plugdata
plugdata copied to clipboard
plugdata-team
How canvas inside GOP subpatch risponds to [get_pos( message
Between Pd and Plugdata, there is a difference in canvas response to[get_pos(message, whether or not the canvas is inside a GOP-ed subpatch.
In Pd, a cnv within a GOP subpatch sends its coordinates respective to the parent patch, while in Plugdata they are respective to the children patch.
Ah yeah, this is a bit annoying: to make plugdata work, we need to gl_havewindow flag on canvas to always be true. There are quite a few places where it becomes difficult to get the information we need, without setting that flag.
In this case, that is leading to incorrect output for the text_xpix/text_ypix function. So I guess we can maybe fix it inside those functions?
In this case, that is leading to incorrect output for the text_xpix/text_ypix function. So I guess we can maybe fix it inside those functions?
Do you mean by overriding them in Plugdata ? Anyway, I find the pd behaviour a bit unlogical : Whether or not the subpatch is opened, the cnv object sends different values for x and y. I find that very unpractical when editing a (sub)patch. I would find more logic to check if the subpatch is GOP, and, if yes, search for the topmost (grand)parent patch, and then always output x and y coordinates according to this patch, whether the subpatch is opened or not. But I don't think we can ask for changing that in puredata, right ?
I think they are usually opposed to potentially breaking changes like this. One goal for Pd is to have good backward compatibility for older patches.
I messed around with changing this in plugdata, but unfortunately it wasn't so simple. I'm afraid this difference will be there for a while.
I messed around with changing this in plugdata, but unfortunately it wasn't so simple. I'm afraid this difference will be there for a while.
No problem. I used cnv + [get_pos( to initialize mouse position after capture, but there are other options in plugdata to get patch position.