R_Gol

number~

flonum

message

ezdac~

gain~

gen~

param

cycle

Is there any way to transfer a numbers into a gen patch at audio rate using the param object and a message (param name $1) ?

when using a "in" inside a gen patch I can transfer data at audio rate but when using message $1 I cannot. Any way of doing so using param?


 
Is there any way to transfer a numbers into a gen patch at audio rate using the param object and a message (param name $1) ?
when using a

transferring-a-message-inside-gen~-at-audio-rate

control messages in max will *never* go at audio rate. Only a special type of data : signal vector, can be transmitted at that rate.

If you need to "transmit" that number at an audio rate, there must be a specific reason why, specifically : it must have to change at a sample-accurate timing. That kind of timing cannot be triggered by any control data (so not from any user interface, for example). 

Now if you send any named parameter to gen~, what will happen is : that number will be taken into account inside gen~ the next time an audio vector is calculated. For the duration of that next vector*, the parameter value will remain the same and be "converted" to an audio signal ; which will stay at that value for the duration of that vector and be updated at the start of the following next vector, if it has been changed. (*a vector of audio signal is very short, usual values are 64 to 512 samples at 44100 samples per second which last from 1,45 ms to 11,6 ms ; it's way under any human reaction time)

In short, you must give more details about what you want to do, because you're probably not thinking about your problem in a way that is adressable in Max !... (not that it's a Max limitation, it's just not how audio programming works)

control messages in max will *never* go at audio rate. Only a special type of data : signal vector, can be transmitted at that rate.
If you need to "transmit" that number at an audio rate, there must be a specific reason why, specifically : it must have to change at a sample-accurate timing. That kind of timing cannot be triggered by any control data (so not from any user interface, for example). 
Now if you send any named parameter to gen~, what will happen is : that number will be taken into account inside gen~ the next time an audio vector is calculated. For the duration of that next vector*, the parameter value will remain the same and be "converted" to an audio signal ; which will stay at that value for the duration of that vector and be updated at the start of the following next vector, if it has been changed. (*a vector of audio signal is very short, usual values are 64 to 512 samples at 44100 samples per second which last from 1,45 ms to 11,6 ms ; it's way under any human reaction time)
In short, you must give more details about what you want to do, because you're probably not thinking about your problem in a way that is adressable in Max !... (not that it's a Max limitation, it's just not how audio programming works)
(I hope that explanation was clear lol)


In your example, you can change numbers arriving in gen~ by a user interface, so you can't manually change those numbers faster than a signal vector size (even from the number~ object), and when they are inside gen~, they are both converted to an audio rate static value (so those two control methods end up in the same effect when inside gen~). If you want "amount" to be a value changed by an external signal generator, then just add an inlet to gen~ and connect the signal to that new inlet. There isn't really a way to "name" a signal path in Max, the thing that would be closest to named signal paths that are conveyed through the same patch cord is the MC objects (like mc.gen~, etc).

input examples.png

 object’s output to modulate the slope of a 

The first example is calculating the result at Gen’s single-sample rate (via a signal rate input), and shows a nice smooth curve. 

The second example is setting the modulation input using a 

 operator, and you can see that the output is stepped. That’s because it’s calculating the value at every tick of MSP’s audio scheduler.

In the third case, we’re sending the inlet a floating-point number we sampled using a 

 object’s second inlet an audio signal, The output looks just like the 

 operator example because the Gen environment is automatically adapting its input and updating it at signal vector rates.

The three gen~ objects shown here are using an MSP cycle~ object’s output to modulate the slope of a triangle operator inside the gen~ patchers. 

The first example is calculating the result at Gen’s single-sample rate (via a signal rate input), and shows a nice smooth curve. 

The second example is setting the modulation input using a param operator, and you can see that the output is stepped. That’s because it’s calculating the value at every tick of MSP’s audio scheduler.

In the third case, we’re sending the inlet a floating-point number we sampled using a snapshot~ object in MSP. instead of sending the gen~ object’s second inlet an audio signal, The output looks just like the param operator example because the Gen environment is automatically adapting its input and updating it at signal vector rates.

Those are the three options.

Thanks everyone for the nice explanations! I clearly understand my options now!

Transferring a message inside gen~ at audio rate?