[PD] [PD-announce] pd 0.43-3 released

[Jonathan Wilkes]

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 <msp at ucsd.edu>
> To: João Pais <jmmmpais at googlemail.com>
> Cc: pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>