Making k-rate inputs s-rate

[Ott]

Is there an easy way to make k-rate inputs s-rate? I want to be able to modulate the pulse width of osc/pwm in audio rate, but when I try I get this ugly tone that I assume is the k-rate limitations. I took a look at the code, but most of it seems to be k-rate already (with buffers), so I'm not too sure where to start. I've also noticed that some k-rate (blue) devices will automatically convert to s-rate (red) inlets/outlets. How does that work?

[lokki]

I've also noticed that some k-rate (blue) devices will automatically convert to s-rate (red) inlets/outlets. How does that work?

that's just the patcher replacing the k-rate object with the s-rate equivalent. no voodoo here
if there is no s-rate version the colours don't change.

[Ott]

Another question: Are the blue ports and red ports the same as k-rate and s-rate? Or is there a difference?

What happens when I plug a red port into a blue port? Does the blue port only check the value at 1/16th rate?
What happens when I plug a blue port into a red port? Does it interpolate to fill in the gaps?
Do I want to keep my entire signal chain composed of red ports if I want to retain audio-rate modulation abilities?

[jfcharles]

blue, (and green) are k-rate. red input or output means the signal is s-rate.
Check out the User Guide, sections "Connection (and Inlet/Outlet types)" and "Connections between different types"

Axoloti User Guide

Overview Axoloti consists of both hardware and software which work together to provide a virtual modular environment. With the Axoloti software we can create 'patches' which are uploaded to the Axoloti hardware and then run on the hardware. When we upload these patches to the Axoloti board, we are actually uploading native code for the hardware and not interpreting these patches on the board. This means it runs very efficiently, close to the efficiency you would get if you wrote the code spe…

[jfcharles]

What happens when I plug a blue port into a red port? Does it interpolate to fill in the gaps?

No, you need to use the conv/interp object to convert from blue to red with interpolation.

[jfcharles]

Do I want to keep my entire signal chain composed of red ports if I want to retain audio-rate modulation abilities?

That's an interesting question. I depends on the kind of modulation you use, and how precise you need it to be. For instance, if you modulate with a k-rate sine wave, and use conv/interp, you are going to get a "reasonable" version of a sine wave. But if you need a sawtooth with a vertical edge, you can't use lfo/saw cheap: the conv/interp will transform the vertical edge to a line, going from 64 to -64 in 16 samples. In that case, you would use an osc/phasor.

[Ott]

That's an interesting question. I depends on the kind of modulation you use, and how precise you need it to be. For instance, if you modulate with a k-rate sine wave, and use conv/interp, you are going to get a "reasonable" version of a sine wave. But if you need a sawtooth with a vertical edge, you can't use lfo/saw cheap: the conv/interp will transform the vertical edge to a line, going from 64 to -64 in 16 samples. In that case, you would use an osc/phasor.

So S-rate -> K-rate is reducing the sampling rate to 3000hz? Does that mean there will be aliasing artifacts, or is it more akin to a lowpass?

Also, I figured out how to make my oscillators audio-rate. You have to embed it (so your changes only affect it), change the inlet type to frac32_buffer, and make some code edits:

[ricard]

So S-rate -> K-rate is reducing the sampling rate to 3000hz? Does that mean there will be aliasing artifacts, or is it more akin to a lowpass?

Aliasing. Essentially, k-rate signals are sampled at the k-rate, so using them on s-rate inputs will be the same as if they'd been downsampled.