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
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 po.boulant@free.fr To: PD-List pd-list@iem.at 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
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 po.boulant@free.fr To: PD-List pd-list@iem.at 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
-
Jonathan Wilkes -
Pierre-Olivier Boulant