Forums > MaxMSP

[feature report] Patcherargs is tardy.

Jul 29 2010 | 4:30 am

I don’t get it. Why do computers only act unpredictably when we want them to be reliable? :-(

I searched the archives. Has nobody caught this yet?

Instructions. save patch, reopen.

-- Pasted Max Patch, click to expand. --

Jul 29 2010 | 5:09 pm

where are my manners


Model Name: MacBook Pro
Model Identifier: MacBookPro5,2
Processor Name: Intel Core 2 Duo
Processor Speed: 2.66 GHz

Jul 29 2010 | 6:19 pm

Are the outputs of the bpatchers supposed to be hooked up to the right inlet on the message boxes?

What is the result you expect?

Jul 29 2010 | 6:49 pm

I expect things that execute on load to go in the order of the patcher level. deepest patcher to top patcher.

As it stands, if I use patcherargs in an abstraction, I *can’t* use loadmess to initialize that abstraction from the outside like I would a normal object. Why? Because patcherargs inside executes *after* the loadmess outside.

If you’re some dude and you download an abstraction that won’t take messages from loadmess, you’d say it was buggy.


-- Pasted Max Patch, click to expand. --

Jul 29 2010 | 9:53 pm

Patcherargs have always fired after ALL loadbangs fire. Nowadays I think it’s probably a hangover from Max 4, where patcher arguments aren’t discoverable at patcher loadbang time. We had a lot of trouble with this sort of thing in the oo objects.

So the order is: all loadbangs, inside-out, then all patcherargs, inside-out.

It’s possibly changeable in Max 5 if patcherargs were to be re-coded, but that would break Max4 -> Max 5 patch compatibility.

Jul 29 2010 | 10:01 pm

hrm… ok… well…. there’s that then. Here’s hoping for patcherargerers.

Thanks john.

Oct 05 2014 | 9:32 am

This is still a BIG ISSUE in Max 6!

Could they just at an attribute to patcherargs which controls the loading order?
(So it stays backward compatible)

Face it, they made a mistake !

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

Forums > MaxMSP