Page 1 of 5
tula's DSP modules
Posted: Thu Jan 11, 2018 4:01 am
by tulamide
I thought that, while exploring the DSP editor, I could just as well share the modules, I come up with. Of course, they will be very simple (yet), and of no use for anybody who can write some DSP code. But I think of those people who, like me, just can't get it and therefore need ready-made modules. Those people might find some use of my modules.
I don't expect this to become an insane number of modules, and I also don't know when I will have a new one ready. However, whenever I can provide something, I'll post it here.
If the DSP gurus find errors or inefficient code (NOT assembler, please, just a better DSP code writing), feel free to comment. I am happy to learn!
Polarity Inverter
Posted: Thu Jan 11, 2018 4:09 am
by tulamide
This first one is probably the most easiest code ever. In fact, you could do it just with stream math and it might even be the better choice. But it was my first module, so here it is.
The Polarity Inverter does exactly that. Don't confuse this with phase shift. Some audio engineers might tell you that a phase shift of 180° would be equal to polarity inversion, but that's not really true. It would only work for never changing waveforms with a defined center point, like sine, triangle or square. It won't work for complex waveforms like noise or even the sum on a master buss.
Note: It has an on/off switch, but off does actually mean bypass. The signal is still evaluated and passed through unaltered, so it still uses some CPU load.
Zero Crossing Detector
Posted: Thu Jan 11, 2018 4:16 am
by tulamide
This one is again as simple as I could keep it. The zero crossing is detected right after it happened, not when it is about to happen. This might be important for applications like Samplers.
Also, no interpolation is involved. It just looks at two adjacent samples and if either one is positive while the other is negative, a zero crossing has occured. It therefore does not detect negative to exactly zero or positive to exactly zero, since the crossing has not yet occured.
To the DSP gurus: I would love to do a streamboolean version of it, but I just don't know how they are used. If somebody could put together a quick example of how to use an incoming streamboolean in the DSP editor to alter the output based on the true or false notifications - that would be great!
Re: tula's DSP modules
Posted: Thu Jan 11, 2018 10:20 am
by Spogg
Doing this is a great idea!
I hope others chip in and we can all learn something.
In many cases there are many ways to achieve a similar result, but not all methods are as efficient as others. This is what interests me; the best way to get a desired result.
Cheers
Spogg
Re: tula's DSP modules
Posted: Thu Jan 11, 2018 10:51 am
by RJHollins
Thanks T.
Are there any DSP sites that you're researching from ?
Re: tula's DSP modules
Posted: Thu Jan 11, 2018 4:27 pm
by KG_is_back
tulamide wrote:To the DSP gurus: I would love to do a streamboolean version of it, but I just don't know how they are used. If somebody could put together a quick example of how to use an incoming streamboolean in the DSP editor to alter the output based on the true or false notifications - that would be great!
I highly discourage you from using streambooleans, especially when receiving them from user-end.
In reality streambooleans are just regular streams with different icon. You have absolutely no guarantee that what comes from the user of your module actually provides true boolean (aka all bits on for true and all bits off for false). This is especially confusing when you connect green boolean to them. For regular stream, green boolean true gets converted to float 1. You would expect stream boolean to convert incoming green values to "all-bits-off" for zero/false input and "all-bits-on" for non-zero/true input, just like the green boolean does... ooh no no no

It behaves exactly like stream - converts everything to float and passes that - if you connect green boolean to it, it will pass 1 for input true.
Only use streamboolean within inside of your modules where you have full control over what passes trough them. Never trust user or stock components/prims to provide correct streamboolean format. Another solution is to add module/code that will convert potential incoming shenanigans to correct format:
Code: Select all
streamboolin in;
streamboolout out;
out=(in!=0); //this converts 0 to FALSE (aka does nothing, because 0=FALSE) and any non-zero value to TRUE
Re: tula's DSP modules
Posted: Thu Jan 11, 2018 4:29 pm
by tulamide
Thanks a ton, KG!
That's very valuable, important information! I will follow your advice.
Re: tula's DSP modules
Posted: Thu Jan 11, 2018 8:36 pm
by BobF
Hello tulamide,
Really looking good! Wish I had the time to develope some programming skills.
Keep up the great work, BobF.....
Re: Polarity Inverter
Posted: Thu Jan 11, 2018 10:22 pm
by martinvicanek
Tula, about your inverter: nothing wrong with the code, however you could avoid the switch, which will interrupt audio and recompile te entire schematic on switching. My proposal would be this:

- inverter1.png (16.23 KiB) Viewed 25520 times
or, if you don't mind the little hack, this:

- inverter2.png (15.39 KiB) Viewed 25520 times
Re: Polarity Inverter
Posted: Fri Jan 12, 2018 5:21 am
by tulamide
martinvicanek wrote:Tula, about your inverter: nothing wrong with the code, however you could avoid the switch, which will interrupt audio and recompile te entire schematic on switching. My proposal would be this:
inverter1.png
or, if you don't mind the little hack, this:
inverter2.png
I love solution 2! It shows once again, what is doable if you have a "behind-the-scenes-view". Of course, a boolean converted to float is 0 or 1, and so it makes sense immediatly.
Is the selector always causing the stream section to recompile? It it the reason, so many people had issues with recompiling? If I remember correctly, the multiplexer does not cause a recompile?
Thank you very much, I will update the module!