Here's Malc's post from when the 'Options' input was added to the preset Manager...Release 1.1.7 Beta8
His post (and the doc's) are not too clear, but here is my interpretation of how it works...(NB. 'Recompile' in the sense used here is not the same as for a proper compiler (e.g. for C++) - things like code and assembly blocks are not parsed all over again etc. - all that happens is that SM takes the 'chunks' of code for each module, and re-connects them so that the execution order is correct.)
1) Normally when streams are re-routed (selectors, multiplexers etc.), it makes a re-compile happen. This is necessary so that SM can check if there are any modules that are not in the signal path (they can 'go to sleep' to save CPU). It also ensures that modules are executed by the CPU in a sensible order to make the behaviour as predictable as possible. (If the module codes were executed in the wrong order, it might stop the audio flowing properly from input to output, and would seriously screw up feedback loops).
2) When changing preset, there could be many selectors etc. all changing at once. Instead of re-compiling for each and every change, the changes are managed so that there just a single re-compile once the preset values have been sent. (Assuming that option is turned on, which is the default)
3) The important part of Malc's post - the ability to turn off preset recompile is there for schematics where it is known that a re-compile is not needed (e.g. pure MIDI plugins, or plugins with no re-routing options).
So, if you DO have selectors etc. that can be re-routed by presets, you DO also need to have re-compiling activated - otherwise nothing will happen until a GUI change etc, makes the routing different later on.
To save processing power, it makes sense for triggers to only force a re-compile if the 'Index' value actually changes - hence sending an extra trigger makes no difference, because the 'index' variable still has the same value (even though it is the wrong value!).
I would guess that a similar principle would apply to the other manager 'Options'. They are not there to force the schematic to behave differently - rather, they are there for when you know that turning them off won't
change the behaviour. There are so many possibilities for what you can make with SM that it would be very tricky to work this out automatically - so it's safest to leave it turned on by default, and let the programmer decide.Note that I don't know if all this is 100% correct
- so I'd advise checking with Malc if this is a feature that is important to your schematic. However, it is consistent with my experience of those settings so far.Technical musing - eminently ignorable...
Why do it this way at all?
The blocks on the schematic are just a network of connections (output X -> input Y), and they must naturally be stored somewhere in some kind of array etc. - so why not look up the connections from the schematic definition as the code is processed?
1) Working out the correct processing order is actually not a trivial task once there are many parallel routes, feedback paths and connectors with more than one source/destination - so doing this for every single sample would eat CPU.
2) Accessing the 'lookup table' of connections would also use a fair chunk of CPU, and create mayhem for the CPU cache. Just looking up the 'next link in the chain' for a single output would use way more CPU than, say, a simple stream Add primitive.
My guess (I stress, just a guess), is that to keep CPU load down, SM uses self-modifying code - that is, when you make a routing change, the actual jumps around the program memory that are needed are written as 'hard-wired' assembly commands - so they don't need recalling from memory for every single sample.
That's a pretty neat way to lower the CPU of a modular design - but it means that when routing is changes, it is not just a few index values to update - the code of the plugin has to re-write part of it's own code.