From the original SynthMaker forum (2004–2014), with its members’ names and dates.
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.
matti wrote:
stefan wrote: 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 ·
infuzion wrote: 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 ·
Tzarls wrote: 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 ·
Tzarls wrote: 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 ·
MichaelBenjamin wrote: 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:
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 ·
MichaelBenjamin wrote: 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;)
infuzion ·
MichaelBenjamin wrote: ...green data is too loose on timing to be really usable for feeding the v2polystream.
Good point; I didn't think of that! My thoughts were that it would be too hard to track what note is what.
and I am not the one that sends secret bug reports every half week to intentionally delay the 1.3 beta
I'm not that smart; I've just been around for a long time! 😇
BTW Mr Project Manager, the Envelope Control can shut off voices. Any more help than that I'll have to charge you 5-25/hour USD 😉
stw ·
infuzion wrote: BTW Mr Project Manager, the Envelope Control can shut off voices. Any more help than that I'll have to charge you 5-25/hour USD 😉
Maybe we can do it without charging you 😉
I' ve come far but until now it is as expected: The interaction between green data and poly section isn't doing well.
I'll try further...
Anyway even if it will do the job it'll be only a workaround. You always have to deal with some kind of delay which can't be a seroius solution. It' should be far better and faster and more simple to change the rules inside the voices to poly section.
stw ·
ok it seems as if the last post was a bit overhasty... 🙁
I created the logic to control the voices but i'm stuck at exactly the point which was actually obvoius.
The journey ends where we need explicit stream identification. That is where the voice tag comes in.
This was discussed months before but i couldn't find an actual statement about it.
I'd be glad if this could make it into the next beta. Maybe somenone can comment on this.
infuzion ·
stw wrote: Anyway even if it will do the job it'll be only a workaround. You always have to deal with some kind of delay which can't be a serious solution. It' should be far better and faster and more simple to change the rules inside the voices to poly section.
Perhaps it could be better for Malc to edit the Voices to Poly, but I suspect if we do it right, then our code will become part of SM, just like the De-zip primitive.
stw wrote: The journey ends where we need explicit stream identification.
If you follow my plan, you don't need any stream ID; just need to track what max value for the envelope index is.
Lui ·
this is an old thread but did someone ever succeed in changing the voice stealing behavior in a way that a pressed note gets kept or sth similiar?
trogluddite ·
Hi Lui,
The basic problem with the poly voice manager is still the same. The whole poly system is very hidden away inside SM's engine, so there no way to change the voice allocation unless the developers re-write the MIDI-to-Poly primitive.
Earlier in the thread, it was mentioned that making a custom voice manager using "Green" and mono streams might be possible.
I have done quite a bit of work on that method, but it is quite cumbersome - 4 or 8 voices is manageable, but it gets very messy the more voices you add, and CPU load is higher because the voices are always playing, even when you don't hear them.
However, I think it can be useful as you can also get around other "preset" behaviours of the stock manager - for example, normal poly voices always reset oscillator phase at note-on, whereas a "blue/green" system allows for genuinely free-running oscillators. So, if there is a very particular behaviour that you need, and don't mind the CPU and voice-count compromises, it might be worth trying.
You can see some of my experiments with a four voice version on the Green Voice Manager thread - and I'm currently working on an 8 voice synth using very similar modules.
Lui ·
thanks for your detailed answer, Trog.
i looked at what you did already and even tho it seems really cool, i need to stay in poly.
i hope there will be an update someday. voice management would be one of my most crucial needs.
peace, lui
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker