Voice stealing

[stw]

this topic was shortly discussed here
It wasn't answered in the thread but I think this is a very important issue because IMHO that's an unusual behaviour. So i want to bring it on the table again.

You mean that if all voices are taken by held notes, new note on's should be ignored?

No. I mean that if for example all 8 voices are taken by 1 sustained note and 7 released notes that are fading away the sustained note shouldn't be the one that gets cut out even if it's the oldest note.

This would allow playing voices with long release values two handedly.

I noticed this too and think thats a very strange behaviour especially when playing with long releases . Did i miss something and that kind of voice management could be altered already, or is this still the only way SM handles voices?

[stw]

Since i got no answer i bump that.
That is an important issue IMHO.
Anyway if nobody got an idea to that i'm gonna initiate an official request.

[MichaelBenjamin]

you cant do anything about the voice spawning/cutting behaviour besides the options at the midi2poly.
and yes, for a synth it would be nice if we could have some more control over the single voices in a stream, and maybe a trigger that only fires when a voice is stolen, so you could do a custom fade out on the old voice. thats said, i would like the stock adsr4 with stream inputs that retriggers at the attack phase.

btw eskas unison asm did access the single voices in a stream but somehow information got messed up in the process so the envelopes did not react correctly anymore.

[infuzion]

Has anyone tried to create a better voice management using MIDI Splitter, Note Event, & some green logic?

[stw]

Has anyone tried to create a better voice management using MIDI Splitter, Note Event, & some green logic?

I don't think that's possible. Though you can do fancy things with your Midi data you still need the midi to poly module to create a controlled stream (which means every poly data is addicted to one special note). And either the Midi to Voice or the Voice to Poly prmitive handles the actual voice management.
Anyway if you proove me wrong i'd be glad.

[Tzarls]

Thinking about infuzion´s post:

A module exists that allows you to keep track of played notes, in the order they were played. That module even allows you to keep track of the notes that are no longer played (note off events). That, combined with MIDI mono (to restrict polyphony ) and some logic could achieve a voice manager, IMO.

[stw]

Thinking about infuzion´s post:

A module exists that allows you to keep track of played notes, in the order they were played. That module even allows you to keep track of the notes that are no longer played (note off events). That, combined with MIDI mono (to restrict polyphony ) and some logic could achieve a voice manager, IMO.

Infuzions idea was my first thought as well. And yes it IS possible to keep track and shift anything on the midi side.
But if it comes to poly section we can't do it because we can't intercept the way SM initiates or cuts streams related to a specific note/order. It's carved in stone that the first stream is killed if max polyphonie is reached.
That's no deal of Midi ON/OFF messages. In fact if we follow the problem here we have most of the midi notes which still are played in the poly section (e.g. long release time) OFF and only few ON.
E.g you play and hold an Octave in the left hand and do some moves with short notes with the right hand. Every right hand note is only ON for a short while but the stream is still active.
What you need to do now is to kill stream number three and ascending with new notes. But you can't access a specified stream manually because you've no possibility to seperate it.
SM itself provides a kind of workaround with the "retrigger stolen" boolean in the Midi to Voice primitive.

Maybe I miss something here?

[Tzarls]

I was thinking something like:

MIDI2Poly : max voices 32 (for example).
With a MIDImono you restrict polyphony to something lower (you can do this by checking how many notes are being played at a certain time, and if it´s not the maximun allowed, keep on passing triggers for new notes). Let´s say you decide you synth will only play 10 notes (keeping in mind that you can play ten new notes, with tewnty "trails" still decaying, and you wouldn´t be hitting our MIDI2Poly max of 32, thus not having SM interfere with our system). . You play your octave with the left hand, the notes are stored in an array. You play short notes with your right hand, the note numbers enter and exit the array. Now, you can decide how to treat this numbers when (max notes + 1). For example, you can define a rule to never kill notes below a certain note, so you could have your left octave always intact. For that, you just need to do some logic so new notes will be stored in our array from a certain index and up.

Or maybe I´m not getting your point (which could be, since english is not my mother tonge). Or I totally overestimate SM´s abilities!

[stw]

For example, you can define a rule to never kill notes below a certain note, so you could have your left octave always intact. For that, you just need to do some logic so new notes will be stored in our array from a certain index and up.

Or maybe I´m not getting your point (which could be, since english is not my mother tonge). Or I totally overestimate SM´s abilities!

Hm...
yes, yes and erm ...yes
You can define rules and tweak the incoming midi data as you like. But you have only two choices - put them into the poly section or not. Because you hit a key on the keyboard you definitly WANT the note to be played so that's only rhetorical.
As soon as you put it into the poly section you've no further control over it because SM handles it.
You can't tell SM which stream has to be killed in exchange to a new one and which not. But that would be required. You have to tell SM which stream has to be cut before you inject the next.
What you're trying to do would work if you build an x-voice Mono Synth with x copys of of signal processing instead of one x-voice poly snth.

[Tzarls]

Well, you can tell the poly to kill voice number 1 (or the first note played) by sending a note off to the correspondig voice. So, from the array, we now that MIDI note 60 was played first, and now I want to kill it, so I send a Note off to midi note 60. Now, of course that´s not total control over SM´s streams, but at least would give some control over the voices being played IMHO.

I think I don´t understand the x-voice mono synth vs x-voice poly synth comparison, would you elaborate on that? Because I thought that if a synth has more than 1 voice then it is poly.

[MichaelBenjamin]

maybe a simple addition to the v2p module would suffice, so that it simply looks for killable notes being in release stage before killing the oldest.

[infuzion]

maybe a simple addition to the v2p module would suffice, so that it simply looks for killable notes being in release stage before killing the oldest.

Then you'd need the voice ID system for the green-MIDI data... very messy!

But your idea gave me this idea:

Code: Select all

When the number of voices > voices ceiling //Max Voices-2 or so
{
  Kill the envelopes who is in Release & whose output is below a certain level
  ~ or ~
  Kill the oldest "Voice Tag" from the Voices to Poly //how does that work please?
  ~ or ~
  First round: find the oldest sample counter //called "cnt" in SM's envs
  Second round: kill the voices near the oldest sample counter
}

All this assumes that there is some master-volume envelope somewhere. Since all of these require atleast 1 round, likely inside a hop() that is not always running but every so often, then you'll need to dump voices before it actually reaches Max Voices & a new note comes in. So the actual voices active will be Max Voices-[1..4]

IMHO, much easier to have Max Voice to 64 or 100 if SM can handle it; I'm unsure of the maximum Max Voices. If your CPU is too high, you'll either have to reduce the features or your OSM, or ASM it all.

[MichaelBenjamin]

why would you need green data? it seems the voice id is passed into the v2p module and the killing happens inside it.
atm there would be only a check for oldest with a kill if incoming greater than max. if you added a check for release stage you could kill only the oldest released notes, and if there are no released, then just kill the oldest.

[infuzion]

Why would you need green data?

IF you were to go with my original idea of tracking notes on before the MIDI to Voices using MIDI Split & Note Event, & creating new Note-Offs to dump old voices. I'm not sure that will work now; that's why I think using envelopes are better.

I still believe that a user-module can do what you want it to do, so Malc doesn't need another thing on his 100-item agenda to do.

[MichaelBenjamin]

yes, its just that i think green data is too loose on timing to be really usable for feeding the v2polystream. maybe for controller data, but not for note data. and i am not the one that sends secret bug reports every half week to intentionally delay the 1.3 beta;)