Improvements to the DSP code component?

Improvements to the DSP code component?

4 Comments

The DSP code component is great for writing fast DSP code but has always been very limited. The code is very close to the underlying SSE Assembler which forces us to use bitmasks instead of if/else statements which I really don’t mind, but what I do mind is the lack of functions. Writing functions enables code reusability , most programming languages have functions but not Flowstones DSP code! The reason is because internally Flowstone doesn’t use function calls at all (for stream data poly/mono) everything under the hood is inline assembler code, this is to avoid function call overhead for efficiency. So game over? Well yes but it doesn’t have to be this way….

Enabling us to write our own functions

If you are familiar with Flowstones DSP code you will know that we have access to what looks like functions, such as rndint() , pow() and abs() these are not real functions but more “place holders” for assembler code, the assembler code for pow() is inserted where ever we write pow() , no function is ever called.

Bearing this in mind I see no reason why we couldn’t create our own functions written in assembler, or even override the existing ‘functions’. Martinvicanek has released a great DSP math functions pack  which got me thinking about this. Wouldn’t it be great if  we could extend the DSP component with our own functions such as these? They are written in assembler and if the DSPRobotics teams gave us the ability to define functions ourselves written in assembler then the community could really get together and turn the DSP code component into something really great.

All we would need is a way to define it like so…

#define abs(float f)  { //fast ASM here….}

Then we could build up a great set of functions, even stuff like Biquad filters….. lowpassBiquad(float freq, float q) or any effect…. phaser(float stream, float feedback……).

Power to the people!

If the DSPRobotics team gave us the ability to define our own DSP functions in this way and expanded the assembler component, ie 64bit processing , more opcodes ect, then imagine the possibilities!

I think for the audio side of Flowstone to remain viable and to keep us audio geeks interested something like this is definitely needed. The DSP component always had a lot of promise and unfulfilled potential (as has the ASM component) , I am still dreaming of the day I can call an FFT function……

 

0 0 0 0 0
Exo

About the author:

I am the founder of Flowstone Guru. I have been using Flowstone since the early days when it was Synthmaker, talking 7-8 years now! I have created lots of things in Flowstone and have a wealth of experience with the software, some of my work you will find on this site in the Downloads section. I'm passionate about programming (Flowstone, Java ,C++,Ruby) there is nothing I like to do more. I just love a challenge and enjoy pushing myself and the tools I use to there limits!

4 Comments

  1. Nubeat 7  - October 3, 2014 - 11:44 am

    yes this would be a great thing to have, would also be awesome to write common if / else conditions which would make codes much more readable..

    beside that maybe a bit off topic:
    what about the implementation of a c++ code component instead of FS DSPcode and ASM components (like we have it with ruby)?
    so we also could have access to the vst sdk directly, and the possibility to include libraries and we still could use ASM

    don’t know how easy or if this would be possible

    another thing would be to open the new dll feature also for stream (poly and mono) so we also could programm streamprocessing modules in c++

    • Exo
      Exo  - October 5, 2014 - 4:44 pm

      A C++ code component would be great or probably more realistic just a C code component (no object orientation) . A dll component that works for poly would be great, I attempted to get the current dll component to work in the poly stream but failed, I had to read and write each voice to a buffer and then pass the buffer into the dll via mem to address. I did have this kind of working but only with a hard coded buffer size. Problem is in a VST although audio buffer stays the same size the buffer size that is passed to the VST can change, so I need to update the buffer size on the fly which I couldn’t seem to get working everything was out of sync. But I will come back to this at some point , so hopefully I will find a solution if not I will pester Malc about it :)

  2. kohugaly
    kohugaly  - October 3, 2014 - 3:15 pm

    those functions like abs() and pow() are in fact functions, but they are placed INLINE instead of OUTLINE and called by jumping back and fourth. The problem with if else branching and custom loops (with non-constant number of loops be it for loop or while loop) is that they are preformed by jumping in the code. But the code runs in 4channel parallel so situation may occur when one channel needs to preform the “if” part and second channel the “else” part. There are ways around that, but they are complicated even for hard-writing it in assembly, not to write a compiler for that. I may provide examples if you wish.

    • Exo
      Exo  - October 5, 2014 - 4:32 pm

      Technically yes they could be described as functions that are inlined, but once they are inlined there is no “calling” going on so not sure what you mean by jumping back and fourth. Yes I have done some proper branching in assembler in the past using jmp/jnz/jz statements and this gets messy pretty quickly for any complicated branching, ie nested if/elses.

Add Comment Register



Leave a comment

You must be logged in to post a comment.

Back to Top