...that deal with pure data
You are not logged in.
i'm still a pd beginner, learning abstractions right now. maybe you can help. attached is a mini sequencer (could have been anything else). the toggles are set to initialize, but when the patch is re-opened, they don't seem to remember changes made in the last session. no problem with subpatches, so my guess is, its a dollar sign thing?
sometimes, when closing a patch, pd asks to discard any changes made in abstractions xy, which seems to be asked also when nothing was changed. i'm confused
Offline
The initialized values are saved in the abstraction itself, and will only be saved when you save the abstraction, not the parent patch. So if you have several of these in the parent, you'll need send the values somewhere in the parent, like in an array, and save them in the parent patch.
Offline
Thanks Maelstorm for your reply. I'm late, but could you give an example, I feel so dumb
Offline
don't feel dumb, it's actually not a simple task - well, not nearly as simple as it should be.
i have attached a little example of what maelstorm means about sending the data outside of your abstractions to be saved in the parent patch. There are a million different ways to do this though, this is just one of them.
Offline
mod, this is very helpful and means a lot of time. But I'm still fighting with the abstractions, the dollar signs make me sick. Would you please have a look at this patch, because I get this:
error: 0-soundfile: no such table
And I don't understand. I guess there are still some dollar signs missing, but I really don't know what causes this error. Must be a simple little mistake and I don't see it
Last edited by wk (2011-11-11 11:04:55)
Offline
without even looking, i can guess that you're using dollar signs in messages?
dollar signs act differently in messages than they do in objects (of which abstractions are a part).
this issue really needs a new tutorial. i'd do it now, but i have been out and had a couple of ales.
Offline
yep! gets 'em every time.
you have $0-soundfile in a message box. basically this means nothing, as dollar signs in message boxes refer to the 'nth' message that is sent to the inlet. so, of course the 'first' message is obvious, but the 'zero-th' message is undefined, and thus set to zero.
instead of what you have, try:
[openpanel]
|
[pack s $0]
|
[read -resize $1 $2-soundfiler(
etc
see, in this case, your message box gets sent the filename as $1 and then gets sent the parent patch's $0 value as $2.
if this is all still confusing, i will try to make a tutorial about it next week. If not, then remind me anyway, and i will make the tutorial to help others.
cheers
Offline
Thanks mod, the [pack] object did it, i tried [read -resize $1 $2-soundfiler( before without [pack] and that didn't work. [pack] and [unpack], [list], [route].... ok, i really have to go into it now, they seem to be absolutely essential. Thnaks for helping me out here, I'm making progress and hopefully others who read this will go ahead as well
Yes, a tutorial would be a good idea, i think hardoff made a very good one for dollar signs in object boxes and that helped me a lot, but the slightly different meanings of dollar signs in objects and messages can be very confusing. It's not too hard to get the idea, but using it within your own abstractions is another thing when you never did this before. Studying patches in quest of specific information is often quite painful and even more confusing, but, on the other hand, challenging. Ok, but using dollar signs in abstractions is such an essential part of Pd, some more examples could really speed up learning Pd, on the web there are not too many illustrations regarding this subject (or maybe i didn't find them) and the manuals that come with Pd are also a little bit shy sometimes....
Bla bla... Have a good time
Last edited by wk (2011-11-11 21:29:00)
Offline
What about [objects~] that are cross-talking? I've got several abstractions running with (in this example) [phasors~] in both. There seems to be some sort of cross talk (I think) between one abstraction and another - also the case in sub-patches also.
How can I stop this as I imagine it's also connected with using $0 etc?
Thanks in advance.
Offline
If those abstractions are using $0 in all of their [send ], [receive ], [send~], [receive~], etc. objects, then there shouldn't be any cross-talk. See Help Browser --> PureData --> 2.control.examples --> 13.locality.pd
Subpatches are a different story. They don't get a unique $0 assigned to them (they just use the same one as the parent patch), so you have to be more explicit with the names. If the subpatches are all copies of each other, it could be easier to just make them into abstractions and use $0.
Offline
Hi Maelstorm, probably saved me yet again, thanks.
Last edited by joesh (2012-02-22 21:47:34)
Offline
mod wrote:
i have attached a little example of what maelstorm means about sending the data outside of your abstractions...
Thank you for the state-saving example, Mod. I am a beginner so please excuse this simple question: Why do your gui-examples know, that their names are test and test-2? I can´t find the source of the naming, neither within the subpatch gui-example nor the master patch state-saving.
Thank you for any insights
Offline
Answering this myself, might help other beginners in the future:
Use a unique identifier added to the name of the subpatch, like
[subpatchname copy-1]
[subpatchname copy-2]
etc.
That way data sent to individual copies of the subpatch can be clearly directed from the main patch.
Offline
It's also possible to send data via a [set $1( etc. message into an empty message and simply give it a loadbang, which i found is very handy if you don't need to save very long lists, only a few toggles or sliders or whatever
Offline
Hi Jayrope,
I haven't seen Maelstorm's patch but I think the answer to your question is that the send/receive symbols for a gui object can be set in the properties pane for each object. Right click a GUI object, select properties and under 'Messages' is the send/receive section.
Also, adding a unique argument to a subpatch will actually not doing anything. All arguments after the name of a subpatch are ignored. This is where abstractions come in handy because you can do that.
Offline