[PD] deleting data structures

[Frank Barknecht]

Hallo,
david golightly hat gesagt: // david golightly wrote:

> 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. 

This sounds like a sensible approach. 

To add a third name, that is used in different contexts to mean
different things: The problem with deleting a data structure is not
only one of memory (de)allocation (that can be solved using C language
features), but the fact, that there is a [pointer] Pd type, which can
be passed around just like a float or a symbol can. A float can not
become invalid, however a [pointer] can: 

If you work a bit with DS, you will encounter messages like
  
  error: ptrobj_bang: empty pointer
  error: ptrobj_next: stale pointer
  error: set: empty pointer

a lot, if you delete a DS, whose [pointer] is still in use in your
patch. This doesn't crash Pd (most of the time) but it will do other
strange things. For example in the Midi-Loop-Sequencer I posted (also
in my PWD~ ("public working directory") at [1]) the sequencing will
stop as soon as you delete a note in your pattern, probably because
not only the deleted [pointer] became invalid, but also all other
[pointer]s in the same list (i.e. subwindow).

So to allow clean deletion of DS-objects, some care has to be taken
with dangling [pointer]s in a Pd patch's logic, too. 

However as deletion of DS is possible by hand (and also by Pd's
internal messages for mouse movement and editing) adding a
"remove"-method to [pointer] would not create a fundamentaly new
problem, as far as I can see.

[1] http://royalrabbit.goto10.org/svn/goto10/pd-patches/fbar/pipeseq/

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__