Re: [PD] GOP-GUI-dynamic patching weirdness

2013-02-03 Thread Pierre-Olivier Boulant

Thanks Jonathan,

Very nice indeed.
Each time I see data structures I realise how elegant they are. I really 
feel I should look into this...  some day... :)


I was mostly pointing out the little problems I encountered this afternoon.

Cheers
Pierre-Olivier





On 03/02/2013 21:40, Jonathan Wilkes wrote:

Might be easier to just instantiate a scalar
within the patch.  (See attached)

Benefits
* you can select it in editmode and move it where you want
* you can change multiple values at once in a ds array (just like a
"Put" menu array) if there's just a y value, as in my example
* you can add or subtract sliders as easy as scrolling the number box to 
[setsize]

Drawbacks:
* no "jump on click" (this would require scalars to report _where_ they were 
clicked)
* small 10x10 draggable "hotspot", just like "Put" menu arrays
* can't simply "get" the array values as a list-- you have to iterate through it

* hard to "gop-ify"


-Jonathan



- Original Message -

From: Pierre-Olivier Boulant 
To: PD-List 
Cc:
Sent: Sunday, February 3, 2013 2:37 PM
Subject: [PD] GOP-GUI-dynamic patching weirdness

Hello,

I've been trying to make a copy of the Max object called
"multislider". From what I gathered it's a set of sliders that
resizes itself according to the length of the list of values it receives. It was
a request posted here:
http://codelab.fr/3980
Sounds like something doable with dynamic patching!

I had to build some pack-like and unpack-like objects that I could create with a
variable number of in/out-lets respectively. That bit seems ok.

But there is some weirdness on my system. (Win 7, 64bit with Pd-extended 0.43.4
win32).
- First when I start the example patch I have no problem as long as I play with
the sliders.
But when I start to change the values of any of the numboxes, that's when
things start to look ugly. See the screen shot.
- I have patch cords supposed to be hidden that show through outside of the GOP.
I can live with that.
- More concerning I can't see the cursors moving at all. I have to open the
abstraction to have them drawn in the subpatch of the abstraction. And then once
I close the abstraction, the cursors are properly drawn in the example patch. I
can play with them or with the set of numboxes that corresponds to the current
number of sliders. Once I change set and the abstractions is resized the cursors
are set to zero and won't move.
In any case the values are still flowing through the abstractions fine, but, you
just can't see the cursors of the sliders.

Maybe mixing GOP/GUI and dynamic patching isn't such a swell idea... ;)

Anything worth reporting in the bug tracker?

Cheers
pob

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list


--


~Pierre-Olivier Boulant ~
-o- www.puffskydd.net -o-
~   www.flickr.com/pob31/sets   ~
-o-www.lepixophone.net-o-
 



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] GOP-GUI-dynamic patching weirdness

2013-02-03 Thread Jonathan Wilkes
Might be easier to just instantiate a scalar
within the patch.  (See attached)

Benefits
* you can select it in editmode and move it where you want
* you can change multiple values at once in a ds array (just like a
"Put" menu array) if there's just a y value, as in my example
* you can add or subtract sliders as easy as scrolling the number box to 
[setsize]

Drawbacks:
* no "jump on click" (this would require scalars to report _where_ they were 
clicked)
* small 10x10 draggable "hotspot", just like "Put" menu arrays
* can't simply "get" the array values as a list-- you have to iterate through it

* hard to "gop-ify"


-Jonathan



- Original Message -
> From: Pierre-Olivier Boulant 
> To: PD-List 
> Cc: 
> Sent: Sunday, February 3, 2013 2:37 PM
> Subject: [PD] GOP-GUI-dynamic patching weirdness
> 
> Hello,
> 
> I've been trying to make a copy of the Max object called 
> "multislider". From what I gathered it's a set of sliders that 
> resizes itself according to the length of the list of values it receives. It 
> was 
> a request posted here:
> http://codelab.fr/3980
> Sounds like something doable with dynamic patching!
> 
> I had to build some pack-like and unpack-like objects that I could create 
> with a 
> variable number of in/out-lets respectively. That bit seems ok.
> 
> But there is some weirdness on my system. (Win 7, 64bit with Pd-extended 
> 0.43.4 
> win32).
> - First when I start the example patch I have no problem as long as I play 
> with 
> the sliders.
> But when I start to change the values of any of the numboxes, that's when 
> things start to look ugly. See the screen shot.
> - I have patch cords supposed to be hidden that show through outside of the 
> GOP. 
> I can live with that.
> - More concerning I can't see the cursors moving at all. I have to open the 
> abstraction to have them drawn in the subpatch of the abstraction. And then 
> once 
> I close the abstraction, the cursors are properly drawn in the example patch. 
> I 
> can play with them or with the set of numboxes that corresponds to the 
> current 
> number of sliders. Once I change set and the abstractions is resized the 
> cursors 
> are set to zero and won't move.
> In any case the values are still flowing through the abstractions fine, but, 
> you 
> just can't see the cursors of the sliders.
> 
> Maybe mixing GOP/GUI and dynamic patching isn't such a swell idea... ;)
> 
> Anything worth reporting in the bug tracker?
> 
> Cheers
> pob
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> #N struct multislider float x float y array a bar;
#N struct bar float y;
#N canvas 15 19 642 622 10;
#N canvas 606 213 450 300 bar 0;
#X obj 113 42 struct bar float y;
#X obj 112 105 filledpolygon 900 0 1 -5 -5 5 -5 5 y(0:127)(0:127) -5
y(0:127)(0:127);
#X obj 88 166 drawnumber y -5 y(0:127)(0:127);
#X restore 365 144 pd bar;
#X obj 428 -1 namecanvas foo;
#X msg 197 281 traverse foo \, next;
#X obj 197 303 pointer;
#X floatatom 74 226 5 0 0 1 no_of_sliders - -;
#X obj 197 255 loadbang;
#N canvas 789 224 450 300 multislider 0;
#X obj 83 96 plot -y y(0:127)(0:-127) a 0 0 0 0 25;
#X obj 66 30 struct multislider float x float y array a bar;
#X restore 365 166 pd multislider;
#X msg 429 21 \; foo scalar multislider 20 120;
#X scalar multislider 20 120 \; 118 \; 127 \; 127 \; 122 \; 99 \; 84
\; 58 \; 58 \; 48 \; 44 \; 54 \; \;;
#X obj 74 331 setsize multislider a;
#X text 301 67 <-- click-drag to change multiple values at once;
#X msg 365 196 traverse foo \, next;
#X obj 386 248 pointer;
#X obj 386 300 getsize multislider a;
#X obj 386 362 until;
#X msg 441 352 0;
#X obj 386 270 t a a;
#X obj 386 428 element multislider a;
#X obj 386 394 f;
#X obj 416 394 + 1;
#X obj 386 450 get bar y;
#X obj 386 505 t a;
#X obj 365 530 list;
#X obj 365 554 print;
#X obj 365 221 t b a;
#X obj 386 321 t anything bang;
#X text 489 194 <-- get list of values;
#X obj 386 483 list prepend;
#X connect 2 0 3 0;
#X connect 3 0 9 1;
#X connect 4 0 9 0;
#X connect 5 0 2 0;
#X connect 11 0 24 0;
#X connect 12 0 16 0;
#X connect 13 0 25 0;
#X connect 14 0 18 0;
#X connect 15 0 18 1;
#X connect 16 0 13 0;
#X connect 16 1 17 1;
#X connect 17 0 20 0;
#X connect 18 0 19 0;
#X connect 18 0 17 0;
#X connect 19 0 18 1;
#X connect 20 0 27 0;
#X connect 21 0 22 1;
#X connect 21 0 27 1;
#X connect 22 0 23 0;
#X connect 24 0 22 0;
#X connect 24 1 12 0;
#X connect 25 0 14 0;
#X connect 25 1 15 0;
#X connect 25 1 27 1;
#X connect 27 0 21 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list