[PD] deleting data structures

david golightly davigoli at hotmail.com
Tue Oct 4 18:17:06 CEST 2005


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 at artengine.ca>
>To: david golightly <davigoli at hotmail.com>
>CC: pd-list at 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 at iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list






More information about the Pd-list mailing list