Had a chance to have a proper poke around in the schematic now - there are certainly a few problems, but the general approach is sound enough.
A few problems I have definitely identified - other, smaller ones are probably concealed by the major problems, but I haven't the time to try all the possible fixes right now. I'll try to give a little detail about
how I found the problems - as the major one may be in a place that you did not expect...
The main problem is with the slider resetting at oscillator change - it makes sense to suspect the 'inslider-reset' triggers, so I disconnected them to see what the 'baseline' behaviour was without them.
...and the slider still resets to zero at oscillator change. The 'inslider-reset' may or may not still be part of the problem, but there is some underlying problem causing other resets - best to deal with those first, as it will confuse any test results when de-bugging the wireless links.
The reset to zero enters the fader via the 'preset tune' input, which also handles the preset "array" for the slider position via the float switch. Look at the output of the float switch - it is always zero, even after playing with the slider. The reason for the reset to zero is that 'preset tune' is an array of zeros - and at oscillator change, one of those zeros is sent ti the slider, resetting it.
I am guessing that when moving the slider, the current value should be stored in the current "tune" preset - same as if the value were typed into the 'tune' box. The edit box will not normally pass these triggers - the 'set' input does not set the output value, it just sets the contents of the GUI label - only typing changes the output. A float switch can be used to toggle between the edit output and the slider input to sort this out.
The fact that only typing changes the 'edit' output may be useful though - for ensuring that only typing generates a 'inslider-reset' trigger (a Boolean to False from the "Is Editing" output does this nicely).
Another anomaly here is that the "preset tune" module contains preset slider positions - but the slider itself also has a preset parameter. These parameters will be 'fighting' each other at preset change - at the least, I would set the in-slider one to not be a preset (automation read/write only).
The preset parameters in the "array" modules, also need some tweaking. The "Auto Rec" input is boolean, and should be true when float values need recording (usually from an "interact" output). Connecting them to the float will not reliably send automation - it is not a Trigger driven input - all that will happen is that automation will get disabled whenever the float value is zero.
For getting things to happen in the right order, things are tricky. Most of that stuff is driven by wireless triggers - i.e. the 'Preset' links and the "osc-selector". There is a strict trigger order for wireless - but it is not easily edited, as it is entirely based on the order that you create the wireless receivers. Naturally, this order is easily disturbed when you are copying/pasting etc.
The best solution is to split those triggers onto separate wireless links, named according to function, e.g...
- Wireless Trig Order.png (12.07 KiB) Viewed 405 times
Then you can use the link order at the "splitter" to easily edit the sequence.
I tried to replicate the problem with needing strings to make the array elements work. In isolation, I can't replicate it at all, though I would probably put a Sample and Hold in that position anyway to block backwards "polling" triggers.
The trigger order will be crucial for that section - if other parts of the schematic cause the inputs to change at the wrong moment during switching, it could cause things to be written to the wrong array index - always tricky when you have a loop of modules. I wonder if it might benefit from a "Before Change", "After Change" approach as used by the presets.
I'd say that there are a couple of general principles that come up here...
- GUI elements are often exceptions to the normal trigger rules (like your edit boxes) - I guess that comes from them being "sub-contracted" to the Windows built-in systems. They are always worth throwing some trigger counters at if you ever find preset values etc. not flowing the way that they should.
- Take care with wireless!! They are a very useful feature, to be sure, but they are the quickest way to trigger order hell!
- Float box tip - when you connect a float box to quickly check a value somewhere, making the link causes the float value to be polled. Sometimes this will "suck" a value through the schematic that under normal circumstances would not have passed through (e.g. because of a missing triggers). This can be misleading because the value shown may have been altered by the addition of the readout. So always run a couple of tests on moving values to check that things really are flowing right.
- Grab the "History Analyser" from
Trogz Toolz- you can connect any "green" node on a schematic to the four inputs. Values and triggers from the four inputs will always be shown strictly in the order that they happened - I find this very handy when I need to analyse the precise order of sequences.
Had to turn on my thinking again instead of mechanical approaching. History tool is nice Trog, helped to solve a problem.