[PD] Array Enhancements

[Jonathan Wilkes]

--- On Sat, 9/19/09, Mathieu Bouchard <matju at artengine.ca> wrote:

> From: Mathieu Bouchard <matju at artengine.ca>
> Subject: Re: [PD] Array Enhancements
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: "puredata mailing list" <pd-list at iem.at>, "Si Mills" <smills at rootsix.net>
> 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