These are good ideas, thanks. M
On Wed, Jul 04, 2012 at 11:40:57AM -0700, Jonathan Wilkes wrote: > 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: > 1) 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.) > > > 2) 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 <[email protected]> > > To: João Pais <[email protected]> > > Cc: [email protected] > > 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. > >> > >> > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
