DSP Robotics Support

Once again a question that probably is more about the concept of Flowstone's code editor than actual programming. I thought about ways to virtually reduce the sample rate (as it is a part of a bitcrusher). However, while bit depth is acting on the amplitude (y-axis on a graphical representation of a waveform), sample rate acts on the time (x-axis).

Whatever code I come up with, it always requires to know both, the last used sample and the current sample (which may have a gap of say 2, 20 or 200 samples between them), to linearly interpolate between them. This obviously doesn't work, since the samples have already passed Flowstone.

How do you guys deal with code that needs a buffer of samples? Do you just fill an array and live with a delay of n samples? Do you notify the DAW of that delay? Zero delay interpolation seems to be an impossible task (at least for me). What tricks do you come up with?

The very simplest way I know of reducing “sample rate”, i.e. increase temporal quantisation, is to use the hop instruction. Of course there’s no interpolation, but it makes a suitably grungy sound, as per the attached example.

Cheers

Spogg

Yes, I played with it myself, but that's not really what I'm looking for. I don't want the samples to stay on their last values until the next hop. My goal is to simplify the waveform through linear interpolation, but keep the overall shape similar as long as possible.

But it was of course just an example, my question still is how to deal with a bunch of samples, when the code editor is made to deal with just one sample at a time. The delay issue etc.

So you don't want a sample and hold? I'm not quite sure what you mean by this:

tulamide wrote: My goal is to simplify the waveform through linear interpolation, but keep the overall shape similar as long as possible

Can you explain a bit more what you want to achieve?

Ahh, I see what you’re looking for now.

I’ll be interested to see what answers you get because I can’t see how you can apply any maths or processing on a bunch of samples without first having sequentially grabbed the samples!

I guess that if you have maybe a 16 sample buffer you could delay any other audio stream by the processing time for the 16 samples and the DAW should pick that up.

BTW I just made some code which took an average of 3 successive samples then output the result but… big problems. At higher frequencies the amplitude dropped away because the delta between successive sample values got greater at higher frequencies. That’s an hour of my life I’ll never get back, but I learned something I suppose

Looking forward to others’ responses…

Cheers

Spogg

TheOm wrote:So you don't want a sample and hold? I'm not quite sure what you mean by this:

tulamide wrote: My goal is to simplify the waveform through linear interpolation, but keep the overall shape similar as long as possible

Can you explain a bit more what you want to achieve?

Correct, I don't want sample and hold.
I hope it is ok that I make a visual explanation. For me that's the easiest way to describe it. In the image, the assumed original waveform is drawn in blue, red would be the result of sample and hold, while green is linear interpolated and what I'm trying to achieve.

However, it really was just an example to the topic of how to deal with tasks that require a buffer, introduce latency, etc.

Yes, the module will introduce latency, that you should compensate for. If the latency is fixed, you can simply add latency compensation prim in your schematic. It informs your DAW about the latency and the DAW should compensate accordingly (note that some DAWs have problem dealing with changing latency - you should keep it constant).

If it is the case that one of your modules introduces latency and another PARALLEL module does not, you need to compensate by adding delay to the parallel module, thus putting them back in sinc.

KG_is_back wrote:Yes, the module will introduce latency, that you should compensate for. If the latency is fixed, you can simply add latency compensation prim in your schematic. It informs your DAW about the latency and the DAW should compensate accordingly (note that some DAWs have problem dealing with changing latency - you should keep it constant).

If it is the case that one of your modules introduces latency and another PARALLEL module does not, you need to compensate by adding delay to the parallel module, thus putting them back in sinc.

Thank you!

So, in my example, where i would provide the user with an option of how much "downsampling" he wants, it would be better to have a fixed buffer (and therefore latency) of always the maximum amount and find ways in the code to restrict to the real (shorter) buffer size, in order to prevent dynamic latency changes?