DSP Robotics Support

Hi all -

I finally upgraded from SM to FS! This is the first project completed, though it was quite a fight to keep my ancient laptop alive during the process; kept freezing and crashing. It's a Lenovo R61e with Celeron 540 @ 1.86 GHz and 504 MB RAM, running Win XP 2002 SP3 (I can hear you all laughing). Do you think I'd be better off with an earlier version than 3.0.6 ? I use my PC lap only for synth work and that just doesn't warrant purchase of a new one only for that purpose - all my other computer work is done on a Mac.

I'd be massively grateful if anyone was kind (and brave) enough to root around in my messy schematic to see what more could be done to get the CPU load down - I've used Martin's oscillators, optimized SVF filters and his ASM stereo clip, and a single ramp prim with code waveshapers in the four LFOs, but the CPU is about three times Spogg's Quilcom A.S.S. I know nothing about ASM, etc., and don't do coding, so is this about as low as it can be without custom-coding things? I suspect that the mod bus setup could be done more efficiently.

About the synth itself - it's basic structure/signal flow was in part inspired by the Dave Smith Evolver, that had two pairs of oscillators (through their own amps) to a stereo filter and amp. Putting each osc through it's own modulate-able amp before the filter enables 'dynamic wave-mixing' similar to the Ensoniq ESQ-1. I didn't attempt emulation of Evolver's various 'harshify-ing' sections (distortion, hack and tuned feedback), but did expand the structure to something more like the Yamaha CS-series synths that had two complete 'synthlines' (and in one case, stereo output); so here each pair of oscillators feeds it's own stereo filter and output amp, with stereo spread control. Included is the option of switching to the more Evolver-like structure of all four oscs going to one stereo filter/amp. As with Evolver, there are four modulation slots (to which I've added Moog Voyager-like Shapers between the mod sources and the destinations). Evolver had dedicated envelopes for the filter and output amp, plus a third modulation EG, here there are two mod EGs. Each oscillator can cross-fade between two selected waveforms and the cross-fade can be modulated. Oscs 3 and 4 each have one wave selector that can switch to a selection of a dozen or so wavetables. The filter has a rather unique control that cross fades between modes: LP > BP > HP > BR , and back to LP. This was a design used in the rare vintage synth the ElectroComp EML 100. Their Model 101 was much more common, but had a much simplified filter Mode control. I added the ability to modulate this mode control - quite a unique sound.



https://ln.sync.com/dl/de3dc2220/5h3vz9 ... y-tcmvku4w

Hi, there - that was fun to play around with - I like the multiplexers for complex modulations in particular.

I've had a very quick rummage in the schematic, and I think you shouldn't be too hard on yourself. The comparison with Spogg's ASS (I enjoyed playing with that, too!) is a little unfair, as their architectures are so different. The USP of ASS is switchable digital/analogue modes for the components; very nice, but with the emphasis on "switchable" (thus saving the CPU load of the unselected options.) OTOH, a lot of Four-on-Two's flexibility comes from being able to mix so many sources together in so many ways (so each voice's sources must be always be running.) I didn't do any benchmarking, but your 3-times figure seems reasonable given the differences.

The components from Martin, MyCo, et al. I'm sure we can trust are as close to optimal as anyone here can code. Unfortunately, I think you're probably right that only major DSP/ASM tinkering would save much in the way of CPU cycles - mostly by gathering multiple modules into single, large DSP/ASM blocks so that they share inputs/outputs/constant-values/hopping-routines etc. - but that would be major surgery indeed!

There are a few minor ASM tweaks possible here and there in the existing DSP code - but not enough that I'd lose an awful lot of sleep over it (mostly the DSP compiler not optimising maths expressions with multiple operators very well.)

Re: the modulation matrix. The busses way of doing it isn't in itself that costly AFAIK. Hopping all modulation paths all the way from source to destination, and then only interpolating them after summing at the destinations, is the only tactic I can think of (if you can live without full audio-rate modulation, of course!). But again, for very small code blocks, it can be counter-productive, as the cost of the hopping routines can easily outweigh that of the few instructions being hopped over.

BTW: I noticed the comment about the "odd" code in the filters. The additional 2 * PI is because the original spec is written with the sin1(x) function (0..1 = full circle), whereas the Taylor series approximates sin(x), which requires radians (0..2PI = full circle.) The following code using x2, x3, x5, etc. is the Taylor series itself - a neat way to approximate a great many otherwise costly maths functions.

Thanks Trog. Any bad after effects from rooting around in that mess? For some reason I just never got around to being tidy with sub modules and such; Spogg's schematics are so impressive in that regard.

Any thoughts about such an old machine being happier with an earlier version of FS? It's just crash city with 3.0.6.

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 .

k brown wrote:Any bad after effects from rooting around in that mess?

Not at all - believe me, I have seen plenty worse. Anyhow, I think you've probably saved me from the perennial problem I have with procrastinating about what I should have for my dinner. Bolognese today, I think!

One thing that might clean it up a lot would be to use the mod-matrix busses differently, as that seems to be the main source of the spaghetti. A bus doesn't have to have all of its 'channels' created or extracted in bulk, you can merge and split off sub-sets of the channels at almost any point in the linking. So you could have bus creators and extractors inside your source/destination modules, and only have to pass a couple of busses around - which could even be done wirelessly. Here's an old example that shows the rudiments of it...

k brown wrote:Any thoughts about such an old machine being happier with an earlier version of FS?

Not really, I'm afraid; though I will say that versions up to 3.0.8 weren't any less stable on my old (but much more powerful) Windows XP machine, so I don't think your OS is a fundamental problem.

Terrif' - thanks so much.

Update coming on 'Four On Two' - a few refinements; mostly added the ability for the two filters to be in series or parallel when oscs 3 and 4 are re-routed to filter A, rather than filt and amp B being 'wasted'.

That schematic won't open in 3.0.6 - maybe I'll try going up to 3.0.8. I was going by some forum posts that described 3.0.6 as the most recent stable version.

I replaced the link in the first post with the re-do. I'm not calling it v1.01 because I haven't 'officially' released it yet, haven't put it on my website.

Thanks again

k brown wrote: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.

Actually it was my fault - my usual PC lap was tied up, so I tried to open it with an even older one; both opened fine with the 'newer' machine. Thanks again for those - makes perfect sense. What are the knobs doing in the first version?
Selecting sources?

trogluddite wrote:One thing that might clean it up a lot would be to use the mod-matrix busses differently,

bus_merge_and_split.fsm

[/quote]
That is very cool !!!

Thanks TROG !