Wondering about the "enable 0" hidden feature of all signal objects
One can put some objects inside a subpatch and use mute~ or pcontrol, in order to free the cpu. But as an alternative, I was wondering about the "enable 0" hidden feature of all signal objects : A "enable 0" message sent to a signal-domain object stop its process to free cpu, while "enable 1" put it back on. (see patch)
But looking at the maxmsp doc, this feature doesn’t appears anywhere, plus it doesn’t appears in the message list that you get by control-clicking on an object input… (the only "enable 0" found is about pcontrol) Does this mean that this feature is not really stable, or that we are not supposed to use it ? Or is it fine to use it anytime on shared patches ?
P.S : in this patch, it look like there is some residual process working when all is disabled, anybody knows why ?
----------begin_max5_patcher---------- 2495.3oc4cszbiaiD9r7uBUp18lWU38i85dHW2pRkSo1ZJJIZatQhzQh1YRR k829RBPIR8fxTDXzzFXNnQlTj7Ce.MP2M5t4e9vjYKJ9Z5tYS+mS+4oSl7mO LYh4P0GXRyeOY1ljutbcxNyOa1lzc6RdNc1i1yUl90RywSySVrNc5eCu+Lul Tt7kr7m+x1zkk1m.FSlidbJkQq+OEdt.U8OwiSI34no+mlKL+sMY4qSKMOOR yAyVYdJEK9u+CsX+i3oh7x7jMolS8Co4oumLq8lT7V496Bt4n1CU96ulZAzr YGdp02qcY+g4D0vr9n+0COT+wiCjZxS+sJ7cFyrH6WeKY0+6J7hvPKBNcNVg UD1iSwH5bUM4PqHGTeji3BjizejytrmySV2CEUAJl.Kn2SdRIL7DQ3AdREv7 DFwqIJtV4AhRGxDEwLSDWncmnvHTHyTLogoXDevT3PloDLCSg49foHgLSoT0 LESo7ASQCXlhfLReLAxGLEKjYJhYoOFE6ClhGxLESaXJDyGLk.9LkSVtnMSp STRWrbAijgloKXFxnSN1KxapHPu.kWj2BZsxUVsx4dvNOLFEz5EfMLEQ5ClB G95EvQ9PCJLIn0Kv3MJlj5ClJn0JWX7GEi4k4oBZsxUVsxw9vRObHqUNEYV6 ip7gGovhPloHFcwoBe3QJ7mW2lu68mt5dKvrK7IaUPWfmSnHtRdMVhdNKIu8 onXe.I83U+FnLATPL5uSoHWLATx+bYA3GM5RWokP0GxJINl1tMViczk3y9nq QRgM1E1wy5ilBkQJEJkyqrqVhk09c2nMlTPcfGUwIOJYrVoYrvIoYcjRgXql tBgyRyJTjRgD0AoYFyXutT6fzrBGo7nRdPZlxvtHMqHQJExM6PIU6txyJZjR gUFdrWZlJ3tyir3jG4V6NDH2USTwiY633Hs0uAXWriSIBJ633R0g0J31fhZz ithTiP318Sm2wu4ilBiT6O3BRqcbLoy1wohTiPDDcqcb1.2arTnNRMBoZQAi cbZoyRy5H09CAl1ZGm08yNYGmlDqd2hzZGmzIerpiTiPD1LNgQbW4YcjZ+gf KZsiSKbWZ9SuQHOstnBeWaGJwJaDeYixYS.DR6ihvmSQzaen1dKUdYwyKKVW rsIfppezsezsa5LtrpUkTVSaKRxeteKS1+bpG9z4IglqjUCFTOdwu00.qxsY 6Vlr1bCQy0MGcQw1UoaGFzWljWQ4UnLsK+UceqNTy8c+c8iHiQz6urXylz7x yDi96Wa.gMQu3FCEv5ae.wsKyf7mkk80h+W+6eZ5OUlsN6ORJyJx2e90Y4oK KdKur63xKEaHRZqThja821MPJR52SRomISe8pSKzD30llJZ+XgK2fQWHXE3C oE+R1pUo4c4Lm7Fg9fHuoEktsgSZHkpeb15z2S2tqdDP6sexrNdBj1Lt21GK sQTMm01zqkTWWr7WRW0ooOY1pzmts6Rwqo4sWApQLu8ii+kY4utMcW0Ha6v2 SdxIust7KWd1uiO+SIKS68hubmzjYOuMaUQdMJN5RqO79mW0LVllZ8ms.27K xSd8BWbYQw5EIaeOaW1h0oG0YTMVNIOaSRYZYlEPDzgqKayqayrhqnNWPa5A 2o69H4hiN9U8T2wBI3tG8hFPXSKVSq2rajXYGNnO2zcl7R2GyU5L5UF4CjSt jrx9SXlMw9kGGICdzLLGSfUKUuxrLcmSdooc6ifsdrhXihQq7D9ZDL9xDL4a CAejBHe+H4MokaKl1lcm857JCY1DCL5CdUt6T6CdHKMnYzjU6plq8scSW95a icnqvnz.lXzZv9GWeraOLMazLM4pSNTo.sYtz6CYae9ezzoR6Tnn8qlbxZJC Ubm2Omf5bl8pKVeYytPascsr598dVjwzLpO+kIgcEusc4dNuQvY5wsnUo6Jy xOrz9Oena+jeWq9RcaDaxV8ZQUGYC7rVJ7gcZ2JpwCD0TPgZx.QMFTnlMPTy 8HpaNXE7spPuK48zUeo5oTIa9kjxJSVW7VoUDnqJ0CQAxqctOR60JcsWjrtQ e9C2jit0moT6MoI7Cs7fmr07GSSmdh8lS+sWpL8X5x0YK+kpI7lV9R5zxhme dcEg1uQXZyBGVGzPwz4U5AivjazdbI96oomNELyV0o4NkNqbcvkMqVUgEdHc 5DgbdGZ8cQSv44HOExYcn0l.F1ConhHjy4PoMUdTdHkCEzftvNYbIB0GYFsH jS3PbyJ6DOjFcBdPWWmrkjOjOlhRDzkuAinGQ5gx2fHjKReXo0qhLOT+qDpf t3MXbaEwGIEsPGp4uJuwwzcJSQiMjCXpnNtms4upvoZuJSGVg8bmzWsoBgL1 AWbTrFyt1cfU5dpcviz.kj2I8UqqJatFZU7XMPI6j9pX6daNZJLVCTxl8ERq cWZNVCTxNouJtIYPPJG3QdjxicReUaT9LZFLVqrD1XpCSbW0YdzVYIZyd0lp otSxxe5s.wtyZerKJslYPP6+b3w3p7FMivFlEeKZJLprMDMGSSQbuZJiavMy 1xnT2UcmPiYSqw1f6uYn+XsslPBssS0VzjYDeTI7kQvtU3i2WG3ftFJ2Lirz GUw0ftDJysdMk4gxxMAE96VAE6gs0gDzuVSzh8U.e2E8DAckl1ponWdWcDzu .JnMY.mOJfqAc0S1Fld06Wn6DUPWPtU175T5iBxMIreilvrkAIqJ5i9EZBNn 1NPlsJHwLCV3NU+KizJ3CytsKTj6k+xHs18v5TCjHJ2q9k3Xceo6TCjvJjS6 ePjxf1RfTEk4rrbjtAL7NU.IRS.L4x1GDqUVuNE.olWssiNDvh0ZSnMcY4t6 o+HMvH3cJ+Q3lnJ2EQYvFhNle3wojqkUOMQKa31ySAWQ2LmrubB8njB87Tq7 xoU4Y8zCFSxAfIB4thoSnfdvD8thoSnfd56j.DSJ.hIM7vTsu7AGlv.ruS.P LwAHlX.DSPbNS.t1hFdPBifGlTvCRB3AII7fDGdPhBPMLgGjtuqovzCYrj.f XRAPLIAHln.DSb.hIHJ2g.HlH.DSX3gI18c9I9PvjPCPLAQdRBPLI.Hl3.DS L.hIJ.wDAfXBCPLceWCdP6e.SCu8OfemcnxI501iEm8MY.9aBnj7g3qf66DT CCSR.hIE.wj.dXRg.Hlv.ruSCPdhBPLAv4mT2WkUTCYQXMEfXhCPLw.HlP.D SPbLNFdXRIAHlz.DSJ.hIN7LlRIfGlj2WdROn4Bj.DSJ.hIM7vj482C7.EFh fh.QPQgHnXPDTbHBp6bHqfjCJHjkfDUvjq3fDULPhJJHQEAjnBCRTgfHpPZP hJE71KFs.dX5T571.U0e7WO7+AfcFwiK -----------end_max5_patcher-----------
|Alexandre wrote on Sat, 25 July 2009 19:55|
|But as an alternative, I was wondering about the "enable 0" hidden feature of all signal objects : A "enable 0" message sent to a signal-domain object stop its process to free cpu, while "enable 1" put it back on.|
As I recall, the enable message was used internally by one of the early MSP mute/unmute techniques, possibly by the selector~/begin~ combination.
It’s probably not documented because you’re not supposed to use it in normal patches (and the selector~/begin~ thing is sort of deprecated nowadays, too). There’s a real potential to end up with unwanted noise in the lines if an MSP object is arbitrarily disabled.
And, yes, there is always some residual MSP processing, even if all objects are disabled. The MSP signal chain is still processed, and every object in the chain is called; the savings are that the object returns immediately without actually doing any work. See the SDK examples to see how this works.
But the CPU usage is very, very close to zero when everything’s disabled.
So i guess it means that the only reasonable way to momentarily suppress few audio objects, is then to put them in a subpatch using mute~…
But then, in my case, this will be a lot of subpatches containing only few objects (knowing inlets/outlets will also cost cpu), and my patch will not be as clear to look at…
I’d recommend using a one voice [poly~] but this might not be useful to you. Why do you want to remove lots of subpatches containing only few objects from the processing chain. Maybe if you shared your reasoning someone would be able to help more.
> Why do you want to remove lots of subpatches containing only few objects from the processing chain.
That’s because these a lot of little processes in it, connected as a tree, i need to choose between some of them. Plus i’m building all this from inside a 60 voices poly~…
> I’d recommend using a one voice [poly~]
what would be really the disadvantage of using subpatch/mute beside this one voice poly~ solution ?
If you have a situation where you want to choose one subpatch from many to insert at a particular place in your signal chain you can dynamically load one in using [poly~] without disrupting the DSP instead of including all the subpatches you might want and then bypassing/routing+muting all the ones you don’t want. Again, this might not work for you as I don’t know what you’re doing but if it is helpful to you then great.
And woooooo 60 voices, is this some mega performance patch and when can we hear something from it?
The thing is that all my little processes are differents so i cannot put them all inside a poly~
(which would be then inside my first poly~ : By the way, it is ok to use a poly inside poly ?)
-> And also, it is ok to mute/unmute a lot of stuff every 3 signal vectors ? (granulated sounds) Or is these a cpu cost added by the mute/unmute action at this special instant ?
>is this some mega performance patch
nop, but if it’s as nice as my resonances shared here last week, i’ll post it here too.
Yeah as far as I know recursive [poly~]s are fine. I’m not sure how many levels deep you can go down before it gets a bit crazy, I assume it all depends on the amount of work each one is doing and the number of voices.
I liked your resonance patch, it made some nice sounds so I shall look forward to seeing this one make an appearance on the list.
Ok, one poly inside the poly will be fine but i’m not sure i’m gonna use it for now.
Well, if somebody knows, i still have this question that is growing in me : it is ok to mute/unmute a lot of stuff every 2 signal vectors ? (shorts granulated sounds) Or is these an additionnal cpu cost added by the mute/unmute action at this special instant ?