Custom DSP Code 2 (comunity project)

[Exo]

Hey KG, thanks again for this great project.

I am planning a couple of function packs when time permits. I currently have a big project under way as well as a few smaller ones. Once the smaller ones are out of the way I will come back to this, I intend to use this DSP code in my future projects.

My ideas for function packs are..

1. Filter pack, this could contain all the well know filters posted over the ages.
2. External Mem pack, Read, Write, Copy, Section ect...
3. Oscillator pack, would include pure coded ones and support for wavetable oscillators.

So if anyone has made a start on anything like this let me know and I will help out rather than reinvent the wheel.

[KG_is_back]

Hi Exo!

Today I've finished oversampling pack. It works good and I even managed to optimize some code in the original oversampling toolkit. Basically has two functions. "upsample" takes the value form a variable, upsamples it by given factor and fills an array with the values (also has quality parameter, to choose from 3 types of upsampling). You than use loop to iterate over the array and then use "downsample" function to downsample the array, returning the downsampled value.

Also I've started working on a filter pack. Already made State variable filter based on ZDF filter. I will make also HPF,LPF,BPF, shelving notch etc. later this week. Also I'm adding option to use hop and/or smart bypass on coefficient calculation. Also when frequency/Q/gain are constants, some stuff gets pre-calculated during compilation and passed as a constant (very convenient setAdvancedCodeGen method can do such things). It should squeeze maximum performance in all situations.
Long story short - leave it up to me!

I'd be very glad if someone could make the oscillator pack. I've already had a look at MartinVicanek's oscillators, and they should be fairly easy to port to DSPcode2.

Only problem I've run into is, that in stage0 code you can't use the input arguments of a function. Well, technically you can, but you have no insurance that they were evaluated.
If stage0 uses some of the function arguments, you'll have to squeeze it into stage2; code somehow. Either make it run only once and then bypassed using conditional jumps, or use bitwise operators and make it run always.

As for the external Mem pack, you're reading my mind. The "read from pointer" operator is already supported by DSPcode2 (I haven't added the codegens yet, so it's recognized by the lexer and parser, but not by the back end). "variable[index]" will use the value of the variable as address and reads from it. As expected it may cause crashes, since it's hard to predict if variable contains valid address. Having a pack of functions specifically designed to manipulate external mems and arrays is super-convenient though. Especially the stuff that needs loops, like "CopySection" or "fill".

[Exo]

Thanks KG,

Good to know about the stage0 issue. Glad to here you are doing a filter pack, I had a feeling you or someone would be.

A Mem pack was one of the first things I thought about because reading from mem is only possible in ASM.
Having a built in way to read directly from the mem as an array is a very good idea. But yes a pack is still definitely needed for copySection ect . Also I want to do an oscillator that takes a mem for the wavetable.

[KG_is_back]

Good to know about the stage0 issue.

here's an example of such behaviour:

Code: Select all


float a;
float b;

stage(2){
a=1;
b=3;
myFunction(a*b);
}


At stage0; the expression "a*b" can't be correctly interpreted, because "a" and "b" are given values at stage(2) (which means at stage0 they are both zero in this example). There is no way to remove this complication.

Having a built in way to read directly from the mem as an array is a very good idea.

actually this reminded me one "hack" I've found some time ago. Using Analyser prim it is possible to extract the address of mem-array (addresses of two arrays - one contains addresses of mems and the other contains their sizes as floats) and then read/write to/from mem-array. It was however super-unstable.

Perhaps Malc could add Mem to address prim and Mem-array to address prim that have stream outputs. That way, when address changes it is instantaneously passed to streams which makes reading/writing mems in ASM much more stable. At the moment We have to route the address trough green or ruby, which (I suspect) causes occasional crashes because they run on different threads and may be out-of-sync with streams.

[Exo]

Perhaps Malc could add Mem to address prim and Mem-array to address prim that have stream outputs. That way, when address changes it is instantaneously passed to streams which makes reading/writing mems in ASM much more stable. At the moment We have to route the address trough green or ruby, which (I suspect) causes occasional crashes because they run on different threads and may be out-of-sync with streams.

Yes that could be a solution. You are right I think the address is obviously not passed to the stream in time. This is definitely a problem that needs solving I have also had crashes.

[KG_is_back]

Alternative solution might be to re-create mem-array prim and mem-using prims using DLL. The DLL would have a frame output, that would be filled with current address. Any time the "alternative mem" inside DLL changes, the address is instantaneously made available in the next ASM buffer. Trog has made similar approach using Ruby frames. Perhaps we could revive the project.
Yet it would be more suitable if this feature was supported by FS prims and FS native mems, because DLLs or Ruby would basically replace that feature.

[martinvicanek]

I want to do an oscillator that takes a mem for the wavetable.

[...] the address is instantaneously made available in the next ASM buffer. Trog has made similar approach using Ruby frames. Perhaps we could revive the project.

I have started a separate thread on this, please have a look.

[Exo]

The mem address crashing discussion has been split into it's own topic HERE.

[KG_is_back]

OK guys, initial version is at FS guru here.

Some features are not added yet (namely the reading/writing via pointer and some function packs are not there/not fully finished). Hopefully you can give me some feedback, because there are hundreds of lines of code = possibly a bug here and there...

[KG_is_back]

Hello guys... working on version 3. Hopefully this one will not be full of bugs...
It seems I have the lexer and parser part figured out and even colorCoding works (it's only a display though - you can't edit the code directly from front panel). It should accept almost any C code.

I'm struggling heavily with the ASM code generator though. I've figured I can implement "if" and "while" statements in poly-compatible way, by putting ternary operator at each assignment. Still the register and temporary variable managing is hell...