DSP Robotics Support

Hi all

Here is my latest effort!

https://www.dropbox.com/s/ipt0zvpygd86r ... s.zip?dl=0

This synth was built to explore wave morphing, i.e. dynamically mixing between two sound sources (it's not spectral morphing). I thought this might be rather limited but I was pleasantly surprised at the amount of possibilities; try the presets I made to get started.

There are 2 identical Generators which can be muted and panned left/right. Most presets just use 1 generator since it seems to be a poweful technique and using just 1 keeps the CPU useage down. The sound can easily be enriched by the effects strip at the bottom.

The scheme is pretty simple. There are 2 wave sources, typically the 2 wave-draw oscillators. There are 2 standard Synth strips, each can be blended into either wave channel. The 'morphing' or blending is controlled by a graphic envelope generator so that high = Wave 1 and low = wave 2. The blend feeds into an envelope-controlled multi-mode filter and finally into the output volume envelope. In addition there is an FM system with its own graphic oscllilator and envelope generator controlloing the amount of FM. The FM system only feeds the Wave osclillators and not the synth strips. This actually increases the range of possibilities.

I've packaged this with my latest Quilcom Wavemaker 2 so you can make your own harmonic series waves to load into the Blender. Also I've provided a stock of basic waveforms and waveform mixes to get going.

I hope you enjoy playing around with this and if you do make any presets (for any Quilcoms) it would be nice to try them out.

Have fun

Spogg

Wow, a real monster! The presets are well chosen to demonstrate the wide range of sounds possible. Good job! My favorite is Celia.

From time to time I am able to test other people's synths. Not as often as I liked to, though. However, this time I got around Blender. In germany a "Blender" is someone who talks much and does nothing. Someone who promises way more than he delivers.

Luckily Blender is not that type of "Blender". You get what it promises. At first I feared that you give way too much to the people. Some will change the gui and then sell it. But, then I looked into the generator modules. What a mess!

Certainly you can't steal what you don't understand, and people with less knowledge won't understand that connection overkill. Don't get me wrong: I think this is a good thing

But there's one more specific question: In the digital domain, clipping occurs over 1.0 (aka over 0 dBFS), but you indicate clipping from 0.93 (aka -0.63 dBFS) on. Any reason for this?

Herr Tulamide, you are SO eagle-eyed

Here's why I set the peak indicator threshold to 0.93:

The Mono to Float module uses a Tick of 25. It could be set to 100 but that's a lot of Ticks, especially when there's so much going on with the CPU elsewhere. Unfortunately I found, by experiment, that this temporal resolution was inadequate to capture ALL short peaks and transients; it was possible to hear clipping that the peak indicator sometimes missed. So my solution was a simple and pragmatic one that seems to work mostly: to slightly lower the threshold to 0.93. Again experimentally, this seems like the sweet spot for accuracy of the display.
I bet there's a much better way to do it, in which case I'd love to see it and I'd use it the future.

Many thanks for your other comments!

Off Topic: I'm making good progress on a DX7 proof of concept which you'll be able to look at soon. I'll put it the DX7 Harmonica Topic soon...

Cheers

Spogg

EDIT: If anyone thinks they can make some money out of anything I upload that's fine and dandy by me! This is a hobby and I do it purely for the fun and the challenge. So go ahead and make your millions

Spogg wrote:The Mono to Float module uses a Tick of 25. It could be set to 100 but that's a lot of Ticks, especially when there's so much going on with the CPU elsewhere. Unfortunately I found, by experiment, that this temporal resolution was inadequate to capture ALL short peaks and transients; it was possible to hear clipping that the peak indicator sometimes missed. So my solution was a simple and pragmatic one that seems to work mostly: to slightly lower the threshold to 0.93. Again experimentally, this seems like the sweet spot for accuracy of the display.
I bet there's a much better way to do it, in which case I'd love to see it and I'd use it the future.

I really asked to understand the thoughts behind. And I think that's pretty good. It's a compromise between cpu-demanding accuracy and light-weight-guessing.
With dsp code you could probably catch every non-intersample peak, but as said would be very demanding in relation to the task. With Ruby you could very quickly search the array for peaks (or even realize rms-peaks), because you can send data to an output without triggering it. But to not miss a peak, you'd need to buffer the peak results. Also, Ruby in stream sync introduces a 1 frame delay, which might not be desired. And for both it's true, that you still would miss intersample peaks.
No, I think your pragmatic solution is probably the best compromise.

tulamide wrote:With dsp code you could probably catch every non-intersample peak, but as said would be very demanding in relation to the task. With Ruby you could very quickly search the array for peaks (or even realize rms-peaks), because you can send data to an output without triggering it. But to not miss a peak, you'd need to buffer the peak results.

Yeah, I would rather use a dsp/asm approach for that, because it just is very reliable. CPU wise, I don't think that you would need that much for that. You could just use a very simple envelope follower with fast attack and slow decay. That way you could read out the value and display it in a meter without having to smooth it out in the UI using green or Ruby.

That's basically what the meters in the toolbox do, when you use their stream inputs.