[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
--
Derek Kwan
www.derekxkwan.com
More information about the Pd-list
mailing list