Re: [PD] [SOLVED!] GOP auto-moving issue with Pd Vanilla 0.53.1 under GNU/Linux and Windows

2023-02-26 Thread Linux ROUEN Normandie 

I'm neither a Pure Data specialist nor a developer.
The best I can do, as a user, is to try thinking cleverly.

If I delete the 1st line on three from my reorganized Restore/Coords 
list, the result is still a good behavior of my GOP / patch.

So it seems this Coords was also referring to this canvas.
Why it was added if it's unnecessary ?

Best,
= = = = = = = = = =

Le 26/02/2023 à 16:20, João Pais a écrit :


without going to see the meaning of all coords parameters or how it's 
applied in the file: if both coords statements refer to the same 
canvas, wouldn't it be better to delete the first one?


= = = = = = = = = =

Hello João,

Thanks for your suggestions.
The first ones were not working, always the same jumping GOP issue.

So I spent some more time on analyzing the 1845 lines of my patch.pd 
file helped by this unofficial PdFileFormat article 
.
After a lot of testing I found the culprit, it is #X restore... and 
any associated #X coords... lines.


In my case I was able to fix my issue by modifying the order of 3 lines.

* Original Pd patch file for Restore & Coords: BAD behavior
/#X coords 0 -1 1 1 853 280 1 995 265;//
//#X restore 10 7 pd smpsk;//
//#X coords 0 293.5 1 292.5 850 280 0;//

/ * Modified Pd patch file for RESTORE & COORDS: Now GOOD behavior
/#X coords 0 293.5 1 292.5 850 280 0;//
//#X coords 0 -1 1 1 853 280 1 995 265;//
//#X restore 10 7 pd smpsk;/

It seems to be a question of properly sorting this 3 lines, here 
manually.

But it should be the automatic task of the Pd engine to do it, isn't it!

I will open an Issue on Miller Puckette Git site.

Best, Joe
= = = = = = = = = =

Le 25/02/2023 à 18:41, João Pais a écrit :
it could be that your object isn't in the position it looks like, 
but it's outside (above or below) the canvas, and it's only noticed 
when you click in it - although it should show slider panes in the 
window. You can try to move it downwards or upwards or check the 
patche's text file to see where exactly in the canvas it is.


or maybe not.

= = = = = = = = = =

Hello List,

In one of my project I have the same weird issue under both 
GNU/Linux (Linux Mint, Ubuntu Studio, Manjaro Linux, Raspberry Pi 
OS) and Windows with the use of Pd Vanilla GOP.
It's moving/jumping down/up (y axis only) when 
maximizing/minimizing its windows or changing its y size with the 
mouse.
See here attached animated GIF file (zoom-out) realized with a RPi 
400.


This is true for both zoom-out / zoom-in level.
But its parent patch doesn't have this weird behavior. The x,y 
position of the GOP is not impacted at all.


Removing from its parent patch all the objects, inside + outside 
the GOP, doesn't change this weird behavior.
Note that trying to reproduce this problem from scratch with very 
simple patches+GOP is not always giving the same result. Sometimes 
it's okay but sometimes not. Random behavior seems to be around.


Is there a known bug in Pd Vanilla or something wrong in the design 
of my patch regarding GOP?


Thank you. Best,
Joe-Rouen

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

Re: [PD] [SOLVED!] GOP auto-moving issue with Pd Vanilla 0.53.1 under GNU/Linux and Windows

2023-02-26 Thread João Pais 
without going to see the meaning of all coords parameters or how it's 
applied in the file: if both coords statements refer to the same canvas, 
wouldn't it be better to delete the first one?




Hello João,

Thanks for your suggestions.
The first ones were not working, always the same jumping GOP issue.

So I spent some more time on analyzing the 1845 lines of my patch.pd 
file helped by this unofficial PdFileFormat article 
.
After a lot of testing I found the culprit, it is #X restore... and 
any associated #X coords... lines.


In my case I was able to fix my issue by modifying the order of 3 lines.

* Original Pd patch file for Restore & Coords: BAD behavior
/#X coords 0 -1 1 1 853 280 1 995 265;//
//#X restore 10 7 pd smpsk;//
//#X coords 0 293.5 1 292.5 850 280 0;//

/ * Modified Pd patch file for RESTORE & COORDS: Now GOOD behavior
/#X coords 0 293.5 1 292.5 850 280 0;//
//#X coords 0 -1 1 1 853 280 1 995 265;//
//#X restore 10 7 pd smpsk;/

It seems to be a question of properly sorting this 3 lines, here manually.
But it should be the automatic task of the Pd engine to do it, isn't it!

I will open an Issue on Miller Puckette Git site.

Best, Joe
= = = = = = = = = =

Le 25/02/2023 à 18:41, João Pais a écrit :
it could be that your object isn't in the position it looks like, but 
it's outside (above or below) the canvas, and it's only noticed when 
you click in it - although it should show slider panes in the window. 
You can try to move it downwards or upwards or check the patche's 
text file to see where exactly in the canvas it is.


or maybe not.

= = = = = = = = = =

Hello List,

In one of my project I have the same weird issue under both 
GNU/Linux (Linux Mint, Ubuntu Studio, Manjaro Linux, Raspberry Pi 
OS) and Windows with the use of Pd Vanilla GOP.
It's moving/jumping down/up (y axis only) when maximizing/minimizing 
its windows or changing its y size with the mouse.

See here attached animated GIF file (zoom-out) realized with a RPi 400.

This is true for both zoom-out / zoom-in level.
But its parent patch doesn't have this weird behavior. The x,y 
position of the GOP is not impacted at all.


Removing from its parent patch all the objects, inside + outside the 
GOP, doesn't change this weird behavior.
Note that trying to reproduce this problem from scratch with very 
simple patches+GOP is not always giving the same result. Sometimes 
it's okay but sometimes not. Random behavior seems to be around.


Is there a known bug in Pd Vanilla or something wrong in the design 
of my patch regarding GOP?


Thank you. Best,
Joe-Rouen

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-manageme


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


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

Re: [PD] [SOLVED!] GOP auto-moving issue with Pd Vanilla 0.53.1 under GNU/Linux and Windows

2023-02-25 Thread Linux Rouen Normandie 

Hello João,

Thanks for your suggestions.
The first ones were not working, always the same jumping GOP issue.

So I spent some more time on analyzing the 1845 lines of my patch.pd 
file helped by this unofficial PdFileFormat article 
.
After a lot of testing I found the culprit, it is #X restore... and any 
associated #X coords... lines.


In my case I was able to fix my issue by modifying the order of 3 lines.

* Original Pd patch file for Restore & Coords: BAD behavior
/#X coords 0 -1 1 1 853 280 1 995 265;//
//#X restore 10 7 pd smpsk;//
//#X coords 0 293.5 1 292.5 850 280 0;//

/ * Modified Pd patch file for RESTORE & COORDS: Now GOOD behavior
/#X coords 0 293.5 1 292.5 850 280 0;//
//#X coords 0 -1 1 1 853 280 1 995 265;//
//#X restore 10 7 pd smpsk;/

It seems to be a question of properly sorting this 3 lines, here manually.
But it should be the automatic task of the Pd engine to do it, isn't it!

I will open an Issue on Miller Puckette Git site.

Best, Joe
= = = = = = = = = =

Le 25/02/2023 à 18:41, João Pais a écrit :
it could be that your object isn't in the position it looks like, but 
it's outside (above or below) the canvas, and it's only noticed when 
you click in it - although it should show slider panes in the window. 
You can try to move it downwards or upwards or check the patche's text 
file to see where exactly in the canvas it is.


or maybe not.

= = = = = = = = = =

Hello List,

In one of my project I have the same weird issue under both GNU/Linux 
(Linux Mint, Ubuntu Studio, Manjaro Linux, Raspberry Pi OS) and 
Windows with the use of Pd Vanilla GOP.
It's moving/jumping down/up (y axis only) when maximizing/minimizing 
its windows or changing its y size with the mouse.

See here attached animated GIF file (zoom-out) realized with a RPi 400.

This is true for both zoom-out / zoom-in level.
But its parent patch doesn't have this weird behavior. The x,y 
position of the GOP is not impacted at all.


Removing from its parent patch all the objects, inside + outside the 
GOP, doesn't change this weird behavior.
Note that trying to reproduce this problem from scratch with very 
simple patches+GOP is not always giving the same result. Sometimes 
it's okay but sometimes not. Random behavior seems to be around.


Is there a known bug in Pd Vanilla or something wrong in the design 
of my patch regarding GOP?


Thank you. Best,
Joe-Rouen

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-manageme


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