sending poly to different synthesizers (within note ranges)

oddson · 30 Jan 2007

If I understand the question, there are two possible solutions that come to mind:

EITHER

Split the incoming midi and filter the notes into separate midi streams - run the results through separate poly streams and combine in the mono section.

OR

Make a code module that passes the poly to different ouputs based on the note values (pitch).

(I hope I'm not out-to-lunch on this 😇 )

overhishead · 30 Jan 2007

you still have to turn that midi back into something an oscillator can 'read.'

this runs into the problem of having multiple midi to poly modules in a project, which will cause crashes.

i was experimenting and accidentally connected a raw oscillator to the sound card out and the oscillator turned blue. then i connected a float number that i read off a midi mono thing and the float number made the oscillator go!

this would be great except the oscillator must be fooled into turning blue which takes more cpu and probably caused the crash that i just had.

if there was only a way to make an oscillator go without having to use midi to poly...

IS there a way to make an oscillator run without having to use midi to poly?

BasherT · 30 Jan 2007

since only one midi to poly may be used in synthmaker, how can that poly be directed to the appropriate oscillator module for a drum synth for example. lets say the drum synth you are trying to make has 8 oscillators.

I am not sure but I think you might have misunderstood what Stefan said in his reply to you in the other thread.

Stefan said:

Are you using more than one Midi To Poly converter for the same poly section? If so, that doesn't work since the converter also does the voice management.

I don't think Stefan was saying that you could not have more than one Midi to Poly converter in SM. He was saying that you can only have one in each poly stream. A subtle but important difference.

The key appears to be to keep the midi to poly converters in each poly stream separate.

I have drawn up a simple schematic that you could use as a basis for dealing with your 8 osc drum synth. It seems to be pretty stable on my machine.

OSM

This follows Oddson's first suggestion. Hope it helps!

oddson · 30 Jan 2007

Sorry... I responded to that thread indicating that I believe you can combine mono singals from different sources since the voice managment issue -- which is what Stefan had identified as the problem -- is not an issue with mono streams.

I think the code version would likely be superior. I'll bash something together to show how later and then someone like Stefan or Sambean can tell me where I've got it wrong. 😕 😉

I'm not sure if there would be any voice management problems with this approach since there would only be one MIDI-to-Poly component.

overhishead · 30 Jan 2007

maybe i am a little ambitious, but what i wanted to try was create a drum synth with 12 'drums' made of 2 oscillators each, and feed them all through a mixer with balance.

i can do it in mono, fine, but it utterly destroys the cpu. in poly it creates poly compile errors for having too many streams, i presume.

i try meeting it half-way by changing things to mono from end to beginning and by the time i trace back to my synth modules, but there is no good way to blend poly streams together. one will cut the other out.

can one create a mixer that handles 24 poly streams? my guess is 'no,' right? the problem keeps changing every time i change my approach, so its hard to be any more specific.

oddson · 31 Jan 2007

Here's what I had in mind:

multiosc.osm

In place of the rather more complex sample players I have simple saw oscillators.

I have made no effort to tune them. I just set them to different frequencies so that you can hear each (from 60-71) is responding to a different midi note.

There may well (read as "almost certainly is") a better way of achieving this but it demonstrates the possibility.

One major drawback is you are not able to map specific sounds to whichever note you want as the pitch values are hard coded. But you could remap notes by splitting and recombining the midi with some intervening processing (if you want details on this I'd be happy to explain).

BasherT · 1 Feb 2007

I have been sticking with Oddson's first suggestion of the midi splitter. I have produced a schematic with 12 synths each of two osc and a mixer with level and pan (balance) for each Osc.

Here it is.

It is no waldorf attack but it shows that oddson's idea works and the CPU stays at around the 5-8% mark on my PC which is not too shabby.

Hope this helps overhishead!

stefan · 1 Feb 2007

I think the CPU might end up being quite nasty once you start adding filters, envelopes, modulations, effects (if needed) etc. It'll be quite a huge poly section.

overhishead · 2 Feb 2007

thats really cool bashert,

i think my problem was trying to mix the two oscillators with one balance knob (in poly) and route the output to a fader and then a panner. seems SM doesnt like to do that. in fact, it seems like an impossibility. this is one limitation that if lifted, would really help processing speed.

that is, if i am to understand that poly uses fewer resources than mono.

i wasnt sure what my major malfunction was, so thats why two threads were created. now im pretty sure the midi thing isnt the problem. its the mixing of poly signals that stands out.

5010 · 28 Feb 2007

I think what would really help here is the ability to input an array. Imagine instead of multiple synthesizers, you have 1 synthesizer with many contexts. The contexts would be determined by an array per controller.

What if the following were possible:

polyfloatarrayin select[]; streamin pitch; streamin osc1; streamin osc2; streamin osc3; streamout audio;

audio = (select[pitch] == 0 * osc1) + select[pitch] == 1 * osc2) + (select[pitch] == 2 * osc3);

So with say select[50]=0,select[51]=1,select[52]=2 Assuming all 3 notes are playing at the same time, the code would output a single poly stream with osc1, osc2, and osc3 in the parts of the poly stream that correspond to the above pitches. I'm assuming this because I also assume that the code would be executed for each part of the poly stream within that context. Correct me if wrong.

Without the ability to index an input array, you would need inputs for each note's setting and test for each, or combine lots of inputs into an array and then index it. Either way takes many more steps than if you could input a pointer to an array primative and simply index it.

I wonder if the SM gurus would be interested in looking into array pointer types for code input/output because it seems very powerful to me.

Thoughts?

5010 · 28 Feb 2007

Wait... I see stefan addressed something like this in another thread.

stefan wrote: I was thinking that you put for instance sample index (as in which sample to play back) in an float array, then using the Float Array To Poly converter with a pitch-mapped index on the input to get for instance a pointer into a buffer where you have your sample data.

So if I get it, you end up with one poly stream with parts of it playing different samples.

That, plus the stuff I've been doing with zones is the answer.

And yes, not the beginner project by any means, but very powerful if successful.

So with that in mind, the ability to input/output array points is not so important as long as we are just using them to read settings within pitch contexts.

An application that requires code modifying the array might require something that powerful, but I can't think of one at the moment.