Split Kbd for 2 parts synth

[talnadav]

Hey there, kind of new in the forum busines - but I kow some of the SM:
I want to make a simple synth but with the option of splitting it to 2 voices/sections.
for example C3 and down will be a Bass synth and C#3 and up would be... LEAD.

tryed to use several midi modules, midi-splitter, note event, even tried to use a combination of pitch split in the midi2poly module.
any clues??? guidelines? something to start with?
tried with the "code" but i'm not familiar with coding and stuff - only the basics of the basic lines...
my aim was to code something that from a point and down (of the KBD) the frq will be sent to Synth A Section, and from the kbd point and up - to Synth B section.

[oddson]

You can split the MIDI data:

splitMIDI.png (56.63 KiB) Viewed 280 times

Or you can split the poly stream:

Code: Select all

streamin p; // MIDI pitch
streamin s; // split point
streamout p1;
streamout p2;

p1 = p>s & p;
p2 = p<=s & p;

[MichaelBenjamin]

for some reason i cant see the picture displayed.
is the green splitting really 100% reliable or does it choke and mess up on heavy data streams and otherwise higher cpu load? if its reliable you could split in green and then basically build 2 synths with their own white section. if you split in code with white the whole synth will be in processing including the parts that give no sound.

[oddson]

Not sure why you can't see the picture... you can likely guess what it contains; MIDI splitter, two MIDI event primitives and some green-boolean logic stuff to filter out note events above and below a split point.

AFAIK green processing of MIDI events is rock solid in SynthMaker (although, admittedly, I did not test this particularly scheme). The programs usual timing issues don't seem to show up and I think that's related to a different event process for MIDI initiated events (which is why the Timer primitive doesn't work with MIDI initiated events).

I did consider the problem of processing poly streams with zero frequency (which is what will happen from the coded version). I don't know that there is any workaround as the channel will stay active as long as the envelope on the other side of the synth is still processing (at least I think that's what will happen).

If the intent is to play different samples but otherwise do similar processing it's likely better not to split them off right from the outset but to work with the data along the way... but if you want completely different processing I think the green solution is better.

BTW- with the green one you still have to worry about non-note MIDI and where it's going. The screen shot assumes it's handled elsewhere as these will not pass any other MIDI data to the right-hand-side. A more complex version could allow passing all non-note to both sides.

[talnadav]

(sorry for the late responde - technical issues...)

THANKS!!! A lot.
I tried this way but i had some mistakes in the connections, thats why it didnt work out.
when i'll finish ste this up with some "fine-tuning" i'll post it.
thank you all.

[mwvdlee]

is the green splitting really 100% reliable or does it choke and mess up on heavy data streams and otherwise higher cpu load?

I've done some things with green MIDI as well and found that you can very quickly get it to skip MIDI input. If you do very little in green (such as this example) it shouldn't cause a problem. But if you have the option of doing it in white, then I strongly advise to go with white; using the envelope to end a poly is very quick. Sadly, multithreading isn't of any help here either since you can't control the timing of multithreading.

[oddson]

...I've done some things with green MIDI as well and found that you can very quickly get it to skip MIDI input...

If you're talking about re-timing it in anyway then definitely it's not reliable but I"ve never had any trouble with standard MIDI rate data being transformed into single, alternate MIDI messages. But I can't say it doesn't happen.

[mwvdlee]

...I've done some things with green MIDI as well and found that you can very quickly get it to skip MIDI input...

If you're talking about re-timing it in anyway then definitely it's not reliable but I"ve never had any trouble with standard MIDI rate data being transformed into single, alternate MIDI messages. But I can't say it doesn't happen.

What I found was that if the green path is sufficiently long (I had some list lookups for filtering+translation), and MIDI notes (from a MIDI instrument) follow eachother fast enough (i.e. nearly at the same time), some notes seem to get lost.

[MichaelBenjamin]

i would also think that any green operation on midi messes it up somehow.
i remember that i tried to make a mono synth and use the white stream full with a depack and pack and 4 green triggers, so one midi note hits 4x and fills the white with complete 4 voices. this worked but when there were 1 oscillator behind you easily heard that sometimes the phases were off so the 4 green triggers did not send midi at the same time. this was in a similar way inconsistent like all other green stuff, so again it was not usable for a mono synth.

would be nice if there was some dedicated midi split module or midi voice doubling module that doesnt run in green, and lets us operate reliably on the midi data before it gets to the white section.

[oddson]

What you're both saying may well be, but I don't think it applies to splitting note events into two streams... I've done a lot more processing than that without problems.

I would hope in the long run that rock solid MIDI processing become part of SynthMaker... whether it's by the mythical sample rate accurate event mechanism or some other means; it seems to be a big missing piece from what these thing should be able to do.