Oops. I meant to put [Pd]
On Nov 19, 2007 4:55 PM, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
I believe the question of saving automation data has come up before, but this is a different question, I think.
I want to write and read the objects in a subpatch to and from textfiles; not the state of the objects, nor scalars, but the patch itself. Is there a way? I have 8 voices in my sequencer, and 8 subpatches for creating control values to send to csoundapi~. But each Csound orchestra I work with will have different parameters for different instruments, and so the 8 will be different from each other, as well as being different depending on what score I open in my Pd sequencer. So I gave up on using abstractions with arguments, because whenever I change one they all change. But AFAIK subpatches can't be read and written by sending messages to them. Any ideas? Is there a 'menusaveas' message or something? -Chuckk
no idea about sending patches to text files, but here's what i would do:
go back to your idea of using abstractions, but give each abstraction only one creation argument.
so, patch one has a creation arg of 1, patch 2 = 2, and so on.
then just use [route $1] to send different params to each instrument.
I'm using pd-0.41.0-test05. The messages documented in http://dh7.free.fr/pd-msg/pd-msg_05.tar.gz aren't working for me. the [saveto( message kills pd, with or without an argument. I'm guessing this is the message that would solve my problem. Has anyone used it in the past? Is this msg documentation still applicable to 0.41.0-test05?
-Chuckk
On Nov 19, 2007 5:25 PM, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
Oops. I meant to put [Pd]
On Nov 19, 2007 4:55 PM, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
I believe the question of saving automation data has come up before, but this is a different question, I think.
I want to write and read the objects in a subpatch to and from textfiles; not the state of the objects, nor scalars, but the patch itself. Is there a way? I have 8 voices in my sequencer, and 8 subpatches for creating control values to send to csoundapi~. But each Csound orchestra I work with will have different parameters for different instruments, and so the 8 will be different from each other, as well as being different depending on what score I open in my Pd sequencer. So I gave up on using abstractions with arguments, because whenever I change one they all change. But AFAIK subpatches can't be read and written by sending messages to them. Any ideas? Is there a 'menusaveas' message or something? -Chuckk
so why not just have 8 'sandboxes' all within one abstraction and then just save that every time you edit it?
i always try to think within what i know pd can do..and then at a last resort look to externals or exotic patching fixes....but i don't think you're at the last resort yet.
there must be a simple way.
you could save your song data within the same abstraction as well, thus only one save every time you edit your song.
so, basically you'd have the guts of your synth in one patch, (patch A)
and then the variable arrays, sliders, radios, etc..as well as sequence data..in another patch. (patch B)
and then for every new song you'd just have to make a new patch B and use that to feed info into patch A
That at least mimics the way that Csound (and all of the Music N languages) have operated: a score/orchestra separation.
~Kyle
On Nov 20, 2007 9:35 AM, hard off hard.off@gmail.com wrote:
you could save your song data within the same abstraction as well, thus only one save every time you edit your song.
so, basically you'd have the guts of your synth in one patch, (patch A)
and then the variable arrays, sliders, radios, etc..as well as sequence data..in another patch. (patch B)
and then for every new song you'd just have to make a new patch B and use that to feed info into patch A
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Nov 21, 2007 at 12:35:23AM +0900, hard off wrote:
you could save your song data within the same abstraction as well, thus only one save every time you edit your song.
and then for every new song you'd just have to make a new patch B and use that to feed info into patch A
As Frank has already pointed out, that sounds to me an awful lot like a problem that is solved much more easily using SSSAD.
Best,
Chris.
as far as i can tell, ssaad just saves the state of sliders, arrays etc that are already a part of the patch...but what chuck needs is a way to save different combos of these gui objects.
can ssaad do that?
Hallo, hard off hat gesagt: // hard off wrote:
as far as i can tell, ssaad just saves the state of sliders, arrays etc that are already a part of the patch... but what chuck needs is a way to save different combos of these gui objects.
sssad is in no way tied to sliders or something, it *is* tied to messages however.
[sssad] can save any list message composed of symbols and numbers, i.e. it doesn't save pointers, gemlists or similar kinds of data, but most of the time you don't want to save these anyway or as with pointers, their underlying data already has its own saving mechanism.
As we still don't know what exactly Chuck is trying to save except that it can also be represented by a subpatch, I'm still confident that sssad can handle it, because even subpatches are just made of messages, which sssad was made to handle.
sssad works by intercepting and eavesdropping the flow of messages at listening points defined by the user through inserting a [sssad NAME] object. On a "save" command, the sssad objects will send out the last message they heard at their position, tagged with the user-defined names, to a global receiver from where they can be collected and saved to a file or message box or whatever. On a "restore" command, the stored, tagged messages get sent back to their respective sssad objects and will be inserted into the flow of messages at the sssad objects' positions. So you can use sssad everywhere you need to take a snapshot of the last messages sent. No sliders necessary.
Ciao
Frank Barknecht _ ______footils.org__
yeah, but what chuck wants to know is WHICH objects are in his subpatch. so...if he puts a slider, 2 number boxes and 3 arrays in a subpatch, he needs something that will tell him that the subpatch contains a slider, 2 number boxes and 3 arrays.
and then in another subpatch there might be 6 number boxes all connected to a [pack] object going into a [send]
ssaad will only tell you the values OUTPUT by these objects...but it won't tell you WHICH objects are in place.
Hallo, hard off hat gesagt: // hard off wrote:
yeah, but what chuck wants to know is WHICH objects are in his subpatch. so...if he puts a slider, 2 number boxes and 3 arrays in a subpatch, he needs something that will tell him that the subpatch contains a slider, 2 number boxes and 3 arrays.
and then in another subpatch there might be 6 number boxes all connected to a [pack] object going into a [send]
ssaad will only tell you the values OUTPUT by these objects...but it won't tell you WHICH objects are in place.
Yes, that's true. However unless Chuck will never touch these objects, nobody else in Pd will know they exist either. But as soon as he touches the objects, sssad can chime in and do its work.
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 2007-11-21 at 18:36 +0900, hard off wrote:
yeah, but what chuck wants to know is WHICH objects are in his subpatch. so...if he puts a slider, 2 number boxes and 3 arrays in a subpatch, he needs something that will tell him that the subpatch contains a slider, 2 number boxes and 3 arrays.
and then in another subpatch there might be 6 number boxes all connected to a [pack] object going into a [send] ssaad will only tell you the values OUTPUT by these objects...but it won't tell you WHICH objects are in place.
how comes that it is 'unkown', which objects are in the subpatch? either it is known, because there is a finite number of different kinds of subpatches or these are created dynamically by messages to canvas. in the latter case, the content of the subpatches is know, because it was created by another patch. so in either case the content is know. this also means, that you can put the list of known objects in one or more messages and thus can be saved by ssaad system.
(sorry, if i missed an important point of that thread, but i just can't think of a case, where a list of objects is unkown)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Nov 21, 2007 11:28 PM, Roman Haefeli reduzierer@yahoo.de wrote:
On Wed, 2007-11-21 at 18:36 +0900, hard off wrote:
yeah, but what chuck wants to know is WHICH objects are in his subpatch. so...if he puts a slider, 2 number boxes and 3 arrays in a subpatch, he needs something that will tell him that the subpatch contains a slider, 2 number boxes and 3 arrays.
and then in another subpatch there might be 6 number boxes all connected to a [pack] object going into a [send] ssaad will only tell you the values OUTPUT by these objects...but it won't tell you WHICH objects are in place.
how comes that it is 'unkown', which objects are in the subpatch? either it is known, because there is a finite number of different kinds of subpatches or these are created dynamically by messages to canvas. in the latter case, the content of the subpatches is know, because it was created by another patch. so in either case the content is know. this also means, that you can put the list of known objects in one or more messages and thus can be saved by ssaad system.
(sorry, if i missed an important point of that thread, but i just can't think of a case, where a list of objects is unkown)
Not sure I understand. I have 8 subpatches, which could as well be 8 abstractions, though I've set up a working system for now. Each of those subpatches is to be a free playground while working on any one piece. Each is for sending control messages to Csound for one of the 8 voices I may use in any one piece. For each piece, I will create a different patch; some will need [line] objects, some will need sliders, some will need toggles, etc. So when I load a piece into my sequencer, I want to have the 8 patches I created for that piece load automatically, and when I save the piece, I want the objects and messages in that subpatch to save to a separate file for the piece.
What I've done was, whenever saving a piece, sending "set #N canvas etc" to a textfile object, then saving it as the name of the piece plus number of instrument, then copying all the contents of each subpatch and pasting into that file, then [;pd-file.pd menuclose 1(. When I load, open the file, selectall, copy, close, open the subpatch, paste, editmode 0, vis 0. Works for me. Only annoyance is that it now tells me my sequencer has been edited and should be saved; since I'm pretty much done building the sequencer, I just remind myself not to save it (if I save the patch with an open piece, the list of notes makes the patch too big for Pd to open and when I open it again half the stuff is missing).
So there is not always a list of objects; only when it is copied from one existing patch to another. They're initially created by me playing around.
-Chuckk
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
Not sure I understand. I have 8 subpatches, which could as well be 8 abstractions, though I've set up a working system for now. Each of those subpatches is to be a free playground while working on any one piece. Each is for sending control messages to Csound for one of the 8 voices I may use in any one piece. For each piece, I will create a different patch; some will need [line] objects, some will need sliders, some will need toggles, etc. So when I load a piece into my sequencer, I want to have the 8 patches I created for that piece load automatically, and when I save the piece, I want the objects and messages in that subpatch to save to a separate file for the piece.
What I've done was, whenever saving a piece, sending "set #N canvas etc" to a textfile object, then saving it as the name of the piece plus number of instrument, then copying all the contents of each subpatch and pasting into that file, then [;pd-file.pd menuclose 1(. When I load, open the file, selectall, copy, close, open the subpatch, paste, editmode 0, vis 0. Works for me. Only annoyance is that it now tells me my sequencer has been edited and should be saved; since I'm pretty much done building the sequencer, I just remind myself not to save it (if I save the patch with an open piece, the list of notes makes the patch too big for Pd to open and when I open it again half the stuff is missing).
I would indeed use abstractions for this. They can be saved with Ctrl-S, which is easier than your subpatch saving, which seems overcomplicated to me. But of course to each his own. ;)
Ciao
Frank
On Nov 22, 2007 11:58 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, I would indeed use abstractions for this. They can be saved with Ctrl-S, which is easier than your subpatch saving, which seems overcomplicated to me. But of course to each his own. ;)
To save all 8 automatically with one button would then involve sending [key] messages to all of them for Ctl-S, no? To have 8 abstractions that reside in the program and save to separate files to be loaded again on cue would take exactly the same amount of work as using 8 subpatches, if I'm not mistaken. Otherwise I guess I could delete the 8 abstractions every time I wanted to work on a different piece, and create 8 more for the new piece. As far as I can tell that requires at least editmode 1, a mouse sweep to select the 8, then sending a backspace key message, then 8 messages to create 8 objects for the new abstractions; and if the abstractions don't already exist, I still have to use textfile to create them.
As it is all I do is type the name of the score and hit load. The 8 subpatches are automatically filled. When I hit save, they are rewritten. If I save a new piece, 8 new files are created in a special folder with the name of the piece + instrument number, and written from the subpatches.
I am experiencing frequent crashes since setting this up, not sure where they come from. MUST be fixed, as I have already lost small bits of work as a result... More later. -Chuckk
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
On Nov 22, 2007 11:58 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, I would indeed use abstractions for this. They can be saved with Ctrl-S, which is easier than your subpatch saving, which seems overcomplicated to me. But of course to each his own. ;)
To save all 8 automatically with one button would then involve sending [key] messages to all of them for Ctl-S, no?
I'd go slightly a different route: Assuming you edit and extend all 8 abstractions one by one, you could save each one after you're finished editing it with a single Ctrl-S. Of course you could not (easily) save all 8 abstractions with one command, but I don't think this would really be necessary.
Cyrille Henry told me once about the interesting setup chdh are using (Cyrille, correct me if I don't remember all of this correctly.) chdh started as a project of Cyrille and his brother Damien (now its a trio), who both lived in different cities. To make working together easier, they use a version control repository where abstractions are checked in.
The main performance patch is dynamically created according to a config file, that just lists the instrument abstractions to load into it. So if for example Damien fixed some stuff in an instrument abstraction, he would check it in, then Cyrille would do a "cvs/svn up" and rebuild the performance patch by clearing and reloading all used abstractions with some simple dynamic message editing.
The dynamic messages for this could be: ";pd-performance clear" to start over with an empty [pd performance] subpatch, then a "read config.txt, rewind"---->[textfile] to load the config file, whose content then gets dumped by [until] into a: ";pd-performance obj X Y $1" possibly replacing X/Y with appropriate coordinates generated from a counter. No "editmode", "select all", "vis 1" or so necessary and almost as easy as instantiating data structures. ;)
See attached patches for how this could work.
Ciao
Frank Barknecht _ ______footils.org__
-
Chris McCormick -
Chuckk Hubbard -
Frank Barknecht -
hard off -
Kyle Klipowicz -
Roman Haefeli