begin~ and matrix~
I have a patch where audio is routed through a matrix~, from various sources to effects, filters, etc. I want to use begin~ objects to shut off portions of the patch that aren’t being routed to anything. But begin~ will only respond when the path is plugged into a gate~ or selector~, not a matrix~. How can I accomplish what I want?
Best,
-Zach
Begin~, so the help file says, is quasi obsolete. Take a look at the mute~ and pass~ objects.
_
johan
I have looked at it, although it doesn’t seem terribly helpful for this situstion. Only being able to stop processing in subpatches makes it a pain to implement.
While begin~ is only quasi-obsolete right now, it will be fully-obsolete in the future. @johan‘s advice is a good suggestion.
Cheers
" Only being able to stop processing in subpatches makes it a pain to implement. "
Only if you did not encapsulate sections of the patch you wished to have toggled on and off in the first place: here is a strong argument for not having all activity on the same level in an omnibus patch: the ridiculously difficult task of actually "turning off" parts of a generated dsp calculation chain without the advantage of the parts to toggle off being encapsulated in a separate "routines/objects" would *kill* me as a developer: i’m sure that’s why c74 implemented their dynamic control at the patcher level.
Just grab the sections you wish to turn on and off, find their inputs, connect em patcher "input" objects,same for outputs, then create a patcher to hold it, cut and paste it in, connect up the orig inputs and outputs to the patcher inlets&outlets, and voi-la! (or if you were looking at my screen, "voi-ici"!) : you have the same function, only you can connect one of those mute and pass messages to the encapsulated patchers, and you’re ready to turn it off or "bypass" it’s function on the signal!!! And with the great advantage that you turned a mess of wires and objects into a smaller set of functional "patcher objects", making the design of the top-level patcher much clearer to see and maintain, and made it easy to control which areas are actually calculating.
intelligent "re-factoring" into a "correct" (read maximally useful and reusable) set of patchers/routines/’object’s is extremely important in all programming, and especially in this sort of graphically driven language.
g’luck!
charlie
Yes, I suppose that does make more sense. Really I already understood that, I’m just lazy and don’t want to deal with trying to encapsulate everything in subpatchers. But I’ll suck it up and get to it anyway.
> "don’t want to deal with trying to encapsulate everything in subpatchers"
Don’t forget that max5 is doing it for you : Edit menu > Encapsulate
Thanks Alexandre, wasn’t aware of that! Saves some time for me.
Still, the idea of the begin~ object is a good one, if it could be successfully implemented, and it would be great if it worked for matrix~ as well as for gate~ and selector~. For example, suppose you had a number of arbitrarily complicated audio processes (for the sake of argument let’s say they’re all very computation-intensive) each neatly encapsulated in a subpatch or abstraction as has been suggested, all being mixed together in different amounts by a single matrix~ object, and the levels of each connection in the matrix~ object are being controlled by some separate process. It’s not a trivial matter in that case to disable each process when its level in the matrix~ is at 0, and then re-enable it just before its level in the matrix~ changes to nonzero. (See example below.) However, it would sure be handy if each inlet of matrix~ "knew" when it did or didn’t have any active nonzero output level, and MSP could appropriately enable or disable the part of the parent patch between the begin~ object and the matrix~ inlet.
I think this example illustrates what I mean, and also illustrates that it’s not a completely trivial matter to program all that yourself.