From the original SynthMaker forum (2004–2014), with its members’ names and dates.
lesobrod ·
Here is the simple example with knobs. Some of them are exactly from Toolbox,
some was edited (Decay).
1. All Default fields in Property are set to definite values.
When i switch between Programs in Preset Manager, all knobs behave as crazy.
What does Default mean then and how can i set all of them to definite for any Program?
2. In some Programs (5,6,..) Decay knobs just disappear (oo_OO).
I changed them only by adding a couple of primitives into module (for dB-like control).
I'm going crazy, please tell smth!
Mo ·
1. You need different preset names for each control. Default means the value the knob will reset to when ctrl + click.
2. The knob can disappear when it set to a value that not in range of the knob. To fix, just adjust the knob and the right value would be stored.
lesobrod ·
I set different names. But i don't understand anyway, fron where come values for empty program?
Thanx, I see why knob disappear, but why it has meaningless value?
Mo ·
Empty means 0 and if your knob got range -3 to -1 the knob will disappear as 0 is out of the range.
lesobrod ·
Something is still very weird. It seems that knobs set to random values from one empty program to another.
And about names.. I've got 7 or more identical modules(harmonics) with over 9 controls per each.
Is there non-masochistic way to set names like "Volume-1", "Link-7" etc., so automate naming?
Mo ·
Could be build in preset in the preset manager, but when you adjust each knob for all presets, it would work.
lesobrod wrote: automate naming?
Not really. You can link the preset names together, then add 1 to the preset name for each knob.
lesobrod ·
From Wiki:
a digression
If this strikes you as a lot of grunt work, it is. For a really complex synth with multiple layers and dozens of repeated elements it would be too much maintenance. There is a way, however, to have component presets inherit names from their parent module and the stock modules and controls have this mechanism built in. But using it requires you to enter ‘Developer Mode’ and start dealing with the underlying event mechanism instead of simply connecting blocks of high-level components as we have done so far in these tutorials. A more advanced tutorial on the preset manager should be available in the not-too-distant future.
Oh I need this tutorial!! 😊
trogluddite ·
You can see the principle in the stock knobs.
Inside the preset part you'll find a wireless string receiver - which will be greyed out because there's no transmitter yet.
If you put a string and string transmitter in your harmonics module, that will transmit a prefix to the preset names of all the knobs inside the module.
Then you just name all of the knobs in one of the modules - duplicate as many modules as you need, and you only need to edit the prefix string for each module to make all the names unique..
lesobrod ·
Thank you Trog. I see now. Operations with Strings is very interesting area of SM.
SM need regular expression mechanism, don't you think so? 😈
trogluddite ·
lesobrod wrote: SM need regular expression mechanism, don't you think so?
NextThought = 1- 2 * PrevThought * SomeoneThought 😀
Trog, you read my mind across the land.
Well topic is closed but I still wonder - how appear values of controls in empty Preset programs?
They not just set to zero.
trogluddite ·
Component Guide wrote: The default value for when
the number of presets is
increased
Now, if you try this with a completely new 'Preset Parameter' primitive from the toolbox, that's exactly what it does.
But, the bitmap knobs in the toolbox don't do this - they seem to have a 'memory' of some previous settings from when they were created. Tried it with some other controls - the 'Sliders' also seems to contain 'legacy' values, but the 'Readout Knob' works as it should.
What's interesting is that the controls that have a 'long memory' all contain exactly the same sequence of values - so I guess they are all modifications of one stock design.
I did some more experiments...
- Removed the 'Preset Parameter' primitive from a stock knob and replaced it with a fresh, new one from the toolbox - now it works as it should - added presets get the value at the default input.
- Dropped it into the toolbox. Reset the Manager to 1 preset. Put it back in the schematic. Increasing the number of presets now 'reveals' any preset values that were stored before it was dropped into the toolbox.
- Back to 1 preset, replaced the primitive again, into the toolbox (before adding more presets) - now works OK when dropped from the toolbox, new presets get the default value again (no memory effect)....
So, any time you drop a module into your toolbox that has presets, the preset values go into the toolbox with it - and will be 'revealed' when you use the module again. The default value is ignored until you add more presets than the control was 'saved' with. And it seems that OutSim must have done this with a lot of the stock toolbox controls (presumably just dragged in from the example synth etc.)
It may be worth re-making the controls with a fresh primitive, set to zero, to avoid surprises when adding new presets (zero so that output volume=0, so no blown speakers/eardrums when selecting an 'undefined' preset).
But really, I think it's nice to create a full bank of presets anyway, to be the defaults when a new user first loads your plugin - so really it's not much of problem IMHO, once you know what's going on!
tor ·
I am having a strange issue here. I am having a preset manager with just two presets. A & B. Both cubase and reaper just will not remember the the knobs position on the active preset when i save and reopen the project. All buttons reappear in the right state for both presets but those !"#¤%!%!% knobs reappear in default state on the last used preset after I open the project in the daws but for the inactive preset all parameters is remembered as it was set in the previous session.
Anyone having an idea here?
I have tried to replace all Preset Parameter prims and the Preset Manager prim with no luck 😝
Mo ·
tor wrote: Anyone having an idea here?
Remove the RedrawLimiter module in the knob preset module.
tor ·
Thanks but I have no redraw limiter there now. Used to have one, but that was not the cause I realized. But also in all my other plugs there is a float changed module after the Preset Parameter prim and they work just perfect. 😕
Edit:
Maybe this will do the trick 😉
http://www.youtube.com/watch?v=HtTUsOKjWyQ
Mo ·
tor wrote: 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 ·
tor wrote: 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 ·
Mo wrote: 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 ·
trogluddite wrote: 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 ·
Mo wrote:
trogluddite wrote: 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 ·
infuzion wrote: 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 ·
Mo wrote: 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 ·
stw wrote: 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 ·
Mo wrote: 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 ·
stw wrote: 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 ·
Mo wrote: 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. 😕
Mo ·
stw wrote: uhh... i'm not allowed to release new features in product updates...
You can by reserve some parameters for new features. For example: Reserved 1, Reserved 2 etc. Then just rename the reserved parameter to the new feature while keeping the preset order. It's done the same way for many non-SM plugins too.
stw ·
Mo wrote:
stw wrote: uhh... i'm not allowed to release new features in product updates...
You can by reserve some parameters for new features. For example: Reserved 1, Reserved 2 etc. Then just rename the reserved parameter to the new feature while keeping the preset order. It's done the same way for many non-SM plugins too.
Did you test already that this doesn't confuse the host? I'll try that later too.
Mo ·
stw wrote: Did you test already that this doesn't confuse the host? I'll try that later too.
Yes, it works fine when only renaming a reserved parameter. But it need same position in the order.
trogluddite ·
Thanks again Mo - very useful stuff to know. 🙂
matti ·
Is there any way to see the order or edit the order?
I've accidentally changed it, but not sure when and how..
trogluddite ·
matti wrote: Is there any way to see the order or edit the order?
The order is preserved when you save a preset or preset bank file - so you can see the order by opening the preset file in any text editor. The format is a simple table with each parameter on its own line, and the values separated by TABs.
To change the order, edit the preset file by cutting and pasting the lines in the order you want (e.g. to match a file saved by your old version) - then re-load the edited preset into your schematic.
matti ·
trogluddite wrote:
matti wrote: Is there any way to see the order or edit the order?
The order is preserved when you save a preset or preset bank file - so you can see the order by opening the preset file in any text editor. The format is a simple table with each parameter on its own line, and the values separated by TABs.
To change the order, edit the preset file by cutting and pasting the lines in the order you want (e.g. to match a file saved by your old version) - then re-load the edited preset into your schematic.
Seriously?? Is that all that's needed to change the underlying vst-parameter order? Bit hard to believe...
This could be huge lifesaver for me. I have to check it out.
matti ·
matti wrote:
trogluddite wrote:
matti wrote: Is there any way to see the order or edit the order?
The order is preserved when you save a preset or preset bank file - so you can see the order by opening the preset file in any text editor. The format is a simple table with each parameter on its own line, and the values separated by TABs.
To change the order, edit the preset file by cutting and pasting the lines in the order you want (e.g. to match a file saved by your old version) - then re-load the edited preset into your schematic.
Seriously?? Is that all that's needed to change the underlying vst-parameter order? Bit hard to believe...
This could be huge lifesaver for me. I have to check it out.
Tested it. It doesn't work. The preset names stay in the order they were. Tested this by loading the edited file, then saving it back to a file. And also by loading the edited file, saving the internal preset of the manager, saving the schematic, reloading the schematic and then saving the preset file again.
If the preset file determines the order of the vst-parameters, when it doesn't change, they don't change.
Should i try something else?
matti ·
Mo wrote: Yes, it works fine when only renaming a reserved parameter. But it need same position in the order.
trogluddite wrote: Thanks again Mo - very useful stuff to know. 🙂
matti wrote: Is there any way to see the order or edit the order?
I've accidentally changed it, but not sure when and how..
trogluddite wrote: edit the preset file by cutting and pasting the lines in the order you want (e.g. to match a file saved by your old version) - then re-load the edited preset into your schematic.
No logic..
Anyhow. Nothing apart from deleting the primitive seems to change the order in which a vst-parameter is assigned to. Not even un-connecting and re-connecting the primitives to the "preset feed".
This is a major flaw in the design. A bug id say. Hinders any kind of updating of schematics/plugins. 😕 🙁 😠
Mo ·
Hi,
A preset file will only show the order if you enable "Save or load parameter order info" on the text file primitive in the preset manager. More about preset order here.
trogluddite ·
Apologies - my bad! Thanks for the correction, Mo.
So long since I have needed to do this - only remembered half of the steps. 😕
matti ·
Mo wrote: Hi,
A preset file will only show the order if you enable "Save or load parameter order info" on the text file primitive in the preset manager. More about preset order here.
Got to try the thing Malc suggests there. If it works or not, the parameter ordering is still a MESS! Needs an urgent fix. I'm pretty tired of the endless list of workarounds that need to be used to get even a simple plugin to work.
Edit: I shouldn't forget my manners.. Thanks guys for the help 🙂
matti ·
This workaround doesn't seem to work for me. No change in loaded presets values in the plugin inside a host even though i changed the parameter order according to Malc's instructions.
Very frustrated with this. Every update i make to my plugins is a potential catastrophe to project files created with them. 😝
Reporting a bug now.
infuzion ·
I'm thinking this has more to do with the wireless issue that we have no control over the connection order. Try these:
? Replace all your Wireless Input connections to the Parameter's "P" connection with direct wired connection
? Copy, paste, reconnect all the "P" in the reverse (maybe?) order you want.
? Combination of the 2 above (wire an envelope's Parameters' knob connections to a single wireless.
Try for just a few things first to test, & please let us know the results; I'm curious also.
philter5 ·
infuzion wrote: I'm thinking this has more to do with the wireless issue that we have no control over the connection order. Try these:
? Replace all your Wireless Input connections to the Parameter's "P" connection with direct wired connection
? Copy, paste, reconnect all the "P" in the reverse (maybe?) order you want.
? Combination of the 2 above (wire an envelope's Parameters' knob connections to a single wireless.
Try for just a few things first to test, & please let us know the results; I'm curious also.
+1, replacing wireless links wth wIred does sometimes fix all the issues
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker