[PD] [text define] functionality for text in structs?

Derek Kwan derek.x.kwan at gmail.com
Wed Mar 29 13:47:10 CEST 2017

"Christof Ressi" <christof.ressi at gmx.at> writes:

> I have - and traversing large lists of scalars by pointer can be veeeery slow. 
yeahhhh, i figured that could be the case =P

> you could hide the fact that it's a linked list from the user but I
> don't know if that's a good thing to do. It doesn't seem transparent
> to me ("why is accessing the 1000th elements slower than the 1st
> element?").

I suppose you could tell the user via documentation, but then you'd have
go into what a linked list is and why linked list indexing is
O(n) versus array O(1) to explain the speed difference and yeah,
I see your point haha. And it's probably not good either to have a layer
of abstraction that isn't totally necessary either.

> if you don't use the graphical representation, you can just as well
> work with data structure arrays and get fast random access. there is
> one little but unfortunate drawback compared to using lists of
> scalars: drawn instances of array elements don't respond to mouse
> events, making them more or less useless as UI elements. if you
> click/select an element, you only get a pointer to the array, not to
> the element(s). if you click on the canvas, you get pointers to the
> array + all array elements (for whatever reason).
> The right behaviour IMHO would be that clicking/selecting array
> elements gives you pointers to the array *and* the clicked/selected
> element(s). clicking on the empty canvas shouldn't trigger any mouse
> events!
> Apart from that, data structure arrays are quite easy to handle and
> much more efficient than linked lists of scalars

ah, that's interesting. admittedly, i haven't used pd structs that much
in my pd work as of yet but the stuff i want to do seems to be
increasingly lending itself to that (or a similar) sort of paradigm so
i'll keep that in mind!


Derek Kwan

More information about the Pd-list mailing list