Hello all,
Brandon has a pretty good working example and I hope you dont mind but Im going to poke a couple of holes in it.
Actually, Brandon has already pointed out in the comments within the patch some of the weaknesses of this example (for example, the need to save the arrays separately).
Id strongly recommend building this example around the [pool] object instead of arrays. In regards to storage devices for key-value pairs, the arrays:
a) only store numbers b) can be saved-in-patch c) but save-in-patch option inflates the file size of the .pd file d) save-in-patch option doesnt allow the user to migrate array data from one patch to another (between sessions). Array data can only be shared amongst patches that are open simultaneously. e) Array data that is saved-in-patch is loaded when the patch is opened. f) unloading and reloading the array requires the use of many text files (if you're reading text files into arrays for example)
The [pool] object:
a) stores numbers and/or text b) can save all data in .dat files to be used in a later session or by a different patch c) data can be shared at run time by all open patches d) can store MANY pools in the same data file (great if you want to save values of two or more patches all in the same data file) e) or it can store MANY data files! f) data is NOT stored directly in the .pd file so the file never becomes inflated by your data. g) [pool] offers more (and easier) ways to manipulate data (easy to remove or add to a pool, easy to drop the last element, or first element, or any element in between, easier to re-sort the values) h) data can be loaded at any time from any data file.
The [pool] object is certainly more versatile and is easier to control (it has a steeper learning curve, but its functionality is VERY rewarding).
Just my thoughts: Dave Sabine
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of Bradon Webb Sent: September 5, 2003 4:52 PM To: Shintaro Miyazaki; pd list Subject: Re: [PD] controlling/recording bang actions
Hey, I have something that might work... It might not be as effiecient as you want, but I have made a mock up of how it might work. It records atom boxes to array and reads them back from a tempo array. I find it is really good for live improv stuff. It works well on the fly, but it is more or a way to animate a atom variable, than trigger samples. If you assign each sample a number, it would work. It reads from the left input a change in an atom, and starts a timmer, then when the next atom is read in, it saves both this information (the time in msec, and the value) into two differnt arrays. Then you can play back the array at the realtime tempo or use 1/2 speed or double speed etc. There is also a loop function so the arrays will repeat once they get to the end. There are some other things in there, but I thought I would put most comments inside. Open the RECORDinstructions for a demo mock up. If anyone wants to give input, I know there are a few inefficeient ways of dealing with the data, especially the saving features, but any suggestions\feedback would be nice. good luck Bradon~