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
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
--- On Thu, 9/10/09, Si Mills smills@rootsix.net wrote:
From: Si Mills smills@rootsix.net Subject: [PD] Array Enhancements To: "puredata mailing list" pd-list@iem.at 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
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
--- On Sat, 9/19/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Array Enhancements To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "puredata mailing list" pd-list@iem.at, "Si Mills" smills@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
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
--- On Sat, 9/19/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Array Enhancements To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "puredata mailing list" pd-list@iem.at, "Si Mills" smills@rootsix.net 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
-
Hans-Christoph Steiner -
Jonathan Wilkes -
Mathieu Bouchard -
Si Mills