bug when applying zoomfactor to a bpatcher?
I believe I’ve found an issue with the zoomfactor message to [thispatcher] when applied within a bpatcher. I’ve attached three patchers to illustrate this.
The basic issue is that zoomfactor appears to behave differently when applied in a patch as opposed to when it is applied in the context of a subpatch. I’m not sure if I can describe this accurately in a paragraph, so hopefully someone can take a look and advise if this is expected behavior.
I do have a workaround, which I’ve also included. This perhaps can speak better to what I’m after.
Would appreciate any feedback.
Patchers attached.
Anyone?
Can anyone comment on this? Is this expected behavior?
Hi Jesse,
Both subpatchers appear the same here on load and on changing the zoomfactor. What OS and computer model? What version of Max?
-Ben
Wow, strange. I checked the patchers again and I still see an offset when viewing the parent patch.
OSX 10.5.8, MacBook Pro 17" 2.8Ghz Core Duo, Max 5.1.5.
Here's a screen capture of what I'm seeing.
[attachment=140185,1044]
Attachments:
Ben – any further comments on this?
Hi Jesse,
I’m puzzling why this would be different on my computer and unfortunately nothing is coming up. The only thing I can suggest is that you trash prefs and do a clean install, just to make sure.
To clean out Max 5 entirely, remove these items:
~/Library/Preferences/Max5 Preferences Folder
/Applications/Max5
Then download and reinstall the latest Max 5 release:
http://cycling74.com/downloads
-Ben
Perhaps you posted the wrong patches? I can see that if I remove the deferlow, the zoomfactor isn’t triggered (or I’m guessing actually that it is triggered and reset to 1. very quickly).
Using deferlow in this situation is the appropriate workaround. FWIW, zoomfactor isn’t officially supported/documented.
-Ben
The screen capture I did yesterday was using the patches I posted – I downloaded them from the forum to be sure I was working with the same ones you are.
Are you looking at the parent patch? The problem I’m seeing is specifically when applying zoomfactor in the context of a bpatcher. I did notice that I had to use deferlow to get zoomfactor to work during patcher initialization, but it doesn’t solve the offset problem.
I didn’t realize zoomfactor was an unsupported feature – I suppose I’ll just continue using my workaround by placing the subpatch UI elements off screen in presentation mode. Just thought it was odd that it works as expected in a patcher context, but not in a bpatcher with offset set to 0 0.
Hi Jesse,
Ah ha, now I see what you mean, the presentation positions were causing me a problem. There seems to be a scaling offset in bpatchers that isn’t there in the normal patcher when using zoomfactor. I’d work around it for now, but I’ll take a closer look.
-Ben
Cool – thanks.
One note: if you try changing the offset of either bpatcher via the standard command-shift-drag in the parent patch you’ll see that they jump to their expected screen positions. Don’t know if that helps at all, but I just noticed it.