Envelope Control module not sending correct Stage

[mwvdlee]

It is my understanding that the Envelope Control sets it's "Stage" output to 1 for every new voice and every retrigger for exactly one sample.

This does not work. (tested in 1.1.6)

I've hooked up some counters in my schematic, one that counts all the "stage(0)" executions in code, one that counts the number of times that the Envelope Control sets "stage" output to 1. The "stage(0)" code is executed more times than the "stage" output is set to 1. I don't know about retriggering since I have not yet found a good way of testing this, but for new voices this is definitely the case.

Here's a reproduction:

envelope_stage_bug.osm

(7.64 KiB) Downloaded 196 times

The bug only seems to appear with REAL Midi devices, not the "PC keyboard".
After some time of playing Midi notes, the two counters become unequal. The bottom one (1's generated by the Envelope Control) will be a bit less than the top one ("stage(0)" counter).

This means poly retriggering doesn't work.

[MichaelBenjamin]

i cant test this atm, but stage 0 only gets executed when a channel is empty, not when a voice gets retriggered on the same sse channel.
also stage 0 only gets executed with internal variables in the code box, the outputs from the m2v and green inputs, every other stream data doesnt exist at stage 0 and starts with stage 1
viewtopic.php?f=2&t=8676&st=0&sk=t&sd=a&hilit=stage+0+retrigger

[stw]

It is my understanding that the Envelope Control sets it's "Stage" output to 1 for every new voice and every retrigger for exactly one sample.

This does not work. (tested in 1.1.6)

This means poly retriggering doesn't work.

I gave my very best to reproduce that error. But gave up after reaching more than 2000 ticks without any glitches.
So i can't confirm the faulty retrigger. Tested with 1.1.7

@MB: You're right that was my first idea too. But if that would cause the error the stage(0) counter should be less than the env counter. But it seems to be the other way round.

[malc]

MB is right, stage(0) only gets executed when a channel is empty. If the same note is triggered continuously then the same channel will be reused so long as the release has not completely played out.

You have a very short 1000 sample envelope in that schematic. If you manage to get two plays of the same note within that 1000 sample window then it will skip one of your stage(0) counts. Increasing to a larger number of samples should make it even more likely for this to occur.

EDIT:
Just noticed what stw highlighted about the bottom counter being less than the top one. That would be strange. I haven't been able to make that happen. As you can see from the above I was observing the top one being less than the bottom.

[malc]

Now I can make it happen.

Using the PC Keyboard all I need to do is drag my finger from Q across the keys to I.

[aliasant]

Now I can make it happen.

Using the PC Keyboard all I need to do is drag my finger from Q across the keys to I.

Confirmed. The faster I drag the bigger the diff.
My result now is 56 on the upper and 46 on the lower.

This was using ASIO DirectX Driver with the ASIO Out. (This is something installed with Cubase I think)
When I switched to my MOTU Audio ASIO I got very little diff.

It seems to me the bigger the lateny is the bigger the difference?
Tried setting my motu asio latency to 96 samples and I couldnt get any difference.
Then swapped the latency to 1024 and it was easy to create the diff...

When I tried playing from my midi keyboard using Motu ASIO 1024 it was quite hard to get any diff at all. Had to play extremely fast and I only mangaged to get 58vs56

[stw]

It seems to me the bigger the lateny is the bigger the difference?
Tried setting my motu asio latency to 96 samples and I couldnt get any difference.
Then swapped the latency to 1024 and it was easy to create the diff...

Yes! Confirmed here too. With big buffers the error occurs easily. With smaller ones way less ore never.
I got my first error with a buffer >192 samples

[MegaHurtz]

Guess it`s confirmed here too, I cant get it to fail on direct sound.

[mwvdlee]

Well, atleast the confirmations mean I haven't gone insane when I noticed this

From my own (inexact) testing, it appears the glitches occur when two midi notes are triggered shortly after eachother (or rather, nearly at the same time).

[MegaHurtz]

Does it get threaded upfront?

[malc]

Not sure what you mean by threaded upfront MegaHurtz.

It seems this happens when a note is very short so the note on and note off come before any code is executed. When the note off comes the stage is set to 4 (for release) and so when the code executes it starts at 4 and not 1.

You can see this in that schematic by setting up another output that sends the stage out when the stage(0) tick is counted (stage&(tStage==1)). Whenever you get a mismatch between the counters you'll see that the new counter is 4 times the difference.

[MegaHurtz]

Not sure what you mean by threaded upfront MegaHurtz.

For the limited part I know about Asio,
is that it`s buffer is getting filled before the need to output it. hence the speedy startup.
Stages and stages.. But on a microcontroller stage 0 would yust boot once.
here using the shells is a bit different,
maybe theres some difference in the order of execution when you use an Asio driver,
where it overlooks the importance of the latter being pre-threaded aswell.
??

[mwvdlee]

Not sure what you mean by threaded upfront MegaHurtz.

It seems this happens when a note is very short so the note on and note off come before any code is executed. When the note off comes the stage is set to 4 (for release) and so when the code executes it starts at 4 and not 1.

You can see this in that schematic by setting up another output that sends the stage out when the stage(0) tick is counted (stage&(tStage==1)). Whenever you get a mismatch between the counters you'll see that the new counter is 4 times the difference.

One way to solve this would be by making sure every poly runs for atleast 2 samples; stage 1 and 4; a bit of a hack.

Another way would be to have the Envelope Control send different/new stage numbers, but that would break compatibility.

Or perhaps a new Envelope Control with new (bit coded) stage numbers. Obvious downside is having 2 similar modules.

Or in cases like this, send 1 instead of 4. Would be fine for me (since I don't care about 3/4/etc, only 1/not-1) but I think many others WOULD mind

[MyCo]

Hi,

just a notice to this behaviour: It depends on the buffersize of the audio driver. You can check that by lowering the latency settings of an Asio-Driver.

So I guess it has something to do with On and Off messages of the same note in the same bufferswitch event.

[aliasant]

Hi,

just a notice to this behaviour: It depends on the buffersize of the audio driver. You can check that by lowering the latency settings of an Asio-Driver.

So I guess it has something to do with On and Off messages of the same note in the same bufferswitch event.

lol


Look at mine and Tzarls posts higher up