[PD] data structures: sugestions for future implmentation

João Pais jmmmpais at googlemail.com
Mon Sep 14 18:55:44 CEST 2009

Hi all and specially Mr. Puckette,

I've been working more with data structures in a new patch. Although some  
nice things are possible, there are still some details that might give  
much more power to their possibilities. Most of these sugestions become  
only evident when one works with more than one template (struct) in the  
same patch.
To know my context, I'm working now with a template with 5 arrays inside.  
Probably other templates might come with more or less arrays - or maybe in  
the end only one (super-)template, with as many activated arrays as  

My sugestions are:

- be possible to set the parameters dynamically with a "set ..." message,  
like in many other objects. Because all objects get hard-coded with the  
first structure given, it's necessary to create many copies of the same  
code if you want to run the same operation through different templates (or  
even different arrays on the same template).
E.g. if you use [tabread], you can use only the same object to read  
different tables. But if you use [get], [set], [element], ... you need as  
many objects as structs. And if something changes in the structure of your  
template, you need to make X changes to the patch.

- automatic pointer output from the struct by clicking in the structure  
also not in edit mode. This allows a much easier compositional work on the  

- a "select 0/1" command given to a pointer, that would behave like a  
mouse selection in edit mode. or "highlight", to show in which atom the  
pointer is.

- a "displace x y" command. of course this can be already coded, but if it  
would be inside the struct object would be much faster

- a "previous" command for a pointer, or even "previous x" and "next x".  
being at that, maybe even a "first" and "last" as well.

- to choose faster between different "notes" (data structure atoms) on my  
"score", I'm assiging an id parameter to the struct, and these get  
reassigned each time the score is sorted. since each pointer already has  
its own identity, would it be possible to make this number/symbol  
transparent? then it would not be necessary to make more code to do the  
same function. an extra would be a flag to display/hide this number/symbol.
actually I don't really know what's inside a "(gpointer)" - it looks like  
if instead of having number boxes, one would only get (float) when trying  
to see the result of an operation.

- general [get] that doesn't depend on a struct, solely on common  
parameters. This can be used, for example, to make a list of all x and y  
(and w) elements of different templates/arrays - without making a copy for  
each template.

- does the scale function work only for the display of data (with  
draw-objects)? If yes, I guess it would be advantageous to have this  
control already at the data level.
And if not, how is it possible to use this feature to limit the values of  
a struct? (and not only of its representation)

Can it be that there's a memory bug somewhere? Besides some crashes when  
templates get changed, also once was noticeable by looking at the  
properties window that structures kept parameters already deleted. (have  
no concrete example now to show)


João Pais

Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmpais at googlemail.com | skype: jmmmpjmmmp

More information about the Pd-list mailing list