I'm having some trouble using pcontrol

    Jul 18 2011 | 3:21 am
    I've just finished creating a midi router in Max to replace what I used to do with Apple MainStage. I can load individual patchers (each of which represents a single song) and everything works just fine, i.e, program changes get sent to my hardware, the appropriate keyboard layers get set up and so forth.
    Initialization is done by each patcher responding to a loadbang when I open it.
    Now that I have separate patchers for each song, I want to be able to use an incoming MIDI program change to open the appropriate patch. The pcontrol seems to be the right approach.
    However, I have run into several issues.
    By using a gate indexed by the incoming program change and I am able to automatically close the previously opened patcher and open the new patcher as defined by the program change value. However, the loadbang message in the patcher that is opened is not being triggered, as a result of which the newly loaded patcher doesn't get initialized.
    Any idea how to fix this?
    Thanks, David

    • Jul 18 2011 | 11:01 am
      hi david
      like this one?
      if the stuff inside your patches is too "heavy" you can increase delay time
      you must post your patch if you have further problems
    • Jul 19 2011 | 1:07 pm
      I don't know how to save a patch in the format you used to supply your example. However, I opened your patch, double-clicked on the object 'p 1pat' and inserted a 'loadbang' connected to a simple message 'abc' connected to print.
      I then closed that changed subpatch.
      When I then clicked on the "1" message of your main patch, it opened up the patch called 1pat but nothing got printed in the debug window. In otherwords, that loadbang in the subpatch didn't get triggered.
    • Jul 19 2011 | 1:26 pm
      If you're using subpatchers, they will only loadbang upon opening the parent patch. If you're opening abstractions, they should loadbang each time they open. Simply using "open" and "close" to a subpatch or abstraction isn't the same as opening and closing from a *file*, they stay in memory, just not shown.
      So, to fix your issue, use a send/receive instead, and whatever triggers the opening of your subpatch, use a slight delay after opening and then send the command to initialize.
    • Jul 19 2011 | 5:34 pm
      Yes, I think I just realized that that's the problem. I had configured two of the patches to respond to a Receive message and then discovered that when I opened ONE of the patches with pcontrol, both patches still responded to the Receive, implying the second one was still open.
      I'm not happy about that concept of "slight delay" though --- if there's potential variation, then I'm at risk of it not working unless I use a really long delay, which is impractical.
      Is there no way to actually LOAD and later UNLOAD a patch under Max? What I'm trying to do, by the way, is use external MIDI program changes to load a specific Max patch. When I send a different program change, I want the previously loaded patch to be gone and replaced with the new one.
    • Jul 20 2011 | 11:40 am
      I guess there isn't --- perhaps this is something for Max 6?
    • Jul 21 2011 | 7:28 pm
      How do I open an abstraction under program control?
    • Jul 21 2011 | 10:21 pm
      You script the abstraction into place.
    • Jul 22 2011 | 3:05 am
      I put all my effects into bpatchers and dynamically load them in with scripting. This is my method, the button over opendialog prompts you to pick your abstraction, and loads it into the umenu. Choose items from the umenu to script it into the adjacent bpatcher.
    • Jul 22 2011 | 4:51 pm
      You can use the "load" message to [pcontrol]. Then to get rid of it, you need a [thispatcher] in the abstraction itself, and send it a "dispose" message. check [thispatcher] help file for info and warnings about "dispose". No worries if you're loading an abstraction that's already been saved, but it's possible to delete work if it's in a subpatcher, which is vulnerable to deletion and non-recovery...
    • Jul 24 2011 | 9:55 pm
      ah....i will give that a try....i had tried the wclose message to thispatcher but that didn't work....i'll try dispose instead.
    • Jul 25 2011 | 3:55 am
      Thanks so much for that suggestion --- it seems to work perfectly.
    • Jul 25 2011 | 3:59 am
      great! glad to hear. and the warnings about "dispose" were fun too :)
    • Jul 25 2011 | 11:45 am
      Actually, I couldn't find any warnings about dispose so I'm wondering if I've oped a can of worms. Also, is the forum admin going to get rid of all those spam posts?
    • Jul 25 2011 | 5:17 pm
      maybe it's in a later Max version. The gist is that "dispose" deletes the abstraction/subpatch, so if it's an abstraction, it just deletes the instance, so your file is unaffected. However, it WILL delete a subpatch, and this is NOT undo-able.
      here's the relevant bits from the help file:
    • Jul 25 2011 | 5:23 pm
      Hmmm, I'm using the very latest version of Max 5.
      I have not seen that issue --- I certainly have a sub-patcher inside one of my main "song" patchers and I've tested having the main patcher dispose of itself upon receipt of a bang to a "CloseMyself" receiver and then later reopen it using 'pcontrol load' and the entire patcher, including the sub-patch, opened just fine.
      I would have thought that 'dispose' simply removes the entire instance. Surely it doesn't edit the .maxpat file on the disk to remove subpatchers.
    • Jul 25 2011 | 5:43 pm
      You're right, what I meant was that if you're actively patching and your file is open, you can make a subpatch and "dispose" it. Then if you save and close, it really will be gone. But if you run the patch and then dispose, the actual file won't be modified, that's true...the subpatch will load again next time as usual.
      It's kind of a strange state of affairs, especially as doing "dispose" doesn't dirty the patcher file, and neither does scripting new objects...at least until you move them a bit with the mouse or keyboard (not by scripting)...kind of weird to get used to, as the patch has definitely "changed"...hehe
    • Jul 25 2011 | 5:48 pm
      Oh, I see. No, these will all be predefined patches (songs) that I just want to be able to load one at a time by sending a Program Change message into Max from my sheet music viewer.