Well, I ended up abandoning attempts to delete the data structures and have
just assigned one data structure to each voice in a polyphonic texture, so
that the DS's get moved around in response to note-events within that voice
rather than created & deleted. Seems to work fine for now, but nonetheless:
it seems to me that creating an effective DS system would involve the use
of doubly-linked lists, each atom having (in C++ terminology) a pointer to
the next object and to the previous object, which are then updated each time
anything gets added or deleted to the list, making it less of a list and
more a 2-way ring (like the <deque> template in C++'s STL), as following
successive pointers in any direction gets you back where you started. That
way, deleting an atom from the list causes the list to close up around the
gap, and the memory address of the defunct atom is returned to the heap and
rendered irrelevant while all remaining pointer references remain valid.
Stuff like this is old hat in C++, and doesn't necessarily involve direct
user allocation/deallocation of memory - a simplified PD equivalent of the
Standard Template Library would be a good way to approach this problem. I
think it can be done automatically without introducing end-user memory
management, though I'm going to have to take a look at the source myself
before signing this statement in my own blood.
On a more germane note, how about integrating the graphical representation of DS's with the rest of PD as useful tools and not just pretty shapes? It would be fabulous if you could somehow "read" the contours of a DS bezier curve like you would an array (ack! another term that gets used twice!! - I mean, a table), without having to literally input hundreds of points - you could just have breakpoints in the DS, but enable indexing of the intermediate points on the curve... which would necessarily be dependent on the DS points - does this make sense? That way you could for instance just use the lines or curves of a DS as a table to control envelopes, any parameter you want, really, without having to do the interpolating yourself. Or am I taking crazy pills here? Just some thoughts.
-David
From: Mathieu Bouchard matju@artengine.ca To: david golightly davigoli@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] deleting data structures Date: Tue, 4 Oct 2005 01:18:57 -0400 (EDT)
On Sun, 2 Oct 2005, david golightly wrote:
I'm trying to teach myself how to use the data structure feature in 0.38-3 - it seems this feature is still very much under development - is there a way to dynamically delete structures, to "un-append" them from a list? I want data structures to appear alongside sound-events, then expire as the events pass on.
Well, that would require not just un-append but also delete from anywhere in the linked-list. There's possibly also a difference between deleting an object and just removing it from the list. If it's possible to just remove the object and keep it alive, or if it's possible to keep pointers to any object, then it's necessary to use a deallocation mechanism, unless the plan is to never deallocate, or to make Pd just as low-level as C/C++. Other than C/C++, which languages make it normal to put the responsibility/burden of deallocating on the programmer? How many Pd users want to do that?
BTW, I find that the inconsistent terminology used in the documentation to describe data structures makes it quite baffling to the neophyte, as terms like "list" (a list of scalars) confuse with a normal pd list of atoms (floats, symbols etc.) and they're treated quite differently.
Yes they are. From language to language, terminology varies a lot, but Pd is the only one I know which has always used twice the word "list" to mean two completely different things, and this at the core of the language.
On one side there are list-messages (and anything-messages) which are stack-allocated indexed-lists of atoms, which you can't explicitly get a pointer to.
On the other side you have heap-allocated linked-lists of atoms, which you can (and have) to get a pointer to.
That's two completely different worlds.
Also, the name "data structures" is very unfortunate because it already means more than that and less than that too. Everywhere else, data structures are considered to not be tied to any appearance at all, and they are normally a lot more flexible than they are in Pd (especially before 0.39, but even with 0.39)
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list