duh. sent from non pd subscribed email addy ;)
-------- Forwarded Message -------- From: <> To: matiaskapo@fastmail.fm Cc: pd-list pd-list@iem.at Subject: pd stuffs Date: Tue, 06 Sep 2005 13:20:15 -0700
ok - just for giggles, i've attached a few things. mostly doodles and starts, none of which are really complete but functional enough for folks to play with (all developed under linux, so plugins won't work for windows users, but the patches should still work).
ecktribe.tgz - state saving drum machine loosely modeled on the korg er-1. start the patch named ecktribe.pd
tiles_generative.tgz - incomplete generative music patch w/ simple gem visualization - colab w/ josh steiner for gem stuff. start the patch named tiles_grid.pd
rex_clone.tgz - a simple loop chopper with midi trigering loosely based on dr.rex insturment from Reason. start the patch named rex_clone.pd, load a sample, select slice number, then ether send it some midi, or click the note msg's across the bottom to see it in action.
event-seq.tgz - my new experemental state saver with state sequencing. start patch seq-tagged-example.pd, click load, select test.txt as the sequence, hit play. also, you can hit clear, check record, and record and play back your own. some bugs in it still, but you get the idea. this is my new main project. next trick is to add midi and osc targets to the seq_ctl abstractions ;)
samp_looper.tgz - simple (stoopid) sample looper. just a sketch, really. load looptest.pd
have fun - let me know what you think, would change, etc. if you do anything with them (you are totally free to do so..) let me know.
-shift8
--
seems i left a really important piece out of my state-saver/sequencer project when i tar'ed it up. ;)
attached is a version that has all the parts. i'd love to get some feedback and/or design tips on it (Frank?)
start patch seq-tagged-example.pd, click load, select test.txt as the sequence, hit play.
to record your own, hit clear, check record, hit start, goof with the sliders. (there is a subtle bug still if you hit rewind while record is selected...)
to use it as a regular state saver with multiple states, select record, make some changes, deselect record, increment or decrement (tic). rinse, repeat.
i know i'm kinda reinventing the wheel, but i also need automation with my state saving. if something like this has already been done, please give me pointers!
-shift8
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.
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.
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.
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
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
Frank Barknecht ha scritto:
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.
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.
hi! just installed rradical patches.... in detail, i am interested in memento/state saving, but can't get the restore function to work :(
I created a careGUI, an originator /p1 $0 and some commun /foo $0. if I select file, save, then hit print, correct values are sown: /p1 0 , /slider2 , 25 /p1 0 , /slider1 , 46 and stored in the file: $ cat rrad.txt , , "/p1" , , "/p1" 0 , "/slider2" , 25 "/p1" 0 , "/slider1" , 46 but when I hit restore, sliders don't change their value. can you tell me why? in the pd console there are no more error messages, so I guess all the dependencies (OSCroute OSCx pool etcetera) are solved. I also tried messing with substates, but slider don't receive restored values :-S
Hallo, federico hat gesagt: // federico wrote:
but when I hit restore, sliders don't change their value. can you tell me why?
Yes: Restore only sets the internal state of the active state but doesn't set sliders and other GUI elements immediatly. It's like a muted state change. Described as methods of [originator]: Restore is like "substate x", after which you need to issue a "set" to actually set the GUI elements to the values stored in the current, new state.
To do both in one step, the "setsub x" message is provided, or use the "bang" send from careGUI for this or use a "/preset x" message to the OSC inlet.
Frank Barknecht _ ______footils.org_ __goto10.org__