[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.
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
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?
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.
SIMPLIFIED ERROR
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.
hrm... ok... well.... there's that then. Here's hoping for patcherargerers.
Thanks john.
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 !