FINALLY - a way to to OVERSAMPLE your schematic for real!!!

[FlowStoner]

right for correctness,
in the version commented in the second assembler code editor is missing this piece of code at the bottom

Code: Select all

mov eax, 1;
mov prev [0], eax;

[KG_is_back]

While at work, something downed on me. Flowstone implements hop in DSPcode and some prims by having a global counter (specifically it's ecx register), which increments each sample and hop checks if it's divisible by N and then eigher executes or skips the hopped code.
This is a problem for hopped code if it ends up in the oversampled module. It will behave strangely and inconsistently. For example, hop(4) in 8x oversampled code will execute 8 times in a row, then 24 times skips, then 8 times executes,... This is because the global counter increments only each 8th sample from the oversampled perspective.

Because of this I had to include internal separate counter, which counts faster (at the oversampled rate), but separately from regular flowstone counter. This means that hopped modules will behave as expected. However, it also means that hopped code inside the oversampled module and outside it may be out of sync, especially if oversampling ratio is not power of two or changes during execution. (normally all hop(N) code executes in unison every Nth sample)

I also added new upsample and downsample modes. Now you can select different interpolation modes and quality on each input/output. Interpolation modes: none, linear, cubic (currently broken), butterworth (2/4/6/8/10-pole), chebyshev (2/4/6/8/10-pole).

[FlowStoner]

Thank you, time to digest the new changes, and let's start with the experiments and feedback.
P.S. in the commented module it still has some errors in the original clock connections.

[KG_is_back]

P.S. in the commented module it still has some errors in the original clock connections.

oops... that happens when you copy-paste the code and don't check how it affects the number and order of outputs... Will be fixed in next update.

There is one serious problem that I've found impossible to fix. Inside the oversampled code you cannot connect any mono-to-float or any other readout-type-of-prims. They will crash flowstone instantly. It most likely has something to do with how flowstone passes data between blue and green. Unfortunately, I really see no way to circumvent the issue.

BTW, This entire schematic can be modified to achieve undersampling ie. it can be made to do implement hop over section of a schematic, similar in function to the hop(N){} command in the DSP code. Would anyone by any chance be interested in such a thing?

[tulamide]

cubic (currently broken)

I'd be interested in how you plan to implement cubic! I only know it from the graphic area, where it is derived from linear interpolation, like so:

Code: Select all

pseudo code

def lerp(a, b, t)
  return (1 - t) * a + t * b
end

def quad(a, b, c, t)
  return lerp(lerp(a, b, t), lerp(b, c, t), t)
end

def cubic(a, b, c, d, t)
  return lerp(quad(a, b, c, t), quad(b, c, d, t), t)
end

As you can see it is way too much code to efficiently work in the DSP code editor, so I'm trying to find a simpler approach.

EDIT: To visualize it, the bezier curve would be the result of above code with the points being a, b, c, d from left to right.

FCW1070_wmf.gif (3.07 KiB) Viewed 35862 times

[KG_is_back]

I'd be interested in how you plan to implement cubic!

I have no idea. The way I did it was, I calculated coefficients of cubic polynomial from the previous two inputs and derivative, and then interpolated using that as a basis (and also calculating derivative at next point). It introduces 1 sample latency (at original sample rate) Like this:

Code: Select all

in0 = value of next sample (at x=1)
in1= value of previous sample (at x=0)
dx = derivative at previous sample (at x=0)

equation:
out=a*x*x + b*x +c
solve for a,b,c:
in0=a+b+c
in1=c
dx=b
from the solved a,b,c calculate dx at x=1
new dx=2a+b
new in1=in0

All of the above values (in1,dx,a,b,c) get updated every time new sample arrives at original sample rate.
Meanwhile all outputs are calculated as:
x=x+1/oversamplingRatio
out=a*x*x+n*x+c


The result was quite terrible. The intersampled values tended to overshoot by a lot, locking the algorithm in weird oscillations. These seem to depend on where exactly the interpolation starts, giving inconsistent results when stream is reset. I know this algorithm probably has a name, I just suck at this kind of stuff... If anyone is interested in contributing by donating more interpolation algorithms, it would be greatly appreciated.
Available inputs are 1. the input value to oversample - it changes at original sample-rate (ie. for 4x oversampling the value stays the same in groups of 4 subsequent samples).
2. the oversampling ratio (it is green int)
3. original clock - streamboolean that ticks at original sample-rate (ie. it is true each time new input value arrives).

[tulamide]

The code you presented actually is a second degree polynmial, also known as quadratic polynomials. They are equal to my quad function in the pseudo code. y = ax^2 + bx + c

Third degree polynomials (aka cubic polynomials) require 4 "inputs": y = ax^3 + bx^2 + cx + d

That 3rd degree one is equal to my cubic function in the pseudo code. It is just written more easily for the computer to calculate (It just feeds linear interpolation with various combinations of a, b, c and d). Your x is my t, btw. t is chosen, since it represents time rather than samples in graphics.

However, you don't actually need to introduce latency; nobody will ever make use or even hear the first 4 samples after starting the audio engine. Just fill the variables/buffer time after time with incoming samples. The first correct calculation will then happen at sample 4 and then ongoing.

[tulamide]

Sorry for flooding this thread, but I just realized that you might think too complex when trying to solve the equation. If you have another look at my pseudo code, you will realize that a and d are equal to (indexed) sample 0 and sample 3, b and c equal to sample 1 and sample 2.

All you still need now for the cubic function is t.

At t = 0 you get sample 0, and at t = 1 you get sample 3. Likewise, the two segments missing are at t = 0.33 and t = 0.66 (when you want to get the interpolated new values of sample 1 and sample 2)

However, I'm not sure how this could be transformed into efficient DSP/Assembler code.

[KG_is_back]

Well... that was embarrassing brain-fart on my side... mixing up quadratic and cubic

However, you don't actually need to introduce latency; nobody will ever make use or even hear the first 4 samples after starting the audio engine. Just fill the variables/buffer time after time with incoming samples. The first correct calculation will then happen at sample 4 and then ongoing.

There seems to be a miscommunication on what counts as latency. By definition, interpolation needs at least 2 values to interpolate between. That means the schematic needs to wait for the second sample to arrive until it can start interpolating towards it, reaching it exactly when third sample arrives. That is 1 sample latency in my mind. 0 latency would be if the "inbetween" values in the oversampled module started interpolating towards the next value even before it arrives. I have a sneaky suspicion that to do that one needs to have either time-machine or non-deterministic computer, both of which are on my to-do list...just not today...

[KG_is_back]

New minor update. I've added "Moving average" up/downsampling mode. I've setup the schematic so that GUIs of the modules inside the oversampler behave as if they were on the outside (meaning you do not have to mess with GUI of the oversampled module itself, to show GUIs of modules inside it). I also made it so that you can now nest the oversampled modules inside one another.
Another convenient addition is that now, the oversampler transmits the new samplerate to the modules inside it. You can simply replace each "sample rate" prim with a wireless input (hotkey R), name it "sample rate OS" and set its output to be green float. It reports correct values even when oversampled modules are nested.

I do believe the oversampled module is pretty much ready for a "official" full release. I plan to post it to flowstone.guru along with a manual, that describes any dos and don'ts and how to modify schematics to work properly when oversampled.