Re: [PD] Pd 0.50 repeated vis reduces window

2019-09-20 Thread rolfm
ro...@dds.nl schreef op 07-09-2019 12:31: in Windows 10 repeating vis 1, vis 0, vis 1 shrinks the vertical size of the shown window every time further and further. rolf this happens when the menu headers need more than 1 line to be displayed.

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread Christof Ressi
TBO, I don't see the big difference... What exactly do you mean by that? You're right that the Pd *core* doesn't care about z-order, but drawing commands are sent while traversing the glist, which implies a certain order. The GUI is theoretically not required to draw things in the same order,

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread IOhannes m zmölnig
Am 20. September 2019 13:50:10 MESZ schrieb Christof Ressi : >> Pd doesn't care about z-ordering at all and the order of drawing is >> mainly defined by "what needs to be done" (rather than: "how will it >> look like"). > >I don't agree that there is no defined z-ordering in Pd, otherwise you

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread Jonathan Wilkes via Pd-list
> On Friday, September 20, 2019, 7:52:07 AM EDT, Christof Ressi > wrote: >> Pd doesn't care about z-ordering at all and the order of drawing is >> mainly defined by "what needs to be done" (rather than: "how will it >> look like"). > I don't agree that there is no defined z-ordering in

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread Christof Ressi
> Pd doesn't care about z-ordering at all and the order of drawing is > mainly defined by "what needs to be done" (rather than: "how will it > look like"). I don't agree that there is no defined z-ordering in Pd, otherwise you couldn't reliably build GUIs. Just imagine that a background canvas

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread João Pais
> Personally, I don't see the need for this be tackled in Pd, since one > has enough control in the patch to re-order scalars as desired. Rather, > I believe dealing with this is best left to the patch author. > There would be two ways of forcing the author to deal with it: - externally by making

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread Roman Haefeli
On Fri, 2019-09-20 at 12:24 +0200, IOhannes m zmölnig wrote: > > adding z-ordering to Pd probably requires a bit of rewriting of the > current code... Personally, I don't see the need for this be tackled in Pd, since one has enough control in the patch to re-order scalars as desired. Rather, I

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread João Pais
> z-ordering is based on the order of drawing commands (things drawn later >> will paint on top of what is already there). >> > > >> Pd doesn't care about z-ordering at all and the order of drawing is >> mainly defined by "what needs to be done" (rather than: "how will it >> look like"). >> > >

[PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

2019-09-20 Thread João Pais
Hello list, I just uploaded a new version of the jmmmp library, with improvements to the [multiarray] object (also at http://bit.ly/jmmmp_056, and soon on deken). In the help file of [multiarray] I described a problem with the drawing of scalars inside a GOP. Basically, z-order is lost (or

[PD] [PD-announce] jmmmp library Version 0.56

2019-09-20 Thread João Pais
Hello everyone, The jmmmp library of abstractions has been updated. New features and improvements to [multiarray] were added: - read and write audio files - show ID - y-window scaling - fixed a bug in "size" method - configuration file to load at startup - background - general setting for color,