Correct way to handle updates

Support
1

Hi Marco,

A question for you, what is the correct way to handle updates? For example. Flow+ indicates that there is a new version (1.0.2). So I understand I have to download a new version of Flow+. But what about the Cubase and VSL projects.

I, and probably other users, will have made some changes to the Cubase and VSL project files. So we can not just use the new project files and I think we need to merge your changes manually into our existing templates. Am I correct? For me this is not A problem as long as there is a clear instructions and list of changes for each version :slight_smile:

Kind regards,
Bastiaan

Kind regards,

Bastiaan

1 Like
2

Hi Bastiaan
this is a very good question, and for this you might want to look at the change log page
https://roadmap.artificialharmonics.com/changelog_page.php

on the top right you can choose between the Flow+ or the template project.

Every change I do in a new version I mark it here, so you will be able to also do it on your template.

Kind regards
Marco

3

Hi Marco,

Thanks for your answer, I had a look at it. But i’m afraid the information I see there is too abstract/minimal for me to actually do the changes by hand. Even if I would try to do it by best efforts and guesses based on this information, the chances that I introduce errors are too high.

Would it be an idea to have a separate text/section at each “bug” or feature request in Mantis (roadmap)… that explains the manual actions in an easy and stepwise fashion? If you want I would be happy to review/test that information for you on each update.

Otherwise I see no other option than just stay upstream and use the latest version of your template (each time you publish an update, or periodically). But that of course will be a tough sport, because I have to (for example) fix some Kontakt instances each time due different version numbers of used libraries. I always work on many different projects, so I can not update some Kontakt Libraries while it is used in open projects. However, should this be the optimal path, then in that case I think I will make a local procedure in form of a text document which describes the manual actions that needs to be done, so that I will be able to do it in a consistent way without a margin for too much human errors. But of course the time needed to fix the template will increase as the libraries (added by you) in template itself expand.

I do understand there is no easy solution, just wanted to discuss with you the best method and move forward this way :slight_smile:

(BTW i assume you have thought of this, but have you checked if the .vesp64 file format is binary or human readable (packed) (XML, JSON etc.)). If it is human readable it could maybe be possible to develop some kind of automated merge/patch system.)

Update: it’s a binary format, so forget the last question :slight_smile:

1 Like
4

Thank you very much Bastiaan for this feedback

The only thing I see is that I need to document better what I have done in the template, so one can reproduce it in its files.

I will start reworking the tasks of the previous releases and add more details on the steps

Marco

5

Thank you Marco, I also think that would be the best solution.
Also, I was thinking about the following. Cubase has a feature called “Track preset”;

https://steinberg.help/cubase_pro_artist/v9/en/cubase_nuendo/topics/track_handling/track_handling_track_presets_c.html

It allows a user to save a track or folder to a (.trackpreset) file and recall it in a different project. The track preset can include multiple tracks, also folder structures. It is basically a modular chunk of a Cubase project. And most of all, it includes all sound & channel settings. I think this feature could be used… whenever a user wants to merge new parts from your newer factory template into his older template.

I need to investigate further…to see how this works out. I will let you know.

1 Like
6

Hi Bastiaan

I have been experimenting with this, and also with the import function in Cubase, but they have limitations:

  • rack is not imported
  • channel routing is not imported
  • and so also the rack vienna output and mixer is not imported

while instead the midi sends and the folder structure is imported.

I think it is key to find a way to merge two cubase project, that would be fantastic since in Vienna that is pretty simple, just import the instance and the game is done.

If you want to make some trial my advise is to create two simple projects each connected to a vst instace with a rack and try with them, if it works with a simple project it will work with Flow :slight_smile:

I will keep experimenting on my side too

1 Like
7

I already suspected that… that is great to hear.

I will try to find a solution for the Cubase part…

1 Like