From the original SynthMaker forum (2004–2014), with its members’ names and dates.
tester ·
I have a question regarding presets. I don't care in which order they are saved. What bothers me (makes me think) however is a situation in which there is a chain of modules that depend on each other.
For example, one module makes a calculation on "range" in which second module loads a "parameter"; then first should be loaded "range" and next - "parameter".
If initial range is beyond loaded parameter, then if loading order is opposite (parameter and then range) - parameter will be trimmed to fit the initial range.
How to set loading order? Or maybe rather (if this is timing related too) - how make, that second module loads a value when first module is done? How to approach this topic?
trogluddite ·
This can usually be solved using a similar method to the preset trigger blocking example I posted before.
By using the "Before/After Preset Change" triggers, you can make it so that all the correct values are in place before the final result is calculated - also useful also to reduce the number of triggers (and hence CPU spike) when presets are changed.
Not at my home PC at the moment - I'll see if I can knock together an example when I get home.
tester ·
Would be great, because although I understand what you wrote - somewhat I can't imagine how it works in practice. Thanks.
trogluddite ·
Here''s something along those lines - a technique I often use to help with GUI redraws.
As well as ensuring that calculations happen in a predictable order, you can see from the trigger counters that it also reduces the number of triggers - one preset change results in one output value, not three.
As you can imagine, this can drastically reduce the amount of processing going on downstream whenever a preset changes - and if those changes were connected to a display, a corresponding drop in redraws. In fact, I have found that the preset manager (often/always?) forces a 'global' redraw anyway whenever the preset changes - so I sometimes use this method to block GUI activity during preset changes to avoid drawing everything twice (or more!)
A peek inside the trigger blocking module should ease the explanation...
Firstly, you'll see that all three float inputs have their incoming triggers blocked (the ">>>" primitives from the Flow toolbox) - so a change of input value(s) does not, of itself, cause anything much to happen.
However, when the Float Sample and Hold at the output receives a trigger, it will 'call back' for a value from the preceding modules, and only when this happens, do any calculations take place.
During normal interaction, triggers from the inputs are collected and sent straight through the trigger switch (the flip-flop is turned on by "After Load" at startup) -so every input change produces an output change.
When a preset change commences, the flip-flop goes false, and the updated values from the presets do not pass through.
After the change is done, the FF goes true, causing the Bool "to True" to send a trigger, updating the output safe in the knowledge that every input value must be up-to-date.
There are many possible variations on this idea. For example, in your example of a control that only sets the behaviour of another - you could omit the "behaviour" control's link to the "Trigger Collector" - meaning that the output would only update when the "slave" control was moved.
PS) The little bit of Flip-Flop logic is something I usually put inside my preset manager with wireless outs - no sense having that in every other module when it can be shared!
tester ·
Yhm, now I'm lost. Could you show on a design how to make it?
I'm aware that this one maybe works correctly as it is, but I don't know that for sure.
Limitations of my intuitive thinking in SM 😉
There are 3 presets inside.
1st captures "base" value,
2nd captures "range" for tuning
and 3rd captures "tuning" value.
Now - there is interaction between "base" and "range" (which is +/- range in relation to "base") in order to manage "zero" as the lowest possible point for the tuning slider itself. According to my limited thinking - this "zero crossing" may cause the trouble on scaling the slider/tuning value.
So there should be following loading order: base, range, tuning.
Would be easier for me to understand what is going on (I guess).
trogluddite ·
In a case like the, the order that the presets load is of surprisingly little importance...
Whenever a module sees a trigger at one of its inputs, it send triggers "backwards" from it's other inputs to check for the latest values. So the final value will always "percolate" through.
What is more of a problem is that triggers arrive via multiple routes at the output - so although the final output will usually be correct, there will be a flurry of intermediate values and their associated triggers. (and a lot of "backwards" triggers for SM to deal with too). In this case a single preset changes was creating 10 or more changes at the output. (by no means all your fault - more later...)
Here's a quick draft of some improvements...
At the output, I've done a slightly simpler version of the example posted before - restricting the throughput of data while the preset changes. That gives us the desired 1 trigger per preset change.
You'll notice a few other little tweaks here and there - a handful of blockers and sample-and-holds.
Rather than go into all that here, there's more thorough Trigger Tutorial HERE.
I have not ventured very far into the main slider. It is certainly a source of a lot of duplicate triggers - unfortunately the toolbox knobs/sliders were not designed with dynamic changing of the min/max in mind, and they send triggers all over by wireless within the knob. The output blocker should see to it that they don't get very far!
The stock knobs are my pet hate in SM! - the learning curve for SM's GUI parts can be pretty steep, but not half as steep as trying to learn your way around that horrible Matryoshka doll of nested sub--sub-sub-sub-modules, and wireless links that you can't find the other end of!
I think optimising triggers is tougher than optimising code/assembly in a lot of ways - the rules are just not explicit at all; there are so many primitives with different behaviours; and so few ways to analyse them (the "backwards" triggers are all but undetectable).
Don't kick yourself for not understanding it all at once! - it really is a very surreal programming paradigm sometimes! 😉
tester ·
Trog - quick question: are these "sample and hold" primitives in "range vs 0" module required? Because if they are there, then there an unwanted behaviour related to range change in editbox vs tuning/slider value (scaling problem). There is also another issue in the whole module (undo/redo clearing onLoad indirectly related) if they are there.
trogluddite ·
Everything should work fine without them - the preset before/after section right at the output is the only part necessary to make the preset changes go smoothly.
I didn't have a lot of time to thoroughly investigate every function. I guess I must have made some wrong assumptions about what triggers were "redundant" - I didn't investigate the undo/redo, but it does make sense that it might be affected by my "trigger thinning".
tester ·
Okay, thanks!
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker