Thanks all for the suggestions. I did shrink my window around my framing canvas and I'm still only getting ok results. I guess 2 pixels of shift in the window is enough to throw of the scaling enough to make it really anoying...
Miller, please remove the scaling feature! In fact I'd be happy if the patch window size was not used at all and the patch is simply cropped based on the graph bound settings. GOPs don't really need to know what size of the patcher window they were created in do they? Also since the GUI objects don't get scaled, only the coordinate system gets scaled, then I think that is really useless since it will always just jumble everything up (if its scaled down from the patch).
Thanks!
Ben
Ben,
I normally put all the GUI objects as I want them on the canvas, and then resize the window to fit just around the canvas, then save. You can also do this using a text editor and the files and changing the canvas sizes.
Yes, I know these aren't solutions, just workarounds. I agree with you that it shouldn't be scaling like that, but work from some sort of origin.
David
ben@ekran.org wrote:
Hello all,
Could someone explain why I had to make my patch look like (GOP_Patch.gif) in order to make it look like (GOP.gif) in the parent patch? Obviously there is some strange scaling going on plus some shifting depending on the type of GUI object (sliders and radios need to move over more, toggles and bangs end up about where you put them).
Is anyone making GOPs that get compressed in the parent patch? Would it be reasonable to make GOPs work so that the upper left corner of the patch is repoduced (without scaling) in the parent up to the size imposed by the graph bounds. So that the GOP patches actually resemble the patches...
Note I'm still using 0.36
Or I could just be using GOP improperly...
Thanks Ben
-- . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .