conceptual presets vs sub-presets vs switching

[tester]

I guess this is addressed to trogluddite but any other comments are welcome too.

Concept 1: to make cluster of multiple similar units, driven by only one, switchable interface - instead of duplicating layers of sliders knobs and so on. Plus - each unit with its own sub-preset versus global program for all units.

I just found, that preset manager could be probably used to perform all these. Correct me if I'm wrong. Preset manager allows to save single programs in separate files, and all of them in one file. But also - each program seems to remember last state of the (for example) slider/konb during usage of application. I.e. if I have two programs in live use, and set in one program one value, in other program other value, then these values are intact (independent from manually saving the preset files) during app use.

So - single programs could be assigned modules, and reloaded via one interface multiplexed/switched to these modules. I.e. "switch interface to module 1" => "switch preset manager to program 1", "switch interface to module 2" => "switch preset manager to program 2". Thus - each module will have proper values (but but... no glitches on such switch?), and one interface (plus switchable number over it) - will pretend that these are separate interfaces in the cluster.

But also, when a preset manager program is active, then inside that program individual files with settings can be saved and loaded. Thus - each module would have it's sub-presets and at the same time - all could be saved in one file.

Concept 2: to add some group managers for single parameters from these units.

Now gets tricky. Let say that I have 10 sliders on the screen (each represents 1 program or 1 quasi-interface), each is connected to individual module, and all of them are connected to one main unit interface. My thought is here, that MouseOver could be used to switch preset manager programs while mousing over these 10 sliders. Thus - only one slider is active at once, ant other are disconnected from preset manager.

*

Now - if you understood something from that and from my english - would it work this way?

[trogluddite]

Hmm, I certainly think that most of what you suggest can be done, though I can think of a few potential problems that maybe would make other solutions more satisfactory.

Using a single GUI to control multiple selectable parameters can certainly be done - almost every control of my Loopa project uses this method. As well as the obvious savings in export file size, it can also make Trigger/ReDraw management somewhat easier, and more economical CPU wise.

The sub-presets idea I think may be workable with some suitable preset switching etc., but I can think of a couple of potential problems...

When a new bank (i.e. "global preset" for your idea) is loaded, only the data for the currently selected preset (i.e. sub-module settings) are normally sent. To refresh the whole synth, you would have to cycle around all of the individual presets, reading each "layer" of parameters one at a time. Not only does this add complexity, but there are potential issues with screen ReDraws and trigger management (preset changes perform a global ReDraw that it is not possible to block). It also has the potential to make the user interface more sluggish
Naturally, any trigger/redraw problems would also apply to preset changing by mouse-over.
Also, there are other things that normally happen at preset changing time - firstly the "global" redraws that I just mentioned - but also resetting of code to stage(0), flushing and re-compilation of the audio path. Some of these it is possible to disable within the preset manager - but there is still a high possibility of provoking big peaks in the CPU usage; possibly enough to glitch the audio momentarily.
There is also the question of VST host compatability - I don't honestly how how much of the VST parameter management is done within the plugin, and how much is done by the host (maybe different for different hosts) The VST spec seems pretty robust to being used in unconventional ways, but there would be no guarantee it would be bug-free when used this way.

However, other ways suggest themselves for allowing sub-presets (it is a useful idea for sure).
I have already made a few things which use custom text files etc to store parameters etc. including array tables. the parsing can be a little greedy if the saved files attempt to be verbose (i.e. easily read by eye) - but for sub-presets where there are inevitably fewer parameter, it need not be too bad. It also has the advantge that as well as sub-presets, you could create sub-banks (e.g. a users custom bank of favourite envelope settings).
I have also used this kind of technique to implement cut/copy/paste parameters between sub-modules within a schematic, and also between whole presets - again passing the values by way of a small text file.

It may seem that I have given this an awful lot of thought in a short time - but in fact it has been on my mind for some time. It just so happens that I have the need for precisely such a system myself just at the moment.
Rather unusually for me, I have finally got around to using SynthMaker to make a Synth!.
The twist is that instead of SM's poly signals, I am creating voices using a custom voice manager and mono4. in this way, I have the sketch of an 8 voice poly synth - but recreating the architecture of an analogue polysynth. That is, each voice is a separate unit with free running oscillators (poly voices always reset phase at note on) - and each voice could have totally independent parameters (if desired).
The free running oscillators plus individual voice detuning etc. are making some lovely rich, slowly evolving sounds - but I'd like to experiment with radically different sounds per voice for some pseudo algorithmic effects. Depending on number of notes held and some mode settings, the note->voice assignments can "accidentally" achieve some quite complex patterns - but still in some way dependent on playing style - and I'd really like to exploit this to the full.
And so, just like you, I have a need for operating and storing nested levels of parameters.
I think there are some parts that I have already built that may be useful (text file handlers, cut/paste buffers etc.), so I will see what I can put together by the way of some "toolkit" modules that may serve us both.

[tester]

Okay, thanks! Meanwhile I go to do some cleansing and rearangements inside my schematics plus gui rework. Good that nobody sees the tangle of my wires

[trogluddite]

Did a bit more work on my synth tonight - and I'm getting somewhere with the "layer knob" idea.
Here's a very rough demo...

Octaknob.osm

(26.32 KiB) Downloaded 83 times

Some way to go yet - no presets etc., just a prototype control mechanism.
Each of the two knobs controls four layers of values (the "meters" are just for displaying the values - not "mousable"). Each layer can be adjusted independently, or you can choose one of two "master" modes - relative/ (keep differences) or absolute (synchronise layers).
When in the Master modes, the knob shows the average of the four values - and that is the value taken by all knobs when you decide to "synchronise" using the absolute mode.

[tester]

Actually right now you inspired me to re-think my concept; your is better. Indeed I can make only one slider for tuning, add indicative controls for units and switches on what should go with what. It would simplify the screen. Adding there individual "ranges" (scaling) for values related to bars should be simple, plus one editbox (switchable) per bar - to display current scaled value and to interact manually back with the knob/slider.

Could you add "constant delta" option to that? Because "absolute" resets them to common value.

Anyway - good direction for me too.

[tester]

Hmm... I think I found simpler way? Preset manager could be connected to arrays (reading, injecting). Anyway - array is switching the slider between variant destinations and remembers their values.

[trogluddite]

Preset manager could be connected to arrays (reading, injecting)

...and don't neglect the "VST Preset Array" - it can be used most places that a normal float array can, but the entire array contents are stored as presets - you can even use record/play automation for individual entries within the array.

If you take a look at my MagiMIDI schematic, there are several instances of using large preset arrays directly to store tables of routing assignments (e.g. MagiMIDI module/Controllers/Make Entry).
That one also has cut/copy/paste of presets/banks. It's also possible to copy settings between any pair of identical "sub-panels"on the GUI, and the "clipboard" is remembered using a temporary file on HDD - allowing pasting into different presets (or even two different instances running on different hosts).
You hit the nail on the head when you mention "buffering" - it allows the separation of read and write operations, so the propagation of changes to input values is totally under your control. Arrays are also less "Trigger happy" than many other modules (often with discrete "Do It" inputs), and this too encourages disciplined signal flow.

I have a vague memory of some hosts being a bit funny with VST arrays, though. But if I remember right, it was something to do with the order of parameters in saved preset files - which is possible to fix with a little bit of manual text editing. (can anyone else confirm? - it is a very vague memory!). Not a show-stopper, I don't think, and I have not experienced it myself or had bug reports that I could blame on it.

P.S. One useful trick I have found when using the selectors/multiplexers. Normally, when the index changes, there will be a trigger at the output (whichever gets selected in the case of multiplexers). Sometimes this is undesirable - in fact if you watch your schematic closely, you will see a "flicker" in the displayed values when switching - caused by this extra trigger.
If you place a trigger blocker on the index input, this extra trigger does not occur - and this has no ill effect on the passing of values along the chosen path (value changes at the other inputs will cause the correct index value to be polled).
You will not always want to do this, but there are occasions when it can be very useful to prevent spurious values from being sent - e.g. if the index updates just before an input value change, a previous value may be inadvertently sent out breifly.

[tester]

Pufff... your MagiMIDI schematic is too big for my head But thanks for other cues. Right now - I think I should focus on simplifications - what to remove, which parts will be not used, where to exchange the sliders into editboxes with arrows (by the way - is it only my impression, that counter primitive tends to hang sometimes?). While my first app will remain as it is and will get presets someday - I'm slowly beginning to understand what kind of tool do I need for creating desirable sounds. Maybe not so crazy like this one (or maybe yes? - careful listening may produce unpredictable effects) but surely useful for my further explorations.

[tester]

It appears, that for single parameter (not matrix of sliders) - arrays does not need to be used (less triggers). The key here is the "text" primitive. If the multiplexer's outputs are bypassed with text primitives, then switching works correctly too (does not works with "string" primitives).

[tester]

Puff... The more I play with synthmaker the less I like it... Unfortunately. Solutions work nice in theory (or in light practice), under heavier load - nothing works as should be. What sad is - is the waste of time needed to spend in order to know whether something will work or not.

[trogluddite]

Take a break from your project for a day or two.
Click on modules that are not working.
Press delete (be utterly ruthless!)
Re-build.

You have encountered a common problem with SM.
The user interface is great - as you say, intuitive. But it is hiding the fact that what you are doing is programming a very complex piece of software. The pretty "signals flowing along links" analogy makes the basics very fast to learn, but unlike the usual 'written' programming languages it doesn't make the order of processing especially clear.
This is particularly true of triggers, where there is a lot of hidden processing going on - not helped by the fact that it isn't documented properly. Working out why a particular value is not in the right place at the right time gets increasingly worse as schematic get more complex.
This is why I say to re-build. I have found the way to deal with the complexity of trigger ordering etc. is to work small. Check and test thoroughly the trigger behaviour of even the smallest modules before you connect them to anything else - thoroughly understand what value is where and when.
Then, when you come to nest these into bigger modules, you are dealing with parts that have precisely defined behaviour - and so on, to the top schematic level.
I find this is often much more effective than attempting to de-bug things in situ - and usually leads to a much more efficient design free from "scar tissue" from previous attempts.

Whether you have the time or patience to continue your project, only you know - I hope that you do as it is a very interesting one. But I think maybe you have underestimated the complexity of it - it is a very ambitious one, with many elements that are not commonplace for most synth builders etc.
If you view the time already spent as prototyping or a "feasibility study", then it is not necessarily wasted - you have learned a lot about SM in a relatively short time, clarified your goal, and been guided towards the new things you need to learn in order to reach it.
To put this in perspective - I have been using SM for about four or five years, before that SynthEdit for a year or two - my Soopa Loopa project has been going for all that time, over 100 old versions are archived on my hard-drive. Most of that effort wasn't spent developing the project - it was spent learning how to develop it.
This isn't particular to SM - it's part of the process of producing any complex piece of software, no matter what programming environment you use.

[tektoog]

Hey Tester,
As Trog said, it might be because you didn't take the right approach that you can't achieve what you are aiming at...
If I recall well, there's in MyCO's Loopdrive some kind of sub-presets schematic, also look at the StepLFO template module (this is where I started from to develop my own system) and also look at my Useful collection for starters...
This thread and its follows up should also be inspiring as I guess you could adapt DWB's system to suit your needs...
I also spotted in the last Trog's Toolz version some array modules which could help you a lot for this type of system...
Keep it up man

[tester]

It's not only that. It's almost everything and everywhere. Even simple stupid 30 sine setup (6x <100Hz AM modulators inside) behaves erratically. It appears that SM is yet only a toy and a waste of time and money.

[trogluddite]

simple stupid 30 sine setup (6x <100Hz AM modulators inside) behaves erratically.

Then you must determine with certainty whether some limitation of SM makes your project unworkable, or whether it is that a better understanding of SM (or DSP is general) is needed.
Like I said before, SM's intuitive user interface obscures many of the finer details of creating sound digitally. It is all very well to know the principles of AM, FM, frequency relationships etc. - but when you implement these things in a discrete-time sample based system, there is a whole new layer of theory and practice to learn. Problems like aliasing distortion, instability due to (lack of) float number precision, and incorrect timing of sequential logic - these are all examples of software engineering problems that are common to making plugins whatever the method or software used.
I had a period of frustration like this myself some way into my exploration of SM. I came from a background of building hardware analogue circuits - where time intervals are not discrete, there is no processing 'order' and no latency in feedback loops. It took me some time to realise that using different tools meant also using different techniques throughout the whole design process.
Get some of your prototyping posted up on the forum. It is a complex project, so possibly folks won't have time to fix everything - but we will be able to spot if there are problems in the approach used, and to point you in the direction of the parts of SM/DSP that you should learn next. At the very least, we might know with certainty if there is indeed a limitation of SM that indicates you should look for an alternative solution.
But I would be wary of discarding SM too hastily - all of the alternative "modular" software environments also have their own particular limitations and learning curves. Unless you know with certainty that another software is more suitable to attain your goal, it may not be a wise move.

[tester]

Over 3 months (and not 3 days) to get frustrated is a very long time I think. But rather I'm simply tired. Tired of promises ("something looks promising") and disappointments after spending time with experimenting and getting <type your favourite words here>. Programming environments like SM is addictive, i.e. it produces psycho-physiological issues when crossing certain borderlines and this is not funny. I would rather prefer to write another books or record new audio series. I don't need to become SM guru. I simply need a sonic tools to produce sounds (with no compromises in that area) according to my designs. I'm not saying that I'm resigning. But no more passion and no more fascination with so called "possibilities", illusoric in nature. If someone would ask me for SM and some recommendations today, I would answer now: "go fisshing"