[PD] event sequencer

[shift8]

On Thu, 2005-09-08 at 10:15 +0200, Frank Barknecht wrote:
> Hallo,
> shift8 hat gesagt: // shift8 wrote:
> 
> > seems i left a really important piece out of my state-saver/sequencer
> > project when i tar'ed it up. ;)
> 
> Seems to be there's more missing: seq-tagged-3.pd used is
> seq-tagged-v3.pd, I guess? seq_motor.pd isn't there.

no... the only things you need to see the example work (and are in the
tarball) are seq-tagged-example.pd (main) , seq_motor_example.pd,
seq-tagged-v3.pd, and seq_ctl.pd.  test.txt is an example recorded
automation, but not really nessisary.

to use this for your own projects, the only object you need is
[seq-tagged-v3]. (defaults to "tic" 1, meaning saving a single state.
if you would like to be able to save more then one state in a session,
or sequence (automate) state changes, then you need to implement
something like seq_motor_example.pd to provide "tic"s and to be able to
navigate them.

> Some quick comments: You use global sends a lot, however I'd need to
> know which ones are used by you, if I'd want to use your patch.

i wouldn't say 3 is a lot ;) any others that you might see (2, i think>)
don't go anywhere, and are artifacts of development.

the only ones that are nessisary are "clear" (because there is a
bug/feature of [pool] that makes itself known if you have many pools of
the same name - ie. shared storage, and only message one of them with
{clrall{ ...),  "reset" (needed to rewind the current "tic" to 1), and
"tic" - the global that tells storage what page it's on. 

everything else is supplied my the user, who could quickly see what
sends and receives are used by looking in [pd controls] or wherever else
they define [seq-ctl] objects.  to say it a different way, the user will
always know what [s]'s and [r]'s are in play, because they would have
specified them themselves.

> For example, I'm not allowed to use "s1_in" in my own patches anymore.
> This is quite a restriction IMO, especially when I'd need to look
> inside the sequencer and follow its logic, to find out which sends are
> taken. IMO (and I lined out reasons for this in my RRADical paper)
> "libraries" of abstractions should not use global sends at all.

i understand (i think) the reasoning here, but if there are a very
limited number of globals that are not user specified, i think it comes
close to meeting the spirit of that idea.

> But probably you don't really intend to provide this as a "library",
> right? However for Memento this was an important guideline while
> designing it and it is responsible for some decisions, which might
> seem a bit too complicated at first.

i'm a little fuzzy on the "library" vs "abstraction" nominclature
here...

> Ciao
--