[feature report] Patcherargs is tardy.

Jul 29, 2010 at 4:30am

[feature report] Patcherargs is tardy.

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 at 5:09pm

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 at 6:19pm

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 at 6:49pm

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 at 9:53pm

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

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

Thanks john.


You must be logged in to reply to this topic.