> a glist (list of graphical objects) is internally implemented as a linked > list. usually, a big
> advantage of a linked lists is that adding/deleting elements won't touch > other elements > (especially doesn't move them in memory, like it can happen with dynamically > sized arrays). That's the theory. In practice the insidious audio dropouts happen when Pd is *iterating* over a glist, not when adding/deleting objects. This is because users learn relatively quickly the simple rule that adding/deleting objects rebuilds the signal graph, so they avoid doing that if at all possible during performance. However, users generally have no idea what triggers a walk through the glist linked list. And those trips can easily cause dropouts during a performance-- even merely moving the mouse over a canvas. So in practice, glist as linked list optimizes for the case not often used in realtime performance and is a detriment to performance in the cases where it matters (esp. compared to iterating over an array, though the number of glist iterations with things like mouse motion might trip up audio anyway). -Jonathan _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list