[PD] [seq16] sequencer abstraction done! - first release

[Federico]

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