Selector/preset manager problem

[MegaHurtz]

I have this problem with my selectors when the preset manager is set to 7 (no recompile,no mute,no kill voices).
But under this setting every selection indicator works, as well as leave the right value. But the corresponding selector module does not perform the switch. I would really not like it to do this since its a killer schematic to change presets with. But it seems like theres little hope..

[oddson]

Maybe I'm a little thick today but I don't understand at all.

It sounds like selectors are not getting triggered when there is a preset manager change... but if that's all it was you'd use the 'after program change' trigger to sort it out.

Given who's asking I figure there's more to it than that.

[MegaHurtz]

You understand correctly, but it does not help to use another trigger. The selectors even indicate the right setting when you look inside the schematic. But no results in making the switch. If i set the preset manager to do a recompile everything is fine.It would be kind of a waste to have a big gap on preset changes it`s nice to hear every preset sort of blend into another. But i guess it`s futile.
It looks like it`s working on pack 4 streams, but not on mono streams (that where unpacked and going to be packed)?

[MegaHurtz]

thisthing.jpg

Heres a little proof.. Hehe if you imagine the blue line was just there to get it blue

[trogluddite]

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.

[MegaHurtz]

I suspected something with the very nature i use these for. But still it sucks a general recompile is not the continuous thing a selector change is. Thus changing presets musically is not an option. im going to cambat this some more

[trogluddite]

I agree completely - I have had a nightmare with this 'feature' in some of my schematics - wouldn't be so bad if only the SM plugin glitched, but with some bigger schematics it can splat the whole system audio due to CPU hogging.

It is a cool enough idea to make life 'safer' (and lower CPU) for SM beginners - but I'd really like to see more control over it. Maybe some sort of setting for each individual selector, instead of always applied globally. At the least, it should check for those 'extra triggers' properly to see if the value really has changed!

The only complete way around it is lots of heavy duty assembly - to create a custom version of the routing and the 'automatic sleeping' CPU saver. I have has some success this way, but it's damned hard work, and impossible to use in many situations (e.g. not for stock modules, only for custom assembly ones).

With code, you cannot duplicate this, but you can lower the CPU use of the recompile - by converting blocks of stock primitives into the code equivalent, and combining small codes into one big one. This makes life easier for the compiler because there will be less links, so calculating the routing is simplified.

[MegaHurtz]

Guess ill have to settle for option 3.

[MegaHurtz]

It sounds like selectors are not getting triggered when there is a preset manager change... but if that's all it was you'd use the 'after program change' trigger to sort it out.

Figured it out, it was just that. Had to take me a year tho, incidentally found this topic again Works on setting 7 too. So yea thats it, thanks!

selector snh.jpg (24.11 KiB) Viewed 192 times