DSP Robotics Support

Here's another less-than-half-a-gift.

Spogg, you've shamed me (a bit) and inspired me (a little more).

Inspired by some of your comments in the minDy thread that sometimes a limited synth can inspire, and as regards emulations especially - there's value in resisting the temptation to pile on extra features and capabilities. So I did a version of the DS-3 that has most of the limitations of the hardware (except for re-jiggering the Poly section as a third multiwave oscillator).

Krumar DS-3_os ('os' for Old School)




And, shamed me into giving it a couple more presets than the original version.

I had no intention of shaming you Kevin! That would be awful.

I do think you know that I was actually intending to encourage you!

Anyway, this last version is great and those extra presets are exactly what I was going on about. And I love their names too.

Thank you!

Cheers

Spogg

So - any idea if this can have the oscs 1 and 2 mono and osc 3 poly?

Sorry, I missed that question in your first post Kevin.

You might think you could use 2 MIDI systems, one set for mono and the other for poly and they would share the same MIDI input.

The problem you would find is that you would need 2 completely separate streams. Stream 1 would be for say the two mono OSCs 1 and 2, and stream 2 for the poly OSC 3. They can only meet and join after poly to mono conversion, where they could be mixed together.

However, I found out ages ago that you can’t have anything, not even green controls, connected to both streams. If you have a knob for say Attack it will only operate on the first stream you connect it to and the other stream won’t respond.

This surprised me but I guess this kind of topology was never considered when FS was designed.

Another approach might be to have a conventional synth for the 2 mono oscillators set to 1 voice, and a Blue stream synth for the “poly” OSC3 one, or it might be better the other way round. In this case I think Martin could help with the Blue section because he’s done something similar with his Hammond clone project (which was amazing!).

If anyone knows more about this I would love to know.

Cheers

Spogg

I can't say anything regarding poly- and monostreams, but regarding the midi flow, I immediately think of custom midi filtering. Basically having polyphonic midi incoming and filter it down for the "mono oscs". I'm unsure about the mono modes though. Should it filter so that any other incoming notes are supressed while another note is already playing, or should any new note kill the already playing one?

Thanks for weighing in tula - I seem to recall reading a description on line of just how the actual synth being emulated here (Crumar DS-2) behaved in this way; I'll have to see if I can find it again - it seemed to indicate that it was a bit unusual compared to other monosynths of it's day (late '70s).

You are right! I had a read at one of the many German retro-synth-sites (we seem to love old gear), and the Crumar DS-2 had a fixed High-Note-Priority and pitch bending (range -2 to +3 semitones) also only affected the mono section. I think I could do 2 modules, one that filters pitch bending and one that does high-note-priority.

They may even exist already in Rex' treasure chest of tools from the older synthmaker days?

That’s a great idea tulamide. I hadn’t even thought about using Ruby to arbitrate the voice assignment. Beyond me, but not you!

I think the monophonic section would need to be in blue and be controlled by your Ruby MIDI code. Then the poly section could be a regular synth system. I think you could then use common controls for blue and white streams. The Ruby code would of course need to create gate and env stage signals for the envelopes. A maximum latency due to Ruby of 10mS should be quite acceptable.

Also, we already have a MIDI mono prim, but it doesn’t create gate and env control signals and it’s only last note priority.

Or am I way off the mark with your thinking?

Cheers

Spogg

Spogg wrote:That’s a great idea tulamide. I hadn’t even thought about using Ruby to arbitrate the voice assignment. Beyond me, but not you!

I think the monophonic section would need to be in blue and be controlled by your Ruby MIDI code. Then the poly section could be a regular synth system. I think you could then use common controls for blue and white streams. The Ruby code would of course need to create gate and env stage signals for the envelopes. A maximum latency due to Ruby of 10mS should be quite acceptable.

Also, we already have a MIDI mono prim, but it doesn’t create gate and env control signals and it’s only last note priority.

Or am I way off the mark with your thinking?

Cheers

Spogg

We are not that far away, only that I don't know anything (well, not enough at least) about white and blue to really connect them to midi, but a gate wouldn't be an issue, as it is just a stream boolean going to true on midi note on and off on midi note off. Env stage would be a problem however, I can't even imagine how that should work, unless we steal from "midi to poly" the envelope bits, which are dsp code. But that would be up to you guys

Here’s what I’m thinking…

When a MIDI event arrives Ruby evaluates it:
If it’s a note ON it’s compared with the existing note playing (if any).
If the new note is higher OR there’s no other note playing, Ruby calls a method to generate the required signals.
The same is done for a note OFF MIDI message. If it’s lower than the current note playing, it’s ignored. If it equals the current note a method is called to provide the signals for ending the note.

The Ruby code would generate 2 green signals:

1) The pitch of the note to be heard: a float 0-127.

2) The env control signal: Gives a very short value of 1 to start the envelope (in white poly it’s just 1 sample), then switches to and holds at a value of 3 until the note is released, whereupon it goes to 4 and stays there. The sequence is repeated for every new note to retrigger the envelope. Since this ADSR will be running in blue there is no need to close the channel after the envelope completes. This is because there is only 1 channel and it’s always running, so no Env prim is needed.

The Ruby output will be in green but it’s easy to convert to blue in DSP for the pitch to frequency and env control.

It's probably much more involved than I said, but it's maybe a starting point to think from.

Naturally I’ll help wherever I can, but not with the Ruby side.

Cheers

Spogg