Jesse

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.

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.

bug-when-applying-zoomfactor-to-a-bpatcher

Can anyone comment on this? Is this expected behavior?

Can anyone comment on this?  Is this expected behavior?


Both subpatchers appear the same here on load and on changing the zoomfactor. What OS and computer model? What version of Max?

Both subpatchers appear the same here on load and on changing the zoomfactor.  What OS and computer model?  What version of Max?

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.

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.

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

Then download and reinstall the latest Max 5 release:

~/Library/Preferences/Max5 Preferences Folder
/Applications/Max5

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.

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.

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.

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.


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.

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.

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.

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.


bug when applying zoomfactor to a bpatcher?