Preset manager kill me

[Mo]

float changed module after the Preset Parameter prim

It would be better to place the Float Changed just after the Drag Accumulation.

Do it not work with stock knobs when the RedrawLimiter module is deleted? Post example.

Edit: -or try with the fixed knob here.

[tor]

I already removed the float changed in the knobs. Did not help. So I thought I post an example here. I copy one knob and the preset manager to a empty scematic. But before I post it I tested a VST with this knob. Know what.... it works just fine. Is there some kind of limit of maximum number of preset parameters? I do not have that many functions with preset parameter either. Confused......

[Mo]

Is there some kind of limit of maximum number of preset parameters? I do not have that many functions with preset parameter either. Confused......

If you got any array presets, then the subsequent parameters in the order are gone in Cubase. Therefore place arrays very last in the preset order and it works fine.

[tor]

Thanks again for the tip. It made me discover that I had some duplicated parameter names. I do not have any arrays stored though.

But silly me!!!!

Earlier on I had trouble getting the knobs set to default on first load in a host. So I tried to add a 'After load' trigger burried in the 'default load' module in my knobs and then forgott to remove it afterwards.

Problem solved.

Best regards
Tor Alzheimer

[tor]

::EDIT::
This post contained some more alzheimer issues

[trogluddite]

If you got any array presets, then the subsequent parameters in the order are gone in Cubase.

Nearly finished my latest plugin - has a lot of preset arrays. Thank you so much for for reminding me of this 'feature' of Cubase, you have saved me from a lot of bug reports!

[Mo]

Nearly finished my latest plugin - has a lot of preset arrays. Thank you so much for for reminding me of this 'feature' of Cubase, you have saved me from a lot of bug reports!

Yes, preset ordering will also break the compatibility, so it's important to get it right from first release. Also therefore extra preset parameters can't be added afterwards, so reserve empty parameters if you plan new features.
-And always keep the same plugin ID or Cubase will see it as another plugin.

[infuzion]

Nearly finished my latest plugin - has a lot of preset arrays. Thank you so much for for reminding me of this 'feature' of Cubase, you have saved me from a lot of bug reports!

Yes, preset ordering will also break the compatibility, so it's important to get it right from first release. Also therefore extra preset parameters can't be added afterwards, so reserve empty parameters if you plan new features.
-And always keep the same plugin ID or Cubase will see it as another plugin.

If you save the preset using SM's preset manager, won't it be able to re-load in later versions? It is just a .TXT file after all?

[Mo]

If you save the preset using SM's preset manager, won't it be able to re-load in later versions? It is just a .TXT file after all?

Yes, but project files from host would not load the right parameters. Also it would mess up the compatibility if you change the parameter amount or array size.

[stw]

Also therefore extra preset parameters can't be added afterwards, so reserve empty parameters if you plan new features.

Could you explain that? AFAIK new parameters are simply appended to the list. So they don't interfer with any parameter prior to it which are already recognized by the host.

[trogluddite]

Probably depends on the host, but I have certainly had problems with Cubase from small changes like that.
I can understand that a new parameter would have an undefined value, but Cubase (maybe others?) just seems to get very confused when re-loading an old song after the .dll is updated, unless the preset structure is identical in order and size.
You can kind of work-around it by saving the presets as a text file before updating the .dll - and then re-loadng them after the update (doing the file save/load from the plugin GUI rather than the host preset handler) - that seems to work better, only the 'new' parameters are then left without values.
This issue doesn't just affect SM - there have been developers of big commercial synths who have had to provde "preset convertors" in the past, to allow back compatibility of presets with older versions.

Another solution is to only use the same 'Four letter code' for bugfixes etc. But to use a new code number when doing a big 'new features' release - then users have the option of a 'parallel' install, so that they can still keep the old version if they prefer. I have a sub-folder of my VST plugins called 'Legacy' that I keep old plugins in, just so that I know old projects will open exactly as I left them, even if they are years old.

[Mo]

Could you explain that? AFAIK new parameters are simply appended to the list. So they don't interfer with any parameter prior to it which are already recognized by the host.

Example: Take the Example Synth and save it as VST. Open the plugin in Cubase and save the project. Then add a control to the Example Synth and save as VST again with the same ID. Open the saved project in Cubase. All the parameters are now randomized.

[stw]

Example: Take the Example Synth and save it as VST. Open the plugin in Cubase and save the project. Then add a control to the Example Synth and save as VST again with the same ID. Open the saved project in Cubase. All the parameters are now randomized.

No, i can't confirm that. Tested with Example Synth, Cubase5, and several additions to the VST Plug. Never had any oddities. It works the way i described. New preset data is appended and existing preset data untouched.
What happens is that the actual preset data settings saved with the Cubase project (not saved as preset inside the Plug) are gone and overwritten with the preset data of the (new) plug. Not as disturbing as a total preset data mess but not less unwanted from a user. I'd really like to know how to avoid that?

[Mo]

No, i can't confirm that. Tested with Example Synth, Cubase5, and several additions to the VST Plug. Never had any oddities. It works the way i described. New preset data is appended and existing preset data untouched.
What happens is that the actual preset data settings saved with the Cubase project (not saved as preset inside the Plug) are gone and overwritten with the preset data of the (new) plug. Not as disturbing as a total preset data mess but not less unwanted from a user. I'd really like to know how to avoid that?

Yes, ok. The parameters is not random, but recall of a saved preset in Cubase won't work and the parameters seems untouched. Just don't add or delete preset parameters for product updates to avoid it.

[stw]

Yes, ok. The parameters is not random, but recall of a saved preset in Cubase won't work and the parameters seems untouched. Just don't add or delete preset parameters for product updates to avoid it.

uhh... i'm not allowed to release new features in product updates...

not really satisfying.