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