[feature report] Patcherargs is tardy.

AudioMatt's icon

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?

Max Patch
Copy patch and select New From Clipboard in Max.

Instructions. save patch, reopen.

AudioMatt's icon

where are my manners

10.5.8
5.1.4

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

bkshepard's icon

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?

AudioMatt's icon

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.

Max Patch
Copy patch and select New From Clipboard in Max.

SIMPLIFIED ERROR

johnpitcairn's icon

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.

AudioMatt's icon

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

Thanks john.

hepi's icon

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 !