AudioMatt

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?

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

feature-report-patcherargs-is-tardy

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?

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.

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.

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.

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

Could they just at an attribute to patcherargs which controls the loading order?

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

[feature report] Patcherargs is tardy.