Give voice standard way to react on note stealing(soft mute)

[selvmarcus]

If one plays more voices than available at a slot, you can hear
the effect, that the Firmware cuts off/restarts the voice EGs immediately
as a short, sometimes very disturbing click.

This event could be logical signaled to the voice by e.g. keyboard module.
It could then switch to some fast release mode (soft mute).

Sometimes you may want a fast reaction, sometimes
something special could happen to the ´stolen´ voice,
as a musical useful expression (holding keys longer or
sustain pedal...)

(I am used to play with this already, e.g. stolen/auto-assigned voices start with higher level sometimes, I don´t understand the exact mechanism...)

selvmarcus

[3phase]

The voice allocation isnt the best part of the G2 yet. i think it desreves at least one alternate mode.. i very often get into situations where keyboard playing, internal and external sequencing come together and the given round robbin allocation is not perfect for such demanding situation...
There it would be better if allready held keys have priority...or internal keys get priority. I think earlier or later ther will be a version 2 for the G2...
as more useres request the real usefull additions as more likely Clavia might see a point in them.
Some optimisation or alternatatives for the voice allocation is defenetly one of this little but important items.

[Tim Kleinert]

The NordLead3 had clicky voice stealing too. Maybe it's a Clavia trademark.

[selvmarcus]

Maybe they wanted to compete with Waldorf?

The Microwave I was famous for this.

And they had very good argument going why this was technically superior...



-------
Marcus

[Fozzie]

[Kassen]

[selvmarcus]

Yes... but latency for a note-on in the range of lets say 3-10 milliseconds
to get rid of that nasty "chk" would be ok, no?

Also I really like to use it as a way of musical expression too,
like when I play chords and then change some notes,
keeping the other notes for longer, raising fingers late, it could play the new notes with
faster attacks or similar stuff.

Can you tell how the voice allocation is working?

I might start some experiments.

Does it just restart all EGs with KBD gating enabled?

So if you are not using these and no osc with KBD tracking either,
it will do nothing?

It could go to attack phase from "current level" instead of
zero level in the EGs, no? Maybe a new mode?

Fozzie wrote:

[Kassen]

[Kassen]

[3phase]

[selvmarcus]

Interesting, thanks for your posting.

First, I noticed my topic title is somewhat misleading. Should be something in the lines of
"OS should give spawned voice a signal, that it wants to pre-empt it". That´s what I mean. OS choses the voice, and just
tells it "Hey, I need you for something different. Here is the new note-number.
Would you please be so kind to do something appropriate?"


Also OS would change any pitches in osc with KBD-track mode on,
and re-gate (off and on again immediatly) EGs with KBD-gate enabled.

So the standard reaction would be to retrigger the EGs, not to
start with zero level, but with current level.

Maybe maybe EGs could have another Restart-input with an associated
"coming down" rate.

What I do not understand, is why the OS has to do alll this flushing,
resetting etc. We can do that, if we want to and the default
behaviour would not be much worse than now.


Anyway, can we work around it with the current OS?

Receive notes only at one slot special for that purpose,
allocate voices according to some scheme,
and give signal to a specific voice?

We can start voices, can´t we?

So we spawn all of them first at patch activation. They keep quiet,
until...

...we send to voice note-on as one or more MIDI-controller, voice
compares with its voice number from status, if it matches, it would react (or not).


-----
Marcus

[selvmarcus]

Or better.

We catch note-on/off in one slot or fx, if there are any voices available,
(we count), we send them along, if the house is full,
we send note-off with high release velocity and put the note-on
in some delay coded as a sample.

So voice could check for fast release (note is pre-empted).

Oh, I see, the NoteReceive mod is too limited. Only one note number.
We would need 128 of them

Maybe having some fake voices in one slot, acting as a relay...

I should study the system first, sorry.


------
Marcus

[Kassen]

A partial solution occured to me that might work for patches that get lots of polyphony anyway yet also require a lot of voices (due to the composition) and still "click".

Make sure you set priority to "last note", I can't remember wether you can do that but I'll just asume you can.

Take a constant and within your voice have it put a "1" on a system bus. Read that bus out; that's how many voices you are getting.

Ok now for the wizardry; take a mixer, put the constant you already made (to save zero page) put it on it at unity gain. Feed it to a S&H and feed the S&H back on that mixer, also at unity gain.

At note on; trigger the S&H. Now there is a "1" in it, this signifies it's the latest voice.

Take keyboard module and detect when the "last note" output changes (You do that by comparing it to the value it had last sample, if those aren't the same it changed).

Trigger the S&H every time that changes as well.

What does this do? Well, we are counting keypresses... Once the value in the S&H equals the value on that bus we know this voice will be next in line to be recycled. At this point we can fade it out as fast as we dare. If we fade too fast it'll click, if we fade too slow the voice might be killed before we are done fading.

This is a bit naive as a aproach because the G2 will recycle a voice if it's not the next in line but has the same notenumber asigned as the key that's being pressed. You could get around that by storing what was done since your voice got spawned in a little array, then compare the new note to all members of that and substract 1 from the S&H again if it's already in the set and ONLY THEN test the S&H's content against the bus's but that will cost quite a bit of overhead, zero-page wise. If you would do that then voices that are re-spawned because their key is re-pressed might still click anyway. I'm not proving it here&now but nothing will get around that. You'll have to swallow that.

I've said it before but; Here be dragons.

[3phase]

[Kassen]

selvmarcus, our posts crossed, I submitted mine anyway because it seems to answer some of the issues you are running into in yours. I recognise your train of thought; I've been there.

I don't understand why the OS has to have "flush" as a deafult either, I'd rather flush manually and I'd rather have some section of the patch where I could determine wether I needed to flush at all.

My advice to you is to either let this topic go and swallow the occasional click (the clicks aren't the worst of it) or evacuate as soon as possible. Dealing with this stuff in the G2 will drive you crazy (note there is no G2 in my studio). Install SupperCollider, take MAX-MSP or ChucK but don't try to deal with this on the G2 because that's a dead end.

[Kassen]

[3phase]

but we are in the wishlist here..discussing an item might lead to a specific module wish that allows to patch such thing..

I am sure Clavia have decided to live with the clicks as price for low polyphony settings. Additional latency must be avoided..it can kill the market postion of an instrument when its the one that is allways late... You do beats with the NM system aswell.

So if any voice/key/alocation module would help to overpatch such problems we should formulate a wish for that specific module...

Its much more likely that Clavia sees a point in that rather than restructuring the whole instrument.

Just the question.. what is the missing module that solves the problem?
And maybe has a bunch of other good uses aswell...

[3phase]

[selvmarcus]

sven wrote

[Kassen]

Well, what I was sugesting with the "code" bit was multiplexing CC's and generating those on a computer in something like MAX or SuperCollider or some speciffic Synthedit vst that you would build once then use forever with that series of patches.

That way you could basically take the voice alocation outside of the G2 to a place where you could define it all yourself and get around any of the limitations of MIDI and the G2 at the expense of making it all a lot more complicated.

I don't think there is any one module that could solve it within the G2 framework. I have some ideas that would be usable in digital modulars in general but those depend on inter-voice comunication and in the G2 that means inter-cpu comunication and that's a bottleneck. I talked about those with Rob and he liked those but we also had to agree that those plans still worked within a framework that's limited and -well- flawed.

This stuff is simply very hard to solve in general; polyphony hasn't been updated in any signifficant way since it came on the scene because even if it wasn't perfect; it worked and nobody had a better idea and plenty of clever people must have thought about it. I still think that for -say- some CEM based analogues it works perfectly fine but for modulars it's my opinion that it breaks down. We need some new good ideas and we especially need ones that work so well in such a simple way that people want to use them and then will realise what the problem was, all those years. Clearly; even if you can solve it in SC if you want to; I don't see the average synth player jump for joy at SupperCollider because that's a bit too hard and not all that intuitive to many.

One big issue is that many systems and especially the G2 work with a graphical interface and because voices are paralel processing they are inherently hard to visualise as is their interaction. Perhaps the biggest isue is visualising the problem so well that people can pick their own solution easily. I admire that problem but don't look at me for a solution... :¬)

Back to the here and now; even after all the ideas posted above I would say that the best plan right now would be trying not to use very long decays on patches where quick playing is needed, setting note priority right, getting a expansion if you run into this and finances allow it and overdubbing if need be. Tactical reverb use and filtering may help as well.

If you realy want a concrete simple module to put on the wishlist i'd go for this;

A module that has four outputs; "lowest note in use" (outputs cv) and "highest note in use" (dito) "lowest note held" (as in; the key is currently pressed) and the same for "highest note held". That would give you a lot of info. Theoretically you could have a module that would simply output all CV's for all notes in the system but as you could have 32 voice that would eat zero-page for breakfast so let's not go there. I think the man isue here might be strings where clicks would be very noticable and with a module like that you could have some tuned filtered reverb to tactfully mask it all.

Mind you; I'm just making that one up as I go along, chit-chatting and sipping wine so perhaps somebody might want to think it all over a bit deeper. :¬)

[3phase]

[Kassen]

[3phase]

[Kassen]

[Kassen]