DSP Robotics Support

I guess MIDI is just too math-like, which I've always been incapable of - I read about MIDI Channels and such and I pretty much understand the concepts but when it comes to the mental leap to how it's actually applied, my brain collapses. Perhaps because I've no experience with DAWs, sequencers and such; I just fire up a synth and play it with a keyboard (often just the PC keyboard ), or my silly little Casio Horn.

Point being - I'm just finishing up project based on the Vemona PERfourMER II hardware synth, which is, at it's core, four complete single-osc synths (that Vermona calls 'channels') in one box. It has a couple of ways of responding to MIDI Channels that I get how they work, but no real clue how to implement them with FS. It has six so-called PlayModes -

Mono 1 - All channels heard together on each keypress. Nothing unusual here, with FS, can be mono or polyphonic.

Mono 2 - (This I've no idea how to do) Each keypress sounds each synth channel in turn.


I've read the various MIDI prim hover-over texts and - umm, I dunno

Duo 1 - Like Mono 2, but two channels heard with every other keypress.


Duo 2 is typical duophony, like the ARP Odyssey.

This project's pretty much finished, but I'd really like to get at least the Mono 2 thing going, would be very interesting, especially when driven by a sequencer.

Here's what it's looking like -



Sounding pretty great, too - still working on presets. It even does up to four-op FM with each operator having multiple waveforms, a dedicated LFO and Multimode filter.

Here's the PERfourMER's manual.

I think this is a case of not seeing the forest for the trees. As all of it is switched and controlled by the instrument, you don't need to consider MIDI at all. Just create the four synths, and when it comes to mixing in blue create hard-wired cross-fades, based on the "mode" the instrument is currently in.

Unless I've missed something in the explanation that is

EDIT: AAAANNNNDDD of course I did
Carry the midi channel information until it comes to mixing in blue and extend the cross fade options to consider the midi channel

But creating the per-synth MIDI channel information is the part I don't get - hence MIDI dunce.
And I don't see where cross-fading comes into play.

Is there an advantage to mixing in blue rather than poly?

tulamide wrote:EDIT: AAAANNNNDDD of course I did
Carry the midi channel information until it comes to mixing in blue and extend the cross fade options to consider the midi channel

k brown wrote:But creating the per-synth MIDI channel information is the part I don't get

I think that these may be way off, too; in fact, I don't think the MIDI channel has anything to do with it at all. To be fair, though, whoever wrote that synth's user guide is using "channels" to describe something more like what we'd normally call "voices"; which seems like a dumb thing to do on a synth which also has MIDI!

If I read it right, on the original synth, "Mode1" is what we'd normally call "mono unison" - all four voices/"channels" play the same single note. "Mode 2" is what we'd normally call "4-voice polyphonic" - but with the unusual quality that each voice gets to have its own settings. Each time you play a new note, it is assigned to a voice/"channel" with different settings than the other three, so each new note has its own "patch" selected from the four.

The very earliest poly-synths, the Oberheim 4-voice and 8-voice, worked in exactly this way - each voice was a separate "SEM" mono-synth, so if you wanted every note to sound the same, you had to tweak 4 or 8 little front panels to all have the same patch settings - or have each new note use a different "patch" to the previous one.

k brown wrote:Is there an advantage to mixing in blue rather than poly?

Assuming the above is correct, and the bulk of the synth is poly, then selecting the voice/"channel" would also have to be in poly, otherwise it wouldn't take place "per note". I can see two ways it might be done...

1) Have a counter which is incremented (mod 4) per note-on, then "lock" this into place using the "trigger" pulse at the start of a new note, and use it to select which path is enabled. This might sound slightly different to the original, as it would be strictly "round-robin", regardless of what note-stealing might happen when you run out of polyphony (probably not that noticeable, though). It could waste quite a lot of CPU, though, calculating the three "synth" paths that you're not actually hearing.

2) Use a custom note allocator and four fixed voices made in "blue" mono4. I have done this before to emulate something like the Oberheim SEM architecture, albeit without separate controls per voice (just a bit of randomness to emulate the inaccuracy of voice matching). This would be a very exact emulation, but you wouldn't be able to extend the polyphony, and "mode 1" would be strictly mono unison.

Thanks for your brainstorming guys - sounds like the Mono 2 mode could only be done all in blue and therefore limited to mono or four note 'polyphony'; not worth it as far as I'm concerned.

Here's a quick proof of concept cobbled together from my "SEM-like" schematic. The envelope is shared (and is also custom, due to not using poly), but each of four voices has its own waveform selector and pitch offset. The way that each note is different is what I'm pretty sure the user-guide was trying to describe:

k brown wrote:...limited to mono or four note 'polyphony'; not worth it as far as I'm concerned.

Nah! Polyphony is what killed creative synth playing and programming; as soon as they became polyphonic, the rot set in with people expecting them to sound like organs and pianos!

I have long had a separate folder in my plugins directory for dedicated mono-synths - you can't beat them for basses and leads, IMHO, and they also allow a few FS tricks that aren't easy to do using poly streams.

Like this very 'round robin' thing, for instance!

Man, that's way more complex than I would have thought it would take to do the Mono 2 mode! And I understand about 2% of it.

Coltrane would have really been a success if he just could have played chords on that damned horn!

Well I wouldn't worry too much about the voice allocator thing - there's loads in there that doesn't need to be, from a bigger "Ruby MIDI Tools" collection, and it can be treated as a "black box", just like the regular MIDI-to-poly.

Once there's a bunch of easily patchable modules, it's not that much harder than poly to put a synth together...
Unless you want more than four-voices, that is! The code will handle it, but you have to copy every single component for each additional four voices - and that gets old and tiresome (and CPU hungry) rather quickly!!

I do think it adds a nice analogue flavour, so long as polyphony isn't an issue. The oscillators are truly free-running for nice detuned sounds that don't "reset" phase at note-ons, and the envelope works like analogue too, without that annoying "sucking out" of the sound when a voice gets stolen and the attack restarts from zero (I much prefer that for mono-synths in particular).

trogluddite wrote:Here's a quick proof of concept cobbled together from my "SEM-like" schematic. The envelope is shared (and is also custom, due to not using poly), but each of four voices has its own waveform selector and pitch offset. The way that each note is different is what I'm pretty sure the user-guide was trying to describe:

Four Voice.fsm

The Roland Jupiter4 (which I long ago owned in hardware) had some similar odd key assignment modes. This should come in handy if I ever get off my butt and try to build an emulation of it.

Kind of a transitional beast: microprocessor-controlled (a half-dozen or so 8048s), full analog audio stream, no MIDI. I just saw a used one online for exactly double what I paid for mine in 1980.