Quilcom Q-50: Inspired by the Roland D-50 synth

[Spogg]

Thanks you guys for the ongoing comments and suggestions:

I hope you don't misunderstand me. The motivation for my moaning is that I really like the sound output of your synths, esp. the QX7, and it frustrates me that I can't use them in production.
I'm not in the least bit cross about this; I'm happy that you've given me this feedback and encouragement to do better...

You might compare the CPU usage of the wave oscs with the MV ones... I know Martin's oscs are more efficient than the stock ones, but often a sampled osc is cheaper than a real-time-calculated one (not sure if that's necessarily the case here). If the samples are cheaper, you might replace the synth oscs with sampled waveforms.
Can anyone else comment on this please? Essentially I'm a designer not a code optimiser and I don't know if sample-based oscillators are lower cpu than calculated ones. I do know the stock prim oscillators use wavetables and they use far more cpu than Martin's. Then there's the issue of aliasing...

This next one comes down to how "smart" the selector is, but you might try changing your filter setup so that any filters that aren't being used are switched out of the signal path entirely. It's possible that your switching setup for the SVF/Ladder filters is sending audio through both filters when it doesn't have to. I could be wrong, someone please correct me if so.
My understanding and experience suggests that selectors will cut off cpu usage from anything not selected, in a poly stream, so I'm not convinced this is an issue if a module has an input but no output path.

Why girls names for all the presets?
When you name a preset you pre-condition a judgement from the listener. "Brass 1" might lead the player to think "well it's ok but not very accurate". I just thought that using girls' names was a bit different and just as good as abstract descriptors. Also the user can rename and save according to their own needs and interpretations. And Bob, thanks for your nice comments

Spogg, a few alternative modules that you might want to consider.
Martin, this was exactly what I needed and hoped for! Thank you so much for this and I will experiment. If you or anyone else is able to offer better alternatives to the stuff I use in any project I will be forever grateful, as I am to Martin always.

I'm going to look at my use of LFOs in the Q-50. It might be better to have mono LFOs supplying a modulation bus to the synths. However, I don't want to forsake the quality of sound I can get at the moment. The current Q-50 also has polyphonic pitch envelopes and that needs thinking about but, again, I don't want to reduce its musical capability. We shall see...

Cheers

Spogg

[stw]

Some ideas for optimization...
One general ruel is to take everything out of the stream what's not needed.
E.g. all LFO's are running though not all are used (level = 0). You could e.g. add the option "Off" in the wave menu to switch them off.
One other thing i noticed is your DC filter. A SVF for that is very expensive. There're cheaper solutions.
Some simple 1pole filter like this should do the job:

Code: Select all

streamin in;
streamout out;
float buf;

out = 0.9999 * out + in - buf;
buf = in;

[tulamide]

You might compare the CPU usage of the wave oscs with the MV ones... I know Martin's oscs are more efficient than the stock ones, but often a sampled osc is cheaper than a real-time-calculated one (not sure if that's necessarily the case here). If the samples are cheaper, you might replace the synth oscs with sampled waveforms.
Can anyone else comment on this please? Essentially I'm a designer not a code optimiser and I don't know if sample-based oscillators are lower cpu than calculated ones. I do know the stock prim oscillators use wavetables and they use far more cpu than Martin's. Then there's the issue of aliasing...

Let me introduce you to how a processor works (not in detail, I'm just giving you a simplified image). A processor has a certain speed, expressed in mulitudes of Hertz. That means a clock will pulse that many times per second. For example, a 3 GHz processor's clock will pulse 3 billion times per second. The tiny pieces are called clock cycles (aka cpu cycles). At anyone of these 3 billion cycles, the processor can execute a certain amount of tasks. Here Assembler can help understanding the tasks. CPUs work with a so called instruction set (risc and cisc, for reduced, resp. complex, instruction set computer). Those instructions can be identified pretty easy in Assembler. For example "MOV" copies a byte from source to destination. A Skylake cpu can execute 4 MOV instructions per cycle. A "DIV" instruction on a 64bit register already takes up to 83 cycles.

Btw., I think here's where Martin makes so awesome optimizations: By eliminating instructions that use too many cycles, and replacing them by more lightweight instructions. If there is a way to get the same result than from a DIV with other instructions, it doesn't even matter much if you replace one instruction by a bunch of others, because they might even combined still use less cycles. (Martin, correct me if I'm wrong!)

Now that you know of cycles and what they mean for computing, you should look into your toolbox to find a prim called "Signal Analyser". You input a stream and a number of samples, and the prim tells you, how many cycles were used per sample processing. You can use this to compare different approaches (for example the stock oscillators against Martin's oscillators) and find the least demanding solution.

Wavetables were introduced back in the days, because they are pre-computed and therefore less demanding than realtime-computed waveforms. You can use wavetables, the prim takes care of anti-aliasing. However, Martin's realtime-computed ("procederal generated" might be the right term) oscs are so optimized that they even outrun wavetables. That's true as long as you stick to the waveforms provided by Martin.

That's all I can say to this topic, but I hope it helped you.

[Spogg]

Thanks to tulamide and stw.
Food for thought!

I really do appreciate all this help and advice and I bet the silent many will also benefit.

I want my plugins to sound nice AND be usable!

Cheers

Spogg

[martinvicanek]

One other thing i noticed is your DC filter. A SVF for that is very expensive. There're cheaper solutions.
Some simple 1pole filter like this should do the job:

Code: Select all

streamin in;
streamout out;
float buf;

out = 0.9999 * out + in - buf;
buf = in;

+1
(and remember to kill denormals...)

[adamszabo]

Everyone is correct about the optimization, I would just like to add that to really optimize a synth, its important to write most of the things directly in assembly. Thats why its worthwhile to learn assembly to do even more tricks. For example instead of multiplying a value by 2 one can add the same number together like so: addps xmm0,xmm0; its the same as multiply by two but uses an addition instead of multiplication. The same thing can be done for example x^2 instead of using a very cpu intensive power math method just use a single multiplication to multiply x by itself like so: mulps xmm0,xmm0; And the list goes on, and once you write everything like this, shut off everything thats not needed, one can do wonders and a really cpu intensive synth will use way less.

[Spogg]

Everyone is correct about the optimization, I would just like to add that to really optimize a synth, its important to write most of the things directly in assembly. Thats why its worthwhile to learn assembly to do even more tricks. For example instead of multiplying a value by 2 one can add the same number together like so: addps xmm0,xmm0; its the same as multiply by two but uses an addition instead of multiplication. The same thing can be done for example x^2 instead of using a very cpu intensive power math method just use a single multiplication to multiply x by itself like so: mulps xmm0,xmm0; And the list goes on, and once you write everything like this, shut off everything thats not needed, one can do wonders and a really cpu intensive synth will use way less.

I do realise you are completely right Adam.
However, the BIG attraction of Flowstone for me is the graphical design environment. I can realise ideas mostly with ease and fairly quickly. The trade-off is obviously cpu efficiency. The logical extension of using lots of assembler is programming the whole synth in say C++ which is far beyond me. For this reason I have to rely on others to help with any optimised modules they may be able to offer, for which I'm always very grateful.

One reason I have moved away from turning stuff off which isn't used is that I wanted to avoid the situation of some presets being heavier on cpu than others. I think that if a synth will actually work on a PC then all the presets should work. Of course the number of voices sounding will directly affect the processor load but that could be limited on the MIDI side or by the player. Any views on this point?

Cheers

Spogg

[noisenerd]

Thanks for clearing up my confusion.

One reason I have moved away from turning stuff off which isn't used is that I wanted to avoid the situation of some presets being heavier on cpu than others... Any views on this point?

I can definitely see your side, but having only recently gotten a computer that can actually handle what I throw at it, I'm all for having options to cut down on CPU usage.

[Spogg]

Thanks for clearing up my confusion.

One reason I have moved away from turning stuff off which isn't used is that I wanted to avoid the situation of some presets being heavier on cpu than others... Any views on this point?

I can definitely see your side, but having only recently gotten a computer that can actually handle what I throw at it, I'm all for having options to cut down on CPU usage.

OK here's the scenario I wanted to avoid: You download a synth and the first few presets run fine and sound good. Then preset number 6 overloads your system and ASIO4ALL drops out. Is this better than downloading a synth and finding it just doesn't work on your system? I never have this issue myself because I have an i7 PC so I need to know which is preferable, generally speaking...

Cheers

Spogg

[RJHollins]

Hi Spogg,

I'm following your thread, not that I can offer a solution, but I can relate to similar issues.

Just a thought. Might it be possible to have a 'lite' version of a Preset ? One that holds the essence of the full-blown preset, but is not as 'hi-rez'.

Something like 'lite' oscillators, or some other cost-cutting ?

As to the issue ... What can you really do? Lower the overall performance/qualities for some 'accepted-base' CPU configuration, or push for best qualities ?

Either way, something is lost.

If you have optimized this to the hilt, then the decision comes down to your intended market/user.

I've recently upgraded from an 8 yr old computer to a new i7-5820K [64-bit, 16GIG RAM]. I use very CPU/RAM intensive processing for my Mastering work. Before, I had to Pre-Render and temp render in stages to work a project. Today, I don't really think about it as everything is now real-time. Thank-Goodness ! as the core software my work is based on is specifically optimized for the latest generation instruction sets.

My opinion. Quality is everything. Workflow is a component of that. It can be a trade-off, but if the computer is the weak link, then it really comes down to the user.

As the 'programmer' ... a real-world perspective should be mindful. We all can't work at 192kHz sampling rate, or whatever the upper bounds are. But if we NEED to ... got to have a computer that can match.

Just my opinion