Hi list,
in that vertical column will jump to your mouse position.
Questions:
using "bit masks", exactly how many flags can I scrunch into a floatarg? Arrays use one floatarg in a pd file to keep 1) the "saveit" flag (i.e., whether or not data is saved with the patch), and 2) plot style, to which I've added one more. I'd like to add a flag for "jump-on-click", and if possible one for x/y ticks.
can I add a A_DEFFLOAT for plot color for arrays?
for bar graph arrays, should the user be able to specify inner/outer color for the bar, or is inner color with black outline good enough?
for arrays with a small number of elements that aren't "jump on click" the UX is misleading: with points-style arrays you can only click on a small undifferentiated part of the line. Should I change this so that the hot spot is the entire line?
Thanks, Jonathan
On 29/04/13 20:36, Jonathan Wilkes wrote:
- I got jump-on-click arrays working.
- Implemented "bargraph style" for "Put" menu arrays. (See attached) This is basically a multi-slider.
nice!
do you have both jump-on-click /and/ "bargraph" at the same time?
cheers, y
On 29/04/13 21:26, yvan volochine wrote:
On 29/04/13 20:36, Jonathan Wilkes wrote:
- I got jump-on-click arrays working.
- Implemented "bargraph style" for "Put" menu arrays. (See attached)
This is basically a multi-slider.
nice!
do you have both jump-on-click /and/ "bargraph" at the same time?
one behavior I missed at the time was having all sliders to "align" when you click on the left side, (don't release yet) move cursor to the right side and then release, i.e. jump-on-click and jump-on-index-change kinda behavior..
also having this as an activable option would be nice..
just my 0.02£ y
----- Original Message -----
From: yvan volochine yvan.pd@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Monday, April 29, 2013 3:29 PM Subject: Re: [PD] got jump-on-click arrays working
On 29/04/13 21:26, yvan volochine wrote:
On 29/04/13 20:36, Jonathan Wilkes wrote:
- I got jump-on-click arrays working.
- Implemented "bargraph style" for "Put" menu
arrays. (See attached)
This is basically a multi-slider.
nice!
do you have both jump-on-click /and/ "bargraph" at the same time?
one behavior I missed at the time was having all sliders to "align" when you click on the left side, (don't release yet) move cursor to the right side and then release, i.e. jump-on-click and jump-on-index-change kinda behavior..
That's the behavior I currently have working. The question is whether there is a need for an additional option to turn off the "jump-on-index", thus making it like a bunch of vsliders in a row.
I'm guessing no since you can already just make a bunch of vsliders in a row, although creating an array is much quicker. :)
-Jonathan
also having this as an activable option would be nice..
just my 0.02£ y
-- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://vimeo.com/yv
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 29/04/13 22:07, Jonathan Wilkes wrote:
That's the behavior I currently have working.
cool =)
The question is whether there is a need for an additional option to turn off the "jump-on-index"
naa I meant the jump-on-click option only.. you might want to keep some sliders responding to delta mouse values and don't "accidentaly" jump from 0.1 to 1.0 (like volume..)
cheers, y
----- Original Message -----
From: yvan volochine yvan.pd@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Monday, April 29, 2013 4:07 PM Subject: Re: [PD] got jump-on-click arrays working
On 29/04/13 22:07, Jonathan Wilkes wrote:
That's the behavior I currently have working.
cool =)
The question is whether there is a need for an additional option to turn
off the "jump-on-index"
naa I meant the jump-on-click option only..
Yes, I'll have an option for that.
you might want to keep some sliders responding to delta mouse values and don't "accidentaly" jump from 0.1 to 1.0 (like volume..)
Yes, I'm just wondering whether it would be useful to offer that same security in the horizontal direction.
Suppose I create a 24-channel mixing board as a 24 element bar graph style array. In this case I probably do not want "jump-on-index" as that allows me to accidentally change a bunch of carefully chosen levels in one swoop of the mouse. One can use 24 vsliders but that's a bit clunky.
-Jonathan
cheers, y
-- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://vimeo.com/yv
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: yvan volochine yvan.pd@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Monday, April 29, 2013 3:26 PM Subject: Re: [PD] got jump-on-click arrays working
On 29/04/13 20:36, Jonathan Wilkes wrote:
- I got jump-on-click arrays working.
- Implemented "bargraph style" for "Put" menu arrays.
(See attached) This is basically a multi-slider.
nice!
do you have both jump-on-click /and/ "bargraph" at the same time?
Yep. I'll post the code after I remove all the "post" functions I inserted just to figure out where a click inside a graph actually gets sent.
btw-- Is there a development tool I can use to see which functions are being called? I see gdb does that with "backtrace" on a crash, but I want to be able to see it when the program is running-- something like "tail" for the latest few function calls.
-Jonathan
cheers, y
-- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://vimeo.com/yv
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oh, this is great news! Can´t give you any response on the two first questions but here is a fast response to the other two...
On Mon, Apr 29, 2013 at 8:36 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Hi list,
- I got jump-on-click arrays working. Basically you can click anywhere in
the graph and the array element in that vertical column will jump to your mouse position.
- Implemented "bargraph style" for "Put" menu arrays. (See attached)
This is basically a multi-slider.
Questions:
- using "bit masks", exactly how many flags can I scrunch into a
floatarg? Arrays use one floatarg in a pd file to keep 1) the "saveit" flag (i.e., whether or not data is saved with the patch), and 2) plot style, to which I've added one more. I'd like to add a flag for "jump-on-click", and if possible one for x/y ticks.
can I add a A_DEFFLOAT for plot color for arrays?
for bar graph arrays, should the user be able to specify inner/outer
color for the bar, or is inner color with black outline good enough?
I think the ability to change both inner and outer color for the bar should be preferred.
the UX is misleading: with points-style arrays you can only click on a small undifferentiated part of the line. Should I change this so that the hot spot is the entire line?
I think, yes! Can´t really see situations where a fraction of the line as hot spot should be preferred...
Thanks,
Jonathan
/Björn Eriksson
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-29 20:36, Jonathan Wilkes wrote:
- can I add a A_DEFFLOAT for plot color for arrays?
i would suggest to use A_DEFSYM instead. i think that using floats to represent the color (as in iemguis) has been way to complicated so far. it's really easy to create symbols like "red" or "#FF0000" in the patch, and it's even easier to save them to and restore them from file.
fgmasdr# IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Tuesday, April 30, 2013 3:52 AM Subject: Re: [PD] got jump-on-click arrays working
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-29 20:36, Jonathan Wilkes wrote:
- can I add a A_DEFFLOAT for plot color for arrays?
i would suggest to use A_DEFSYM instead. i think that using floats to represent the color (as in iemguis) has been way to complicated so far. it's really easy to create symbols like "red" or "#FF0000" in the patch, and it's even easier to save them to and restore them from file.
Ok, thanks.
-Jonathan
fgmasdr# IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF/eEkACgkQkX2Xpv6ydvQ38wCfW4Nsg9CTtgdSWkxz19FgX2L8 AgQAnjbq//AetKtljcPt+SXIxNmcKwdy =tn3G -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi List, More "Put" menu array fun:
http://puredata.info/Members/jancsika/array-in-color/view
http://puredata.info/Members/jancsika/bargraph-array/view
http://puredata.info/Members/jancsika/bargraph-sinesum/view
http://puredata.info/Members/jancsika/two-arrays/view
plus:
savable colors for "Put" menu arrays
html-style color symbols savable in last two args to [plot]
Please test. Data structure "bargraph" arrays probably look a little screwy-- haven't worked on those yet.
-Jonathan
I can't (or don't know how to) test these patches. But I would suggest
something else, in case it's somehow related:
arrays, that output the pointer and index for the element in question.
Then it's possible to link user interaction with arrays as well
Hi List, More "Put" menu array fun:
- settable colors for the trace + "jump on click" action
http://puredata.info/Members/jancsika/array-in-color/view
- bar graph with settable outline/fill colors
http://puredata.info/Members/jancsika/bargraph-array/view
- resizing bar graph
http://puredata.info/Members/jancsika/bargraph-sinesum/view
- multiple colored arrays in one graph
http://puredata.info/Members/jancsika/two-arrays/view
plus:
savable colors for "Put" menu arrays
html-style color symbols savable in last two args to [plot]
Please test. Data structure "bargraph" arrays probably look a little screwy-- haven't worked on those yet.
-Jonathan
On 05/15/2013 02:12 PM, João Pais wrote:
I can't (or don't know how to) test these patches.
That's actually a big problem, because it means the only people testing my changes are people who already know how to compile Pd on their platform AND have the free time (and interest) to test the changes I make. It would be much better if everyone who can run Pd can also test out the changes I make.
I should probably tackle this problem before delving into the rest of my goals. Is anyone cross-compiling for Windows using the Debian packages for mingw? That would make it possible to post binaries for windows and linux using a single Debian box.
What about OSX?
But I would suggest something else, in case it's somehow related:
- "change" message coming out the [struct] (or [plot]?) for data
structure arrays, that output the pointer and index for the element in question. Then it's possible to link user interaction with arrays as well
So which [struct] gets the "change" message: the one with the array and [plot] drawing instruction, or the [struct] that is the template for the array (i.e., the one with the "y" field that's actually being changed)?
-Jonathan
That's actually a big problem, because it means the only people testing
my changes are people who already know how to compile Pd on their
platform AND have the free time (and interest) to test the changes I
make. It would be much better if everyone who can run Pd can also test
out the changes I make.I should probably tackle this problem before delving into the rest of my
goals. Is anyone cross-compiling for Windows using the Debian packages
for mingw? That would make it possible to post binaries for windows and
linux using a single Debian box.
I mean I don't know how to test them. But if it's only necessary to
compile pd, maybe that's already written somewhere? Or is there a "how to
test new changes" page?
But I would suggest something else, in case it's somehow related:
- "change" message coming out the [struct] (or [plot]?) for data
structure arrays, that output the pointer and index for the element in
question. Then it's possible to link user interaction with arrays as
wellSo which [struct] gets the "change" message: the one with the array and
[plot] drawing instruction, or the [struct] that is the template for the
array (i.e., the one with the "y" field that's actually being changed)?
I would say the one with the array (and not [plot]). But I'm a surface
user, I don't know what's happening inside.
A con for the template struct: if this template is used also for
individual scalars (which doesn't happen often anyway), it might get
messy. So maybe better think of high level.
João
On 05/15/2013 02:42 PM, João Pais wrote:
That's actually a big problem, because it means the only people testing my changes are people who already know how to compile Pd on their platform AND have the free time (and interest) to test the changes I make. It would be much better if everyone who can run Pd can also test out the changes I make.
I should probably tackle this problem before delving into the rest of my goals. Is anyone cross-compiling for Windows using the Debian packages for mingw? That would make it possible to post binaries for windows and linux using a single Debian box.
I mean I don't know how to test them. But if it's only necessary to compile pd, maybe that's already written somewhere? Or is there a "how to test new changes" page?
There is something on puredata.info about compiling Pd-extended using either cygwin or mingw (can't remember which). It's pretty difficult if you've never done it before.
Compiling Pd- vanilla should be easier. Still, it'd be better if I just post a zip of the binaries for the revisions. All that would require is a user to download, unzip, then click on the "Pd" executable, which means any user that can double click an icon can test the changes.
But I would suggest something else, in case it's somehow related:
- "change" message coming out the [struct] (or [plot]?) for data
structure arrays, that output the pointer and index for the element in question. Then it's possible to link user interaction with arrays as well
So which [struct] gets the "change" message: the one with the array and [plot] drawing instruction, or the [struct] that is the template for the array (i.e., the one with the "y" field that's actually being changed)?
I would say the one with the array (and not [plot]). But I'm a surface user, I don't know what's happening inside. A con for the template struct: if this template is used also for individual scalars (which doesn't happen often anyway), it might get messy. So maybe better think of high level.
Well, there are two "parent widgets" that can receive a click-- the plot trace itself (currently, the black line that represents the array elements) and, if there is a drawing instruction for the scalar elements, that particular drawing instruction like [fillepolygon]. I guess to keep it simple the scalar element's [struct] should always receive the notification-- even if it doesn't have a drawing instruction, it's "y" field is the one getting changed. The [struct] containing the array definition should only receive a notification for things like adding or deleting elements with the mouse-- that is, for manipulations that change the structure of the array itself. (Although even there it would be nice for the scalar element's [struct] to receive a message that one of its scalars died.) Complicated stuff.
-Jonathan
João
Hello,
On Wed, May 15, 2013 at 9:46 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Compiling Pd- vanilla should be easier. Still, it'd be better if I just post a zip of the binaries for the revisions. All that would require is a user to download, unzip, then click on the "Pd" executable, which means any user that can double click an icon can test the changes.
That would be very interesting! I didn´t learnt yet to compile Pd. Please go ahead! :-)
There is something on puredata.info about compiling Pd-extended using
either cygwin or mingw (can't remember which). It's pretty difficult if
you've never done it before.Compiling Pd- vanilla should be easier. Still, it'd be better if I just
post a zip of the binaries for the revisions. All that would require is
a user to download, unzip, then click on the "Pd" executable, which
means any user that can double click an icon can test the changes.
it would be much easier with vanilla, since these are vanilla features.
and that would also test part of your new guide, anyway. I think there is
a page for compilling vanilla somewhere, will search for it later.
I would say the one with the array (and not [plot]). But I'm a surface
user, I don't know what's happening inside. A con for the template struct: if this template is used also for
individual scalars (which doesn't happen often anyway), it might get
messy. So maybe better think of high level.Well, there are two "parent widgets" that can receive a click-- the plot
trace itself (currently, the black line that represents the array
elements) and, if there is a drawing instruction for the scalar
elements, that particular drawing instruction like [fillepolygon]. I
guess to keep it simple the scalar element's [struct] should always
receive the notification-- even if it doesn't have a drawing
instruction, it's "y" field is the one getting changed. The [struct]
containing the array definition should only receive a notification for
things like adding or deleting elements with the mouse-- that is, for
manipulations that change the structure of the array itself. (Although
even there it would be nice for the scalar element's [struct] to receive
a message that one of its scalars died.) Complicated stuff.
although the element being changed belongs to the array defined in another
struct...
and what will make sense when you have an array made of other arrays?
doesn't happen very often, but I do have an example in my data-s workshop.
On 05/15/2013 02:12 PM, João Pais wrote:
I can't (or don't know how to) test these patches. But I would suggest something else, in case it's somehow related:
- "change" message coming out the [struct] (or [plot]?) for data
structure arrays, that output the pointer and index for the element in question. Then it's possible to link user interaction with arrays as well
pd-l2ork has had something like this for some time. Basically, anytime the array is changed via a mouse click it outputs a bang to <arrayname>_changed, so you can simply do [r <arrayname>_changed] and use that to drive logic behind an array values driving something else (e.g. dsp). This is used in the spectdelay~ external help file so you can investigate that one if you like to see how it is implemented.
HTH
And here is a preliminary patch:
---Goods---
jump-on-click, saves with patch
new bar graph style for multisliders, saves with patch
dialog option to hide array name
---Bads---
no color choices yet
bar graph style with 100+ elements-- something weird happens with the colors shifting on some elements
haven't yet made it easier to select elements for arrays that aren't jump-on-click (but it is possible)
---Uglies---
-Jonathan