the user doesn'tget expressivity through data structures that would be comparable to just coding a c external, but they do get a (somewhat) comparable level of complexity.
yes, the worse is that the enigmatic (gpointer) don't mean anything for
someone that can't read the C code, like me. changing that format for a
symbolic "link" - like "structname-scalarnr" or similar, user-defined -
would make much more sense for users. And also, hopefully, give scalars a
faster way of being accessed (the traversing issue).
Here's how to make them better:
- Make a public interface out of the trick you're already using to
load pd-_float_array and pd-_float. Users should be able to make a ds library and load that library with the same ease that they load external libraries using [declare], [import], etc. (This will also solve the problem of trying to use a data structure inside an abstraction, where on the one hand the user must use [struct $0-foo], but then that destroys any chance to save and reload state with impugnity.)
ah, that one I forgot. for my simple abstractions like [bezier] or
[swatch], the scalars of $0-templates are created on loadbang. but that's
not very handy (or possible?) when loading a score with thousands of
scalars.
- Allow scalar creation by typing the name in an object box. If I
A good complement to that would be scalar manipulation as well. like
sending a message [select scalar-1 scalar-278( to select a range of
scalars, and then move them (without going to the x/y fields of each one),
duplicating, erasing, copy/pasting, ...
(Experimental) 3) Add a "canvas" or "glist" field to [struct] as I
suggested in an earlier email. I don't think João would need to search through a linked list
just to find a value if he could have a canvas with the necessary objects in it that is associated with that scalar and its field values.
I didn't understood that, but it sounds very important, my name is in that
paragraph.
João