bug when applying zoomfactor to a bpatcher?

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.

#51692
Aug 7, 2010 at 12:21am

Patchers attached.

#185440
Aug 10, 2010 at 4:39pm

Anyone?

#185441
Aug 30, 2010 at 11:14pm

Can anyone comment on this? Is this expected behavior?

#185442
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

#185443
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.

#185445
Aug 30, 2010 at 11:41pm

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

[attachment=140185,1044]

Attachments:
  1. capture.png
#185446
Sep 1, 2010 at 6:15pm

Ben – any further comments on this?

#185447
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

#185448
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

#185449
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.

#185450
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

#185451
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.

#185452

You must be logged in to reply to this topic.