I'm having some trouble using pcontrol
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?
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
----------begin_max5_patcher---------- 1020.3oc6YssbaBCD8Y5L8efgmcyfDfLz252QlNYDfhsZAgGP1Isc5+dERfM xABxooH217BjY0sydzd1cI9Gu+cNdoUORZ7b+n6stNN+PXwQZq0hSuAGuR7i YE3F4D8XjGpR+h2ptw3jG4R64jBWfu+wAX6KorBBWtJXuUZtbxhc3Cf0Gm6t ZRCgwwbZE6tZRFWAIXz5a7W4BTu76d394AGQ0dd+Y.5MeeEi2P+NQZDJVUmc 0b4eaGQs8doX1FuSa2NLOaKksYHBP.IBBCZeEIg.TCCsGFCWJ2RuOUSwEdxQ 946eW6awqUVfZQdKGGAfwpaIqxQb2T2zwYHvXLTzbAefDnzs7iLI3C9xH1UF QvZHIH7uCBNzyBLUHXAYpRRSCdC4oTE7BTpAylDDIcCkm85mCzrPO4y.3MQh +Ndw4SvEvmPuEhYfpZS9KAyLklrosvfK7BTk9SPOA+dpxUyRWHU0A4yPjkDl YEUMDyClPyoMCTdB.FZCwY.PlS.pJ4FjHgxxqNq1QXlyoy2zWRGmhrAm10vG LRkwa8eVNcJc8NWn.alKqiMjTg.iZlweNRcZhKPUmJzrRuZ6Gotip54JwRnE jCj5FgyLz0c7F5YsmzZoegBkdVX7vyUbIronJ6qj7gtlino56uncoML+zB7G xi5joZpT1vqhmbz38E76lfd0mv83LxzKebB0waSMMuhIklZqs0d+QJxJGo5b WC8xovv6Fa47pphTb8AZCMsfnemHh0wLZIlS3TEnf9mVIsbWMkw02NBCK1ls MY0UEE56lZnCiMTN4.Mi7.MmuUtcCHNsumcXnjlVTefyzjYUkkhqsiTodSvh nTh1PipMOWeFb9RFQr8DAWb7MwQn0HzvILlxqqLfuRh2kyxOY3k5yk3x4Txq t+b0Kl7jTwz7i+D7C3Y3GMN8YxlOcURUPNPkRJp+o9B6u0aQzTzx.MRAk0Gm 49YkwVdqKcVC9.I+NgiI.wcXNulltmqluV5sYyCLt9exoKxykhK5Rld7p16U LsxjwP8L0qZUvLwoIj+lWGLwzlKPI1r4hjnS8Be82E7r+mRf.om.B7sxmntN VIoQ+E0Eb3h8UpcjSrcamEbQsyN02v+R5KsiABBW+Veou0W5+p8ktk7sqstR Qp6P0q25J8stR+usqTvxVrOvG7xauTM2gQRG4K4I1NvYrVS095rdD1+aq4BN cp4jFNkcrdysm94ecGfssz7b8z5dkz7cUhjy5wzidYZN3N6XGGbVBaHSvVnc vVnIX6bOXo.WjIfKxNXy2H0Pj8tUmEbH6QbyGwYI4.zHv4aGvEbECtDSvVrU flQkFRrBzPWuPynbu.q.svqWnALAZvean0ZP75WfIMmqX -----------end_max5_patcher-----------
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.
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.
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.
I guess there isn’t — perhaps this is something for Max 6?
How do I open an abstraction under program control?
You script the abstraction into place.
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.
----------begin_max5_patcher---------- 642.3ocyVE0aaBCD9YpT+OXQ2ioSXRHgrUMo8GXRS6wkpIC3Q7DXivl1zUs+ 66rIPHYkDxhSSyC9TNae7ce9y24mu9JG2HwJpzE8Az2QNNOCdbL9zdbZb33l SVEmQjlE5FKxyobk6n0SpnqTlItC9sfufGUPTwKoknGYpkHz2hKYEJFOEwI4 TzBH9QKba2dFiSiEUbSLlz38mBtRubSf+bIij0tAVhwoH5W2h8Z8xqxY7Lpx fQb2vHY+1DFr+685rZQkpY4stM.GP5OJowpZVYrmGrMDNvLFFpMSgHgt2rm+ b8UZKXFMXBjSeD.++xeEkzBJOAw3RZoBsI2pgp5oBZMlbcQ2ebDUnU3I7g4I erwLel4OdmDOUAxrp9IAlVCBbwns3ClhlWu86n4Epm9j6.XJcTWeKnSj1Pey rB8Md.z2jZiWfE3ubpTRRoVTFM8k4Ae6IilLMniLBOa80tyx8Mg91Fjohz8P Qf5JhvSOZpJvJRF+ATYJzXlN2BJlnJkRv6mM1gI5jtSNP5dzERvAdMIzImV8 I.TKYx08p1uB3nO8G+Zc5OttwT2S+lMIIOzjC27EcVrU5hb+nd3lupGg6A0d rX0lVVVZ5+ijvGABAB59ifFcYjXJ5cXKVbx+rWbpoHcXcUoYXKTbJZWA3Cjx 1bE3pV+jxz80hB+xY++wKd57dG+405JL1pMhZkFwYTRoEk.yO+8m751eJvqW EPMzMutc22WaBqdhc3LonpLtI2W2CA04BcBUBOilnXPI5MKJb6EsjkjP4acF myRJDvqkZkO8ePNXnENDnM6h.M8WEeHn4eQf172tr1fzZS2lZekf1jg.sfKB q4ODnM9jgl1AX96A6nmo -----------end_max5_patcher-----------
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…
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.
Thanks so much for that suggestion — it seems to work perfectly.
great! glad to hear. and the warnings about "dispose" were fun too :)
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?
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:
----------begin_max5_patcher---------- 1117.3oc6Ys0iZiCE9YpT+O3IcejhhyEXR6Kc+CrR8g8ooqF4jXBdahcTrAl oU6+80WR.LjjICEXnsiDJI3KGe72463iO1e+suYjSL6AL2A7AvcfQi9trjQ5 xTkLpofQNEnGRxQbcCcn30r3+0YbccB7CBc4kfu3jR3kLNFP3.7JR9Wb1zr4 LpfhJv5l9mUDT9lpnKKHzbrPKd2lRIo5lJGp26Oc21xVJNnwJoyIeSKcHbRX TH71YMUVhDIKHzr6qvIBybMveh6XPXn5IzW+xychK3er5CtpFGZ.B4.Qxwqv UbBipGqwMUrU1ybcUxKv6V0Ke2H8fDtq3kXbVNK4q3zcmEibRwyelxgUhoa6 htCVO1qoDZYElioBjndFXM3nk4h6svRuIs2f4nDb2cucC8HmrJRJipTD69pJ uYHuSNGMyTKsW2DJprstKXr7XT0JBmDmissKRxLhRJPBrfXTJO2s8jTTVQnB awgoHoXVvSpX441RyT0p1pJUR3SvqIohEZwsCvY4jsKcxxYythdc5rc7Rw4. nqqUk8XENvkya2Z1wsyye+9riqGb+QqMJil1o6i3wxZqqSLhl4r0x1gGpWvL iyol1G5dfKptiKHooF1.bSo+2aeSy2xOGezPtfkkIYScBavtfMugBaG.MZp3 ShL9PMxL81FL4RiLEXNGkgamMp9Hgkyp.vIf+.p9Amb54ltmEt4fQeuPC8DN U+51KI722ZA279yAZCiNKn87bFZ.Dd+FuecbAeuIgWUD9yIMGN8Ehl2f4dZZ 9zYWWr73L8JLGMbGzAb2GZ6NTztGzzrnQXzkmA2GZVfEULYHVWvmPIBxJL.d xIxgujaknNfITaDfdvKeDyDVQgbW2cs+Mtz.7HGHVfA7kw04dbC3ukYRIVHy kBI.OxVVAXqofJB+q2XInbBEmvVZ1Fq2wZ45Z6LAGnzFeOyV0sS3.tOl9DtP MYQ.+A7sflvBAAlMEoSryOXeEYdUVb2p7E0cSYQaRu7Tarf83l4c7gKFOjPF A5sBEow2oQs6iwQqZD569KkXs.CfyGUOd2mUOwzTSImAySuwyqOCiS+VVegB karKly5Hzaaf7NP0cx4VsvRW4spGHUC5.u4x0qRZTx5oOXO1fZgOBcyQQb2F NLnykls.iBRZISlyTsN9bHJOa0WsSrgo+S6S+guT5uJgogo+AWm5+f4OsMSu Bl.pbnFnCv0ICJbvF.+ex0euqSO.+e1m.CODPzwNA7BbUIWAizA87MoZo+WO A7L+QMKqO8e01TRuWpIxfn2iDhJR7RgITn0sAz+Ih22IgOjSK+IOP9tG1Vad VNKFkWuaqMCpylYu9i520l7e7aDZcRt5Bg3qwXAPltF9TcoPP+yykB46dVuT nYFdoYPlEdzWJTex40KE52iKEp2SUv32oO9fZdKXMglxV6bdOgfS2olEYN6Q 3l68rwe70z0eMc8M1GS.lewxV2P5Cl86X15uter12OlBWju9eMkDKm. -----------end_max5_patcher-----------
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.
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
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.