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

[FlowStoner]

In the code editor there is no call opcode,
it can be used in the assembler editor, and does not refer to a function loop.
With the call opcode you can re-call a sequence of byte code and execute it,
so now KG has found a way to store a function directly from the assembler code editor in a specific memory address, and then can execute it with the call opcode.

[RJHollins]

FS 3.04 CrashTest2 results:

Test1 : PASS

Test 2 : PASS

Test 3 : PASS

I hooked up the connection the same as in previous test [hopefully correct] ...

All 3 tests PASSED. No crash, and all displayed integer values related to the given OS rate.

I don't know how this impacts, but you seem to have knowledge as to what these results indicate.

As a FlowStoner, I can only THANK-YOU for what you contribute to this community, and for the HELP You
have graciously provided.

Thanks KG. Will be following the thread.

[KG_is_back]

Excellent. I will post updated version of the oversampled module later this day. There are a few other minor changes I'm working on, along with fully commented version. Current version is uncommented, to make it easier for users to add more inputs/outputs - comments mark where should the user continue the pattern to add more inputs/outputs (it should be easy to do so even if you don't know any assembler, just copy paste what is already there and rename variables).

Awesome. Now that you spotted the issue, I can't wait to hear the difference in oversampling. Btw, if it doesn't bother you too much: What exactly is the difference between your "function call" and the loop function of the DSP code editor?

As you suspect, the effectively achieve the exact same result, but through different means. The loop in DSP code is actually a simple do-while loop. Here is its assembler code with corresponding C code:

Code: Select all

push eax;         //   {
mov eax,10;         //   int counter=10;
start0:            //   do
push eax;         //
   //looped code   //      //looped code
pop eax;add eax,-1;   //   counter--;
cmp eax,0;jnz start0;//   while(counter!=0;)
pop eax;         //   }

It uses RELATIVE jump - the "jnz label;" instruction. During compilation, the compiler replaces the label name with integer constant, that corresponds to position difference between the "jnz" instruction and the instruction just after the label. This kind of looping only works within the same ASM module, because labels apply only within the same block of code (aka you can't use them to jump form one code/ASM component to another).

My code uses different approach. It sort of cheats - it uses "call" instruction which does ABSOLUTE jump (and also pushes current code address onto stack, to be returned to later). The first ASM module obtains the absolute memory address of its own machine code (by calling the "call of cuthulu" function which is saved in the string within the ruby component). The second ASM block then uses that value to do absolute jump to the first asm block. Normally this would be done via dedicated ASM instructions for absolute jumps (which are unavailable in FS), but it can be via "call" instruction, which essentially does the same thing.
Corresponding C code would look something like this:

Code: Select all


//////first ASM block
int c=0;
void* codepoint=&&label; //move position marked by label: to void pointer variable
label:
c++;
if(c==oversampling)
{
c=0;
codepoint=NULL;
}
... //the rest of the code is just moving the inputs and preprocessing them for upsampling
///////

//the oversampled code

//////second ASM module
...//first the code post-processes the outputs after downsampling

if(codepoint!=NULL) goto *codepoint;
///////


[KG_is_back]

OK, this should be more-or-less the next-to-final version, until Martin has something to say about the up/down-sampling filters. I would prefer if user could specify the quality of up/down sampling per input/output, so the user has option to sacrifice speed for quality where he deems fit. Filters in current version are massive CPU Overkill with mediocre result...

[FlowStoner]

excuse Tulamide if I have not correctly clarified your question,
thank you very much KG with the comments now everything is clearer to me too,
I wondered if this would also work in poly-section, because if it has to be,
filter optimization must guarantee all four process channels,
ok experiment day ....

[RJHollins]

Just doing a quick check on this latest version.

It's working GREAT !!!

The 'bit crusher' section is a little confusing. Fully Clock-wise sounds strange, but backing off a bit it snaps in
to a better sound. The readout off the wireless link that sounds natural is:

Code: Select all

1.20289e+007

2nd. I used 4x oversampling. The sonic difference/improvement is dramatic. Even the PINK NOISE has the sound I'd expect. [PinkNoise always sounded 'not right' [upper harmonics] with FlowStone generated. Always ended up using a Wave file]. Now I need to A/B the two.

Butterworth filters. Wonder how these are influencing the UP/Down sampling.

Anyway, very much following this thread.

Mainly wanted to report it's WORKING

[KG_is_back]

The 'bit crusher' section is a little confusing. Fully Clock-wise sounds strange, but backing off a bit it snaps in to a better sound.

Yes, that has a very simple explanation/excuse. After releasing the initial version, the crowd demanded BLOOD!!! -
wanting to see what this oversampler is capable of... So I hastily put together the first effect with notorious aliasing issues that came to my mind, which was a bitcrusher. I didn't really bothered to properly scale the controls in any sensible way.

Butterworth filters. Wonder how these are influencing the UP/Down sampling.

They are there to remove low-pass the signal and remove aliasing. The upsampling actually does no interpolation, so the upsampled signal contains a lot of crap in frequencies above the original nyquist. Low-pass filter simply removes that -> interpolates the signal. In Downsampling the same thing happens in reverse - > the upsampled schematic creates frequencies that end up above the original nyquist frequences, so you need to low-pass them before down-sampling the signal to original sample rate.
I choose Butterworth filters, semi-randomly, because they have flat-ish phase response in the pass-band, which I thought was a desireable property. It doesn't really matter that much, what kind of low-pass filter you use.

Also, there is one thing I forgot to mention about this entire contraption: IT ONLY WORKS IF YOUR CODE CONTAINS ONLY STAGE(0) AND STAGE(2) CODE! If you include code that relies on stage1 or 3 code (like some stock delays do) it will not produce desirable results. Unfortunately, there is really no way to fix this. Stages get executed for the entire schematic. First all stage(0) get executed in the entire schematic, then stage(1) etc. per each sample. Most code relies on them being executed once per sample. If stage(2) gets looped N times and after that stage(3) gets looped N times, it would be massive inconsistency.

I wondered if this would also work in poly-section, because if it has to be,
filter optimization must guarantee all four process channels,
ok experiment day ....

Yes, it should also work in poly section, though I haven't confirmed it yet. Poly-section sometimes clears the channels in SSE variables, when voice is inactive, but that should be an easy issue to overcome (shufps to the rescue).

It also reminds me... sometimes we do not want to truly "oversample" some inputs, but still pass them to the oversampled section (things like voiceID, pitch or indexes for waveArray). I will have to include instructions on how to pass them in w/o messing with their values.

[tulamide]

My code uses different approach. It sort of cheats - it uses "call" instruction which does ABSOLUTE jump (and also pushes current code address onto stack, to be returned to later). The first ASM module obtains the absolute memory address of its own machine code (by calling the "call of cuthulu" function which is saved in the string within the ruby component). The second ASM block then uses that value to do absolute jump to the first asm block. Normally this would be done via dedicated ASM instructions for absolute jumps (which are unavailable in FS), but it can be via "call" instruction, which essentially does the same thing.

Wow! Now I understand, and see why you were so excited about it! With this in mind, I played with the new version (which of course works without any issue) and see the potential. I also had a look at the comments in both modules and have to agree that even someone like me, without knowledge of ASM, can easily extend them with more inputs/outputs. Very, very good!

The restriction to stage(0)/stage(2) makes sense, but shouldn't be a limiting factor. For example, wouldn't you want to enhance quality by upsampling, AFTER the delay code has been executed (overlaying of signals, etc.)? In contrast to "while it is executed"?

Anyway, thank you very much for extending the capabilities of Flowstone. I can see some mind-blowing applications done by Martin already

[martinvicanek]

FlowStoner's question about oversamplintg in the poly section is interesting. That would mean oversampling the entire poly section, including oscillators, right? So we'd need only half the setup.

I am kind of stuck with the filters. The problem is that you have so many parameters to play with:
1. oversampling ratio
2. passband ripples
3. stopband rejection
4. transition band width
These will determine the filter coefficients, and then you can start designing an efficient filter configuration. At the end of the process, the result might exceed your CPU budget and you have to start all over.

In terms of flexibility, KG's choice of using Butterworth filters is not so bad after all, maybe one could get away with a lower degree.

[KG_is_back]

FlowStoner's question about oversamplintg in the poly section is interesting. That would mean oversampling the entire poly section, including oscillators, right? So we'd need only half the setup.

Kind of. The assembler blocks are arranged in a way, that they both need to be present for oversampling to work. However, the inputs and outputs and whether they should get oversampled is modular. For example in typical synth poly section: midi-to-poly module passes pitch and velocity into the OS-module. These do not need to get oversampled, so no up-sampling is necessary. the OS-module would contain [oscillator->adsr->filters] and its output would need downsampling. They would be passed into poly-to-mono module which sums the voices to mono stream.