hello Frank,
i can't use toggles in my system, because i used to send bangs to read UI-controls's values (which aren't connected to any wire). while radios and sliders react to bang sending their value, the toggle change its state and doesn't send anything. :(
This can be solved by storing the current value of the toggle into the right inlet of a float object and then banging that float instead.
you are right... (i didn't think that when i got in trouble)
...but this involves creating: (in addition to the [toggle])
- a [r $0-noteon-X-set] object,
- connected to [f],
- connected to [s $0-noteon-X]
and when developing complex interfaces, this can be time-consuming, and (maybe) cpu-power-consuming.... :) however, i couldn't find a better solution than using send/recv in conjunction with [select 0 1 2 3 ...] to make the sequencer thing... i read something about qlist, but with an array of controls, the send/recv mechanism is mandatory.
This also would solve, that currently every change to a slider or so directly sends out the changed value to the outlet, although its not its turn yet.
yeah, i experienced some cool behaviors playing a synthesizer live with [seq16] running :)))) i can fix this in a future release.
Never use a send or receive inside an abstraction without starting it with "$0".
i know also the $0-thing. yesterday i was reading some old pd-list's messages, and i wasn't sure if $0-symbol works across different subpatches.... btw this can be fixed by searching&replacing seq16 with $0 in seq16.pd (i hope)
A third update would be a possibility to save patterns. I may recommend using "Memento" for this, a state saving system I developed.
[cut]
See http://footils.org/cms/show/28 for a screenshot of these (rrad.drumseq).
awesome! i am downloading pd externals. (this is my first time ;) hope to play with rrad.* as soon as possible...
cheers
Federico