Hi Miller, I think the whole gpointer thingy forces Pd users to think about unnecessary details-- like scalar creation order-- just in order to use them, which is exactly why the #1 complaint about them is that nobody understands how to use them. You've designed the rest of Pd to hide just the things data structures reveal. Unfortunately 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.
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.)
- Allow scalar creation by typing the name in an object box. If I
have [struct foo] in a subpatch template I should be able to type [foo] andhave it create a scalar. If I loaded a library named "foo" that includes a template for [struct bar] I should be able to type [bar] or [foo/bar] and have the scalar create. If it's any harder than that to create a scalar then the number of people who will understand and benefit from using data structures will never exceed the number of people who understand and benefit from dynamic patching (which is very few because it's too clunky). If you do these then data structures will be crystal clear: As an abstraction is Pd code analogous to external class in c with default widget behavior So too is A data structure template analogous to an external class in c with custom widget behavior
... with the added benefit that coding up such a data structure doesn't carry the complexity of coding a graphical external class in c.
-Jonathan
p.s. (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.
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: João Pais jmmmpais@googlemail.com Cc: pd-list@iem.at Sent: Wednesday, July 4, 2012 12:43 PM Subject: Re: [PD] [PD-announce] pd 0.43-3 released
(t aking this off pd-announce - sorry I didn't notice that earlier :)
Yep, it was indeed my original focus, and it's proved hard to make it as wonderful as I keep hoping it will someday be. Anyhow, making traversal more convenient is definitely something I want to do. BEsides the ideas you mentioned, here are two others - first, being ble somehow to name a pointer so somewhere else in the patch you can get what's inside a pointer object - maybe somehow making it more like "v" objects.
Also, making pointers/data structures and "textfile" have many of the same methods (and several more of them) so you can search, trim, reorder, etc.
Much to think about!
cheers Miller On Wed, Jul 04, 2012 at 06:33:49PM +0200, João Pais wrote:
I would find it very simple if a method would allow me to find scalar nr 2571 (I have a patch with many more) by sending the message [traverse xxxx, bang, next 2571(, than by building a [2571(-[until]-[next( structure. Or for example, it's impossible (?) to erase scalers without using the mouse. Making those simple/trivial operations less laborious to program - i.e., incorporate them into [pointer] - could be a good way of making data structures more accessible. which was anyway, the original drive to create Pd, as I read in your paper (right?).
or, what was meant with "unnecessary complexity"?
Yeah... I'm still trying to figure out how to make data structures
less
clunky without adding unnecessary complexity... I'm planning to go
back
and look at that again.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list