hey, ive been writing a patch that will allow me to create and instansiate any number of abstractions, each with unique varibles so as each instance of the abstraction will run independantly, but ive hit a problem. I'm using message objects filled with the code from the original abstraction to instansiate it (much like an example in the extended documentation dealing with messages to pd).
its working fine, except that it creates the abstraction in a temporary space.
i want to add a line or two of code to the original message that will direct the newly created abstraction to a fixed location, with a unique name, and then call pd to then place an instance of that abstraction into the existing patch. does this make sense?
if anyone has a detailed knowlege of the pd commandlines and so forth i would really appreciate some help.
thanks, sam
-
Automation
-
sorry, i should add that this is to be used with a loop playing abstraction that i have written, and my aim is to be able to click and instantly create a new instance of the loop abstraction, with a unique table name and object calls so that more than one loop player will play different samples simaltaneously.
i could always manually change the name of each table and so forth, but thats boring.
cheers -
smccusker--a few months a go i had was playing around with the idea of a 'self-modifying' patch. basically, i had an abstraction that modified itself at the time it was created. the modifications were based on a parameters supplied by a creation argument.
unfortunately, when i tried to revisit this patch, i encounted some errors and can't quite remember how i had things set up.
i may be wrong, but it sounds like you are attempting something similar. if so, let me know and i'll see if i can come up with some examples of how to do this sort of thing for you.
i myself am still interested in this area of pd's functionality. i am curious if anyone has written any Pd quines. a quine is a program that regenerates itself. i am not sure if there would be any useful elements of such a patch but it would, nonetheless, be interesting.
cheers. -
thanks for the reply,
by my understanding of your post, i think our ideas are quite similar. My patch has a global counter which assigns a number for the creation argument of the abstraction, so that when created, the array and any related objects will all be given a name/assignment of sample1 or sample2 etc. when the next abstraction is created, the global counter will then send the next sequential number, sample2, sample3 etc.
that part is working fine, the problem lies in that every instance of the abstraction that i create has been created in a cache somewhere, which i can only assume isn't on the scratch disc (since a search for the file yeilded no results), what i want to do is add a few lines to the creation code that will tell pd (much in the same way that it tells it to create a new abstraction, fill it, and open it) to save the file to a set location, with a unique name, and then create an instance of it on the original canvas, so that it can be used.
i have also written a simple delay loop object, and another patch based on a vst plugin that i use with audiomulch that overides the buffersize and samplesize of the soundcard which i would like to be able to create any number of.
Essentially my goal is to create a patch which, when opened, is blank save for a few message boxes, which when clicked will create my abstractions so that any number of instances can be linked together in any combination.
anyway, i hope that my reply was clear enough, and that you might be able to help me.
thanks
-sam -
just a thought,
but what about creating a subpatch first, and then directing the abstractions to open there?
will that change anything?
i seem to remember having weird glitches with building objects from messages, but then it worked fine when i put the messages on the main canvas, and requested for the objects to be built in a subpatch. -
thanks for the reply
how would i go about directing pd to create the new object in a subpatch?
something like this? (appologies for the crude diagram)
[message which creates object( [pd subpatch]
|
|
is this what you meant? -
personally, i wouldn't bother with saving the generated abstractions to a location on disk. i've revisited the patch i did a few months ago and what happens in my is that i have an abstraction that it set up to generate a subpatch on its own canvas (not the main patches canvas). so what happens is on the main patch, i create an instantiation of that abstraction with various creation arguments to make it unique. when that abstraction is instantiated, it goes through a sequence of events:
a. create the new subpatch on the abstraction's canvas. something like this:
[loadbang]
|
[symbol $1] ($1 is the name of the sub patch to be created)
| \
| [makefilename pd-%s] (you will need this symbol for referencing)
| |
[pack s s]
|
[ ; (
[ pd-abstraction.pd obj 83 500 pd-abstraction.pd $1; ( (create it)
[$2 vis 0 ( (hide it)
b. fill the subpatch with whatever it needs to function. e.g.
first you need to pack any parameters together that will govern how the subpatch is created. the only parameter you absolutely need is the name of the subpatch window prefixed by 'pd-'. you'll make this symbol as above with the makefilename object so it looks like pd-subpatch. other paremeters i used were a send/receive name, and one other numerical parameter. after you have your parameters packed, send them to a message like this ($1 is the window name, $2 and $3, are other parameters):
[pack s s f]
|
[ ; (
[pd-abstraction.pd vis 1, $1 vis 1 (
[$1 obj 10 10 r $2, obj 40 40 * $3; (
[$1 connect ....etc.... (
[ create and connect more objs (
[ $1 vis 0 (
[pd-abstraction.pd vis 0 (
note that i have included messages to show and hide windows. i don't know why it's necessary, but i ran into problems when the window wasn't visible. it probably has something to do with the coordinate system. another thing i did in my patch was before i sent this message, i ran a few messages to clear the contents of the subpatch just in case a subpatch with that name had already been created.
and that's about it. my actually patch was a little bit more complicated. i have simplified here for easier explanation. my patch had more complex naming conventions and more parameters were passed to the message box that created the contents of the new subpatch.
i hope this helps.