[PD] PD- dynamic patching - how to keep track of object creation number?

[Ed Kelly]

>OK i'm getting a little further in dynamic patching, but one thing i don't get is how you keep track of which objects have which creation numbers in PD. is there perhaps a way to list the objects in a canvas sorted by creation order? for example the '1.1.add_objects.pd' example under the 'pd-msg' in the Help browser doesn't work right - i'm guessing it's because the object number is wrong but i don't know what order the objects were created in, and opening as text means i'd have to count every creation line number until i arrived at the one i wanted. if you've got 100 objects on the screen this becomes very difficult.
>
>
>so, any way to do this easily? preferably something i could query from outside remotely.
>


A mess, because you have to do it yourself!

I've tried to do it with music notation, but there are many other issues I have to keep track of as a result.

>
>thanks,
>scott
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>

I'd get into writing a helper object to keep track of things - written in C - because this does make the process of dynamic patching a lot easier. You can encode object types and connections in such an object I guess -  this is a bit like writing an object that makes a map of Pd patches, and you could encode the connections as well. Perhaps iemguts does this although I don't know it that well. (it's the patch itself we're trying to query after all - what objects, in what order, and how are they connected, and in what order).

There follows a long explanation of how I tried to do this with music notation. The objects I created are all abstractions. I may have missed a trick here - is iemguts a tool to query the hash table of Pd? After all, the patch already exists in memory as a bunch of objects in a certain order, with a bunch of connections in a certain order (that is what the patch IS). I may have missed something. 

Scroll down for the long drawn out bit...
;)
Ed























Gemnotes keeps track of the object number internally to [makevoice] which generates objects in a subpatch, and in theory you can send messages back to an object after it has been created. (note - using iemguts the subpatch would not be necessary). Basically I wrote an object to keep track of the object number (gemnotes_counter) and object type, but there isn't an internal database of the objects and order of creation, and it's a huge external, so looking at the source code probably won't help much.?!?!?!

One thing I can say for sure - writing a helper external in C is way easier than trying to create the patch only in Pd - you can organise different types of object directly with an index number, and track them according to object type (e.g. osc~ line~ etc. or in gemnotes, barline, tsig, noteobject etc.)

I've only tried this to sort out the problem with on-the-fly beaming for notes so far - whether they have a tail or not when a group (e.g. 4x16th notes) is interrupted: the "revise" method within [makevoice sends some info to a previously created object, so that the beam/tail values can be reset.

The rightmost outlet of [makevoice] outputs the instructions to gemnotes_counter that make the object (note, barline, rest etc) and these could be logged in a [msgfile] object, but I've not used this yet
I've had problems working with this - objects are arbitrarily created, so which object do you want to change and why? But they are organised according to type, and so a [msgfile] object with some [end, goto -1, where( + [kalashnikov]s could be used to find all objects of a particular type or pitch e.g.

The tail/beam issue, when a group is interrupted: well-formed scores for gemnotes have [group( statements that set up the expected beaming of groups of notes. But In my latest piece I'm turning some of these notes randomly into rests, so the beaming of notes may need to be revised after they have been created, and single notes need to have a tail (not a beam). I've begun writing this "revision" information into the master controller for the system (gemnotes_counter) so that the tail/beaming stuff can be revised on-the-fly (e.g. a group of four notes can be split into 1 note + tail, 1 rest, 2 notes + beam)

But yes, dynamic patching is a bit of a nightmare. Maybe we need to connect it to an SQL database or something...Pd is a giant hash table. Discuss...

Islands 2 will be finished v.soon, and I'll post to the list when it is. Here's the latest gemnotes_0.2.4

Ed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gemnotes_0.2.4.zip
Type: application/zip
Size: 592309 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121008/c7665d73/attachment-0001.zip>