[PD] data structures: sugestions for future implmentation
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
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
- 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
- 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)
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