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__