"Four On Two" dual synth

[RJHollins]

That schematic won't open in 3.0.6

That's very weird - it was saved from 3.0.6, and I don't think it's ever been touched by a later version! I just tried opening the download from here, and it worked fine (FS 3.0.6, Win 10).

Can you try this version for me please - I've removed the knobs (which were Ruby code) to leave just primitives, and unsychronised some modules. Just a hunch, but it might point out or rule out some possible causes.

bus_merge_and_split (v2).fsm

One 'issue' I noticed ... both versions ..

Inside the Destination module, the BUS prim's OUTPUT is not assigned as a FLOAT, even though the OUT prim is a Float.

Once I reconnect onr of them ... they all connect and then work.

FS 3.07

[k brown]

I've often seen this happen when you copy and paste something - connections can go 'dead' and need to be 'reactivated'.

[k brown]

FWIW, in trying to get the CPU-load down for Four On Two (since it has four LFOs), I made a slightly leaner version of Martin's LFO. By sacrificing the SIne and making the Ramp by inverting the Saw, I was able to remove two oscillators yet it produces two waveforms not in the original, by wave-shaping the Tri. One is a shape found in Martin's audio oscillator he calls 'Parabola' (u-he calls the same shape 'Peak'), the other is like a Tri with sharp bends in it's sides, I call it 'Dip'.

The new LFOs were just added to Four On Two, so re-download it from the original link.

MV LFO_lower CPU.fsm

(25.26 KiB) Downloaded 839 times

[k brown]

TEsting this , no comment on sound and use yet but I noticed that you have lines going over the knobs for the lfo section 1-2 and 4 , not on 3 .

Didn't notice your post at first - thanks for catching that. Been fixed, re-download it.

[trogluddite]

Took another look at those busses schematics. Yes, I see the problem now. The bus extractors repair themselves when you send a trigger to the 'Channel Names' input (e.g. if selecting a new source from the drop-downs - guess I must have fiddled with these before testing the data flow, hence didn't see it - d'oh!) The 'black' connectors, I had ignored, as the bus prim's have always been a bit funny like that - especially, as k brown said, when pasting. Connecting 'After Load' and 'After Dup' primitives to the extractors' 'Channel Names' inputs seems to fix it here.

The new LFOs were just added to Four On Two, so re-download it from the original link.

Excellent. I love it when a solution to a problem leads to an unexpected bonus like that!

[Spogg]

Kevin, this is a lovely looking and sounding synth with a lot of potential. Those few presets are great!

I love the separate glide rates for mono mode. Never thought of that one! Like having 2 Minimoogs imperfectly matched for glide.

Now here are a few points I will raise, having played with it and studied it for about 2 hours (more may follow):

The mouse direction for the osc mix thumbwheel goes the opposite way to what I expected.

The mixer for filter types is great but uses a lot of CPU (more than 1 section of code is on-stream always). Fixed switching could save up to 16% of the total load (I tried it!).

Some LFO oscillators have an error in the code. The line float F1=1 is duplicated and either one of these lines can be deleted. Applies to Square and Saw LFO modules as per Martin. That can cause you a LOT of bad trouble, believe me, I've been there.

There are a total of 8 audio rate oscillators constantly on-stream. If the level from the mix knob or the output level knob is zero you can use a selector to open that stream. No clicks because the level is zero!

I see you use DSP code for adding (mixing). In fact you can just connect two or more lines together to make a junction. That could save a few cycles (unless someone knows otherwise). The same goes for multiplication; why not use a multiply prim which may be coded in C++ behind the scenes (again, maybe I’m wrong so someone could clarify if it’s any better to use DSP).

Great and good-looking work as always Kevin. Thanks for sharing.

Cheers

Spogg

[trogluddite]

I see you use DSP code for adding (mixing). In fact you can just connect two or more lines together to make a junction. That could save a few cycles (unless someone knows otherwise). The same goes for multiplication; why not use a multiply prim which may be coded in C++ behind the scenes (again, maybe I’m wrong so someone could clarify if it’s any better to use DSP).

Yes, that's essentially correct - it's what I was referring to earlier when I mentioned the DSP compiler not always optimising very well. The difference isn't very big, but it all adds up when you've a lot of them. As a rule of thumb; unless you're reducing the number of inter-component links, especially one-to-many links, it's usually not worth it for trivial maths calculations. Even then, you often need to use optimised ASM - fewer links makes it possible to keep values in CPU registers rather than using memory stores/loads, but the DSP compiler often doesn't spot these opportunities.

[k brown]

Thanks for weighing-in Spogg, I'd hoped you would.

I can't take credit for the separate Glides - that's straight from the synth's main inspiration, the Dave Smith Evolver. In fact it's something he's done on everything since returning to the hardware world.

Fixed the mouse direction on the 'thumbwheels', not because I know what I'm doing - I guessed my way there and got lucky !

If by 'fixed switching' on the filter modes, you mean simply switching between one mode and another - that defeats the whole purpose of that knob. Mixing two modes together in controllable amounts is at the core of the concept - especially when it can be modulated. I experimented with greens to switch out any filters that weren't currently 'on' at any given knob position, but it only seemed to save a couple of percent of CPU (maybe I didn't do it right - does it matter if it's the filter's input or output that's being switched?). Anyway knob-controlled greens to switch off unused filters means that now the modes can't be morphed by an LFO or other CV. I'd hate to lose that function just save some CPU. Maybe there's a way to switch them based on incoming stream values, but that's far above my 'pay grade'.

Regarding the LFOs - there was errors in Matin's code? - heavens!

I've implimented the oscillator switching - I'd actually done that before, I just forgot about it; been 'out of the saddle' for a while! Thanks for reminding.

You guys have convinced me - the simple code modules are out and prims / simple multi-links are in - stay tuned.

[trogluddite]

does it matter if it's the filter's input or output that's being switched?

Yes; disconnect outputs to remove the CPU load of stream components. With DSP/ASM you can even make stream components which don't have any inputs at all, and they'll still run if an output is connected.

Re: your filters. I agree, the CPU load is a fair price to pay for the flexibility that you want. Switching them off when not contributing would only be viable if there were no modulation, because any "playback time" switching events would cause the schematic to recompute all of its signal paths, which often leads to rather glitchy results. ASM can allow dynamic code bypassing in some situations, but it's not really viable for poly signals.

[k brown]

I got rid of all the unnecessary code modules - CPU only seemed to drop a couple of percent, but sumpn's better'd n' nuttin'.

Thanks guys for your assessments and input. The latest version is now in the Sync folder. I added an additional 'lite' version with much simpler filters, for those with CPU challenges.
https://ln.sync.com/dl/de3dc2220/5h3vz9 ... y-tcmvku4w