Forums > MaxMSP

I'm having some trouble using pcontrol

July 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


July 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

– Pasted Max Patch, click to expand. –

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


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


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


July 20, 2011 | 11:40 am

I guess there isn’t — perhaps this is something for Max 6?


July 21, 2011 | 7:28 pm

How do I open an abstraction under program control?


July 21, 2011 | 10:21 pm

You script the abstraction into place.


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

– Pasted Max Patch, click to expand. –

July 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…


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


July 25, 2011 | 3:55 am

@seejayjames

Thanks so much for that suggestion — it seems to work perfectly.


July 25, 2011 | 3:59 am

great! glad to hear. and the warnings about "dispose" were fun too :)


July 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?


July 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:

– Pasted Max Patch, click to expand. –

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


July 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


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


Viewing 18 posts - 1 through 18 (of 18 total)