another problem with sliders

trogluddite · 29 Apr 2012

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...

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.

tester · 2 May 2012

Thanks for advice on order of things. I think I corrected something in earlier version, that works now correctly. Is there a difference between order of refreshing regarding gui and those two other things? Because editbox gui is connected to blocker via redraw area only, not value passing part.

//edit: ooops seems to not work. Sometimes work, sometimes not.

//update: day of updates 🙂 Had to turn on my thinking again instead of mechanical approaching. History tool is nice Trog, helped to solve a problem.

trogluddite · 2 May 2012

Just had another look - i think I see what you mean. I too have always seemed to have a bit of trouble with edit boxes (and drop-down lists etc.) - they don't quite seem to work with triggers/redraws quite like anything else.

Firstly, make sure that the link to the Edit Box is made before the 'blocker+redraw' part. This ensures that the screen is redrawn after the new value has updated the Edit Box - and this is generally good practice with ReDraws; they should nearly always be the last thing to see the trigger. The Edit box is particularly fiddly because changing the input doesn't make anything much happen - the number is put into the primitive, but there's no trigger out or automatic draw of the display (as there would be when you typed a value). Hence it needs a ReDraw triggered by changing input values In this case, the Edit Box may be updated twice. Firstly, when you tyoe in a value.- but then the value goes in a loop around to the slider, and back to the edit box input. This is why it displays a float value (with many decimals) rather than the literally typed string - it is the float "string conversion" from the knob that is ultimately displayed. This may be something to watch out for - if not careful with the triggers, it could lead to feedback (SM highlights such loops in red as a warning). Even if no feedback is detected it can still sometimes lead to erratic behaviour, depending at what point the loop is 'broken'. "Float Changed" modules are good for sorting this out, as they prevent the same value from being passed twice in a row - thus giving control over where the loop is broken. They are also helpful any time that you want to avoid wasted processing of values which have not changed (the stock knobs pass quite a lot of redundant "no value change" triggers).

tester · 2 May 2012

I have editboxes with feedback loops inside to bypass the edit primitive; these ranges in slider were forgotten (from my SM beginnings), so had to rebuild them. Generally it would not require feedback loop (value moving back to input) if the way of accepting values would be different in edit primitive. Now - the true/false is for both - gui editing and discrete input. If you need live input, then it's fine, but usually when you play with value - you wish to hear the change after you decided what to enter and not during.

I removed all blockers from your mod, and added only one - inside the slider before feedback loop. Plus - reedited these range editboxes, so now the loading order is (seems to be) correct.

There is no problem with feedbacks in both - editboxes and sliders, so in fact you can connect output to input with no great issues. Formatting inside defines in which way it will be displayed (how many places) and it's intentional.