[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.

    • Jul 29 2010 | 5:09 pm
      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
    • 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.
      SIMPLIFIED ERROR
    • 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 | 4:32 pm
      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 !