|
|
Aug 7, 2010 at 12:20am
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.
|
|
|
Aug 7, 2010 at 12:21am
|
|
|
Aug 10, 2010 at 4:39pm
|
|
|
Aug 30, 2010 at 11:14pm
Can anyone comment on this? Is this expected behavior?
|
|
|
Aug 30, 2010 at 11:29pm
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
|
|
|
Aug 30, 2010 at 11:38pm
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.
|
|
|
Aug 30, 2010 at 11:41pm
Here's a screen capture of what I'm seeing.
[attachment=140185,1044]
Attachments:
|
|
|
Sep 1, 2010 at 6:15pm
Ben – any further comments on this?
|
|
|
Sep 1, 2010 at 6:22pm
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
|
|
|
Sep 1, 2010 at 6:47pm
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
|
|
|
Sep 1, 2010 at 10:00pm
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.
|
|
|
Sep 1, 2010 at 10:25pm
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
|
|
|
Sep 1, 2010 at 11:16pm
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.
|
