Re: [PD] Array Enhancements
--- On Sat, 9/19/09, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] Array Enhancements > To: "Jonathan Wilkes" > Cc: "puredata mailing list" , "Si Mills" > Date: Saturday, September 19, 2009, 10:44 PM > On Sat, 19 Sep 2009, Jonathan Wilkes > wrote: > > > 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] > > ? > > No, sorry, just [struct foo float x float y float z] used > as the template of an array. I thought that we were talking > about that... > > > 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? > > I mean that with the struct foo above, and an array named > foo using struct foo as its template, you could make a > virtual array named bar, which would be an actual subpart of > the array foo, using a different template, which would have > to be some kind of substruct of the original template. Oh, I see. So how would you get an array named foo to use struct foo as its template, as opposed to the hidden float struct? > > >> 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. > > why do you say that? Because it doesn't have the name of the author above it (Si Mills) so it looks like you're responding to me. -Jonathan > > _ _ __ ___ _ _ > _ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: > +1.514.383.3801 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array Enhancements
On Sat, 19 Sep 2009, Jonathan Wilkes wrote: 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] ? No, sorry, just [struct foo float x float y float z] used as the template of an array. I thought that we were talking about that... 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? I mean that with the struct foo above, and an array named foo using struct foo as its template, you could make a virtual array named bar, which would be an actual subpart of the array foo, using a different template, which would have to be some kind of substruct of the original template. 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. why do you say that? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array Enhancements
--- On Sat, 9/19/09, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] Array Enhancements > To: "Jonathan Wilkes" > Cc: "puredata mailing list" , "Si Mills" > 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array Enhancements
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. 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. 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 Well, if you think about the fact that Pd 0.41 fixes the 64-bit problems by adding 100% waste (thus the resulting array wastes 50% of its space), you can guess that it's because it wasn't easy making an efficient fix, therefore it's probably hard to make the [deputize] I suggested; however, it's probably easy to make the [deputize] you suggest (?), but I haven't tried and I don't know what it would involve, i just know that as long as your struct has only one element in it, all versions of Pd so far have their internals fairly ready to accept such a feature. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array Enhancements
--- On Thu, 9/10/09, Si Mills wrote: > From: Si Mills > Subject: [PD] Array Enhancements > To: "puredata mailing list" > Date: Thursday, September 10, 2009, 11:14 AM > Hi Hans/DEv Tem > I have a couple of ideas for the Array/Table > object, mainly visual: > Hide Array name - > doesn't seem to be working.Would it be possible > to limit the array vertically? This would make manually > entering values for a sequencer more usable.Allow a > step value for each slider, so selecting increments is > easier - I guess an Array in Pd is a array of > multi-sliders in a senseExpand appearance - the > array indexes could be solid barsEvent listeners - > so onMouseUp over an array could trigger > somethingColour > properties! 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. But I don't know the inner workings of Pd either, so I'm not sure how feasible this is. -Jonathan > 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 > -Inline Attachment Follows- > > ___ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array Enhancements
Hey Si, Lots of good ideas there. They are all possible, they would probably all require changes on the C side as well as the Tcl side, but nothing too bad. My dev activities right now are focused on tying up all the loose ends with the new GUI, so I won't be able to take on anything new like this. That said, while I am immersed in this, it would be a great time to try your hand at it since I can make adjustments to the GUI code to make these kinds of things possible. One place to start would be color properties, since that can happen in only Tcl. The array elements now have a Tk tag 'array' so you can configure them. Check out the included plugin that does just that pd/ startup/disabled/editmode_look.tcl. .hc On Sep 10, 2009, at 5:14 AM, Si Mills wrote: Hi Hans/DEv Tem I have a couple of ideas for the Array/Table object, mainly visual: Hide Array name - doesn't seem to be working. Would it be possible to limit the array vertically? This would make manually entering values for a sequencer more usable. Allow a step value for each slider, so selecting increments is easier - I guess an Array in Pd is a array of multi-sliders in a sense Expand appearance - the array indexes could be solid bars Event listeners - so onMouseUp over an array could trigger something Colour properties! 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Array Enhancements
Hi Hans/DEv Tem I have a couple of ideas for the Array/Table object, mainly visual: Hide Array name - doesn't seem to be working. Would it be possible to limit the array vertically? This would make manually entering values for a sequencer more usable. Allow a step value for each slider, so selecting increments is easier - I guess an Array in Pd is a array of multi-sliders in a sense Expand appearance - the array indexes could be solid bars Event listeners - so onMouseUp over an array could trigger something Colour properties! 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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
