Params and Inputs : details and differences in GEN (only)
Oct 08 2015 | 7:17 am
Hello, I wish there's someone so nice to help me :)
I would ask about details and differences between Params and Inputs (INSIDE GEN ONLY, I'm not talking about the general max/msp).
Example : 2 gen Abstractions, the first OSC_ABSTR containing an oscillator, the second FILTER_ABSTR containing a filter. The oscillator output will modulate filter's cutoff.
THE STANDARD APPROACH , example : the ouput of OSC_ABSTR is sent to the CUTOFF input of FILTER_ABSTR. Obviously it is ok.
But if I make use of a Parameter (using setparam , ...) instead of Input/Inlet, there will be any inaccuracy or any CPU/performance penalities?
THE PARAM APPROACH , example : OSC_ABSTR output => setparam @name "modulator_signal" => parameter inside FILTER_ABSTR.
Compared to THE STANDARD APPROACH(using outputs/inputs ONLY), will I have EXACTLY THE SAME SAMPLE - LEVEL processing and ACCURACY and no CPU/performance overhead?
I know the STANDARD APPROACH is the most recommended, but is it possible to have an answer to my "PARAM APPROACH" ? As I mentioned above, I'm talking about everything INSIDE GEN ONLY, I'm not talking about the general max/msp behaviour...
Thank you in advance !
- Oct 08 2015 | 3:04 pmHi, since you are talking about gen~, I'll answer.Basically, all operators in gen~ will generate sample-rate or block-rate code according to its inputs, according to sound heuristics, so you should never have to think about it. The exception is that some operators will always operate at sample rate by definition, e.g. delay, oscillators. So, in a top-level genpatcher, the rate of [in] thus depends on whether there is an MSP signal connected to the corresponding inlet of the gen~. The rate of [param] can only be updated via Max messages, so it remains at block-rate. In a gen subpatcher/abstraction (one hosted in a genpatcher), the rates of [in] and [param] depend on the rates of what is connected to the corresponding [gen] inlet or [setparam] in the parent genpatcher.There should be no efficiency/accuracy considerations in choosing between [in] and [param] in a gen subpatcher, it should be essentially cosmetic.
- Oct 08 2015 | 4:02 pmThank you Graham for your fine explanation, much appreciated. :)
