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

[Spogg]

Hey many thanks for your thoughts and opinions RJ.
I guess I'm mostly thinking about poor tulamide who likes my stuff but can't really use it. Point being that there must be others who try my stuff and get dissapointed.
However, the quality and flexibility is very important to me. There are SO many free VSTs out there so I like to do kinda different stuff which generally explores a specific technique in somewhat greater depth.

I've been given some stuff which will apparently be more efficient so I will experiment with that and as long as the sound isn't compromised I'll update what is appropriate and publish the approximate cpu savings.

I've just been experimenting with mono LFOs but they just won't work properly as modulation sources and even if they did I think the overall instrument richness and quality would be reduced. The original D-50 had 3 LFOs but it had to have routing control so that adds to the burden of programming it. My version with 4 LFOs is far more accessible I believe. Of course if you have a 7 note chord held that can be an extra 28 oscillators running (4 voices x 1 LFO x 7 notes).

My background is analogue and digital electronics so I'm used to adding a filter or whatever and the only overhead is a few more mA from the PSU and maybe a slight increase in the noise level. I guess I have to be more vigilant about the cpu cost when I add something.

Cheers

Spogg

[tulamide]

Of course if you have a 7 note chord held that can be an extra 28 oscillators running (4 voices x 1 LFO x 7 notes).

That's why even a few cpu cycles can do wonders. For example, let's assume there's a synth with 4 oscillators. The synth has an option to play 16x unison. That's 64 oscillators per note. Played on a 4-note chord that's 256 oscillators. Let's also assume the signal analyser tells you that one oscillator uses 1000 cycles per sample. The sample rate is 44100 Hz. That's 44,100,000 cycles per second = 44 MHz per oscillator. Times 256 that's 11264 MHz = 11 GHz !!
Now say you optimized your oscillator to use only 300 cycles. You now get away with only 3.3 GHz, so at least some PCs will be able to play the synth with a polyphony of 4.
Another 50 cycles and you're already at 2.8 GHz, even more PCs can run the synth. Etc.

[Spogg]

Of course if you have a 7 note chord held that can be an extra 28 oscillators running (4 voices x 1 LFO x 7 notes).

That's why even a few cpu cycles can do wonders. For example, let's assume there's a synth with 4 oscillators. The synth has an option to play 16x unison. That's 64 oscillators per note. Played on a 4-note chord that's 256 oscillators. Let's also assume the signal analyser tells you that one oscillator uses 1000 cycles per sample. The sample rate is 44100 Hz. That's 44,100,000 cycles per second = 44 MHz per oscillator. Times 256 that's 11264 MHz = 11 GHz !!
Now say you optimized your oscillator to use only 300 cycles. You now get away with only 3.3 GHz, so at least some PCs will be able to play the synth with a polyphony of 4.
Another 50 cycles and you're already at 2.8 GHz, even more PCs can run the synth. Etc.

You've frightened me now tulamide
How does anything ever work with all that stuff going on? Amazing when you do the math.

But your point is well made; just a few cycles here and there make a significant difference when there's lots of the same processes happening at once. Plus graphics and maybe a DAW doing its thing too.

Cheers

Spogg

[noisenerd]

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...

Heh, this is a tougher question than it seems on the surface... ultimately, I used my personal experience to inform my answer, because my first reaction is to agree with your view. However, I remember times on my old PC when I would disable everything I could, and set everything that had the option to "low quality" or equivalent so I could do as much as I could before having to render stuff to audio.

On the other hand, like I said, I do see your point also... and I agree with what I think RJH is saying, that sometimes you just have to accept that something uses a lot of computrons to achieve its purpose. If you think it would compromise your vision, then I wouldn't do it. My comments here aside, I personally worry more about making a thing turn out how I envision it than how well-optimized it is.

[tulamide]

Really, not easy to answer that.
If you see creating an instrument as an art-form, then I tend to agree to you both. But if you want to make a synth to be used by as many people as possible, then I disagree. If I test a new synth, the first thing I do is selecting the heaviest presets of the synth I can find, then playing 4 to 8 note polyphon. If it stays under 25%, I give it a chance in my production chain.
That's for a good reason. While composing I don't want to be distracted from the creative process by needing some bounce to disk/freezing tracks and the like. I just want to play, alongside what is already recorded, for as long as needed to get a structure I am pleased with.
After that, while mixing/re-arranging and finally mastering, I am willing to outsource music from the cpu to the disk. It is just too annoying to always un-freeze/un-bounce tracks, make little changes, then freeze/bounce them again.

For such an approach I need at least 4 to 6 instruments running at the same time and therefore each of them may only demand a certain amount of my processor's capabilities.

I may also be influenced too much by Reason, because in Reason I have yet to find the upper limit of instruments. My most demanding setups there use something like 40 or so synths, and my processor isn't even sweating (cpu load is around 30%)

Back to topic: I am sure that other musicians work similar, and therefore you always have to decide, if your vision is worth not being used by many musicians, or if you implement cpu-savings wherever possible, to deliver both, your vision (for those with mega-pcs) and usability (for the hobby musician).

[Spogg]

Hi guys!

I’ve spent some time experimenting with optimisation for lower CPU usage and, thanks to all the suggestions and help I got from you lovely people, I think the new version 1.05 is much leaner whilst still retaining the original sound quality and feature set.

https://www.dropbox.com/s/kcax4242nk333 ... m.zip?dl=0
I’ll update the original post too.

For those interested here are the details of the changes and their effects:

The CPU figures are from the meter in FS on 32 bit Windows 7. I used preset 1 “Beryl” and held a 7 note chord for comparison at each stage.

Initial CPU was 14.1%
Used Martin’s 20Hz HP filter CPU 13.8%
Used Martin’s Stereo clipper CPU 13.6%
Used Martin’s SVF CPU 11.7%
Used the filters from Martin’s parametric EQ (kept the graphic control) CPU 11.1%
I decided to open the path for any levels set to zero and have LEDs to show when not zero.
Removed the animated knob for the Modwheel: this was causing the CPU to double when the wheel was operated! The wheel function is now just from the MIDI CC prim and the knob is now invisible but still in the schematic to keep the presets happy.

Current CPU is now 8.7% so I’m hoping that tulamide will now see a CPU of around 31% (instead of 50%) which of course will now vary with the preset used.

I’ve decided that (as advised) it’s better to turn off any section that’s not being used, having given much consideration to practical usage. My thinking now is that if you bypass any effect then that’s not using CPU (so why not other stuff?) and also it’s unlikely that all presets will use all elements, especially in my synths.

I’ve modified a few presets to take advantage of the “zero is off”, to set the knobs properly to zero. The zip and the FSM have these incorporated but the ones I addressed sound exactly the same as before. All the many presets you’ve been working on for me so far will sound the same

@Martin: Thank you so much for the optimised modules you uploaded. I wanted to use the reverb because it dropped the CPU from 13.8 to 12.5 but the sound was very inferior to the original. One issue was the output mixer worked differently (Mix control kept the dry present and just added the Wet) but that was an easy fix. However the wet sound had distortion on sources with a high harmonic content and actually increased the volume of sounds with a sharp attack. If this can be fixed I will incorporate it but I didn’t want to degrade the quality.

When testing this release in Reaper I noticed something odd: the 32 bit version showed 1.1% CPU with the 7 note chord test but the 64 bit reaper showed 2.5% (same hardware of course). Can it really be that the Reaper bridging is using so much CPU? If that is the case it’s a good argument for a 64 bit FS (sorry for bringing that up ).

Once again, thank you to all who have offered help and if there are any more suggestions for optimisation I will be very appreciative.

Cheers

Spogg

[tulamide]

Spogg, I love you!

The changes obviously have greater effect on slower machines. 10-finger-chromatic Fatima uses 15% cpu in Reaper! On average it uses around 5-6% in my typical production environment. Plus, it didn't crash (QX-7 unfortunately crashes here and there, but that's probably due to the CPU load being maxed out). This is very well usable!

Now please, please, please, please, please, please, please, please optimize my beloved QX-7 as well. Please. I would love you even more, with hugs and kisses and everything

[nix]

hahaha
lol

Well done, thumbs up!

[Spogg]

Spogg, I love you!

The changes obviously have greater effect on slower machines. 10-finger-chromatic Fatima uses 15% cpu in Reaper! On average it uses around 5-6% in my typical production environment. Plus, it didn't crash (QX-7 unfortunately crashes here and there, but that's probably due to the CPU load being maxed out). This is very well usable!

Now please, please, please, please, please, please, please, please optimize my beloved QX-7 as well. Please. I would love you even more, with hugs and kisses and everything

That's so good to hear tulamide. Very good!

The QX7 was next on my list and I'll probably start on it later today. Same procedure.

If Martin can fix the reverb and keep the quality that will help too. Also if he can provide a cheaper wave read module that would be SO cool.

We have a really great community here I must say so thanks again to all you fellow flowstoners!

Cheers

Spogg

[martinvicanek]

@Martin: Thank you so much for the optimised modules you uploaded. I wanted to use the reverb because it dropped the CPU from 13.8 to 12.5 but the sound was very inferior to the original. One issue was the output mixer worked differently (Mix control kept the dry present and just added the Wet) but that was an easy fix. However the wet sound had distortion on sources with a high harmonic content and actually increased the volume of sounds with a sharp attack. If this can be fixed I will incorporate it but I didn’t want to degrade the quality.
Spogg

Hmm, very strange. Yes, I modified the mixer because in my topology I have no use for "wet only". But other than that, the two reverbs are very similar. Yes, the time constants are slightly different, but to my ears the difference is negligible. I could not tell which is which in a blind test, Anyway, let me see if I can make my reverb sound exactly like yours.

Glad you could use the other stuff though.

Edit: Done, updated attachment in my original post.