Forums > MaxMSP

bug when applying zoomfactor to a bpatcher?


Aug 07 2010 | 12:20 am

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 07 2010 | 12:21 am

Patchers attached.

Aug 10 2010 | 4:39 pm

Anyone?

Aug 30 2010 | 11:14 pm

Can anyone comment on this? Is this expected behavior?

Aug 30 2010 | 11:29 pm

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 | 11:38 pm

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 | 11:41 pm

Here's a screen capture of what I'm seeing.

[attachment=140185,1044]

Attachments:
  1. capture.png

    capture.png

Sep 01 2010 | 6:15 pm

Ben – any further comments on this?

Sep 01 2010 | 6:22 pm

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 01 2010 | 6:47 pm

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 01 2010 | 10:00 pm

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 01 2010 | 10:25 pm

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 01 2010 | 11:16 pm

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.

Viewing 13 posts - 1 through 13 (of 13 total)

Forums > MaxMSP