--- On Sat, 9/19/09, Mathieu Bouchard <[email protected]> wrote:
> From: Mathieu Bouchard <[email protected]> > Subject: Re: [PD] Array Enhancements > To: "Jonathan Wilkes" <[email protected]> > Cc: "puredata mailing list" <[email protected]>, "Si Mills" <[email protected]> > Date: Saturday, September 19, 2009, 8:26 PM > On Thu, 10 Sep 2009, Jonathan Wilkes > wrote: > > > You can get all of the above (except onMouseUp > behavior) using > > data structures. Really, there should just be a > way to "deputize" a > > ds array as a Pd array usable by [tabread] and the > like. > > So if you have a subpatch with > > [struct blah float x array some_array] > > you could put the following in the same subpatch: > > [deputize some_array] > > And now [tabwrite~ some_array] > > will work. > > I don't get the point of it. there is already a hidden > struct called 'float' defined by pd in a hidden patch (which > doesn't appear in the window list) upon startup. Afaik this > is a sign that [table] is making something that can be used > as a DS array. Having it vice-versa shouldn't need something > like [deputize]. However, such a new object class would be > nice for introducing a "stride factor", e.g. if you have a > struct of several elements such as "float x float y float z" > and you want [tabwrite~] to use only z and not x nor y; this > is unless it would be better to make it an option in every > array-using class, or to make it an object-class that does > something else: e.g. [virtualarray foo bar y] would make a > fake "bar" array that is actually a subpart of foo such that > modifying bar also modifies that subpart of foo (not a copy > of it). This is like the VIEW feature of the SQL language. Do you mean a struct having *arrays* x, y, and z like: [struct foo array x x-element array y y-element array z z-element] ? Then [tabwrite~ foo] writes to all arrays in foo, and [tabwrite~ bar] writes to array y of foo if you use [virtualarray foo bar y]. Do I have it right, or am I completely misunderstanding? > > > But I don't know the inner workings of Pd either, so > I'm not sure how > > feasible this is. > > Your suggestion prompted me to have an idea which in turn > sounds like the kind of API change that could go > hand-in-hand with a replacement to the "64-bit fixes" of Pd > 0.41, but I'd have to think about it more. It would be a > generic feature for setting the spacing between relevant > elements in an array, in bytes. But it may involve too many > changes at once for me to be comfortable with. Happy to have made an idea-prompting suggestion. > > >> I know this is probably flawed for I know not the > inner technical workings of Pd, or for its purposes, there > are other more suitable methods for gui interaction, but is > any of this possible? cheers I don't believe I wrote this. -Jonathan _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
