From the original SynthMaker forum (2004–2014), with its members’ names and dates.
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:
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
stage 0 does not retrigger on stolen voice
stw ·
mwvdlee wrote: 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 ·
malc wrote: 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 ·
aliasant wrote: 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 ·
malc wrote: 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 ·
malc wrote: 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 ·
MyCo wrote: 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 😉
MyCo ·
yeah... haven't read all 😈
Tzarls ·
aliasant wrote:
MyCo wrote: 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 😉
But Aliasant, I have´t even posted here! LOL! 😉
aliasant ·
Tzarls wrote:
aliasant wrote:
MyCo wrote: 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 😉
But Aliasant, I have´t even posted here! LOL! 😉
LOL !
It was stw......Its his fault. stw !!! .......... 😊
malc ·
This is going to need some thinking. I'll add it to the list for the next release but for now I want to get 1.1.7 out.
mwvdlee ·
Been thinking about this issue yesterday and it seems to me that you can safely set the first sample of a (re)triggered voice to 1 always, even if there isn't a second sample, because either (A) there isn't anything to handle the release stage 4 or (B) if there IS something that handles the release, it'll keep the poly alive for atleast one more sample.
Sad to hear it'll have to wait a version as I really could use this, but since I don't expect to have anything anywhere near finished within half a year, I guess it isn't too bad 😉
mwvdlee ·
It's been well over a year now.
Is it really that f**king hard to have some module signal a "1" or boolean "true" for 1 sample whenever a channel is (re-)triggered?
The MIDI-to-poly modules obviously knows when this happens, why can't we?
mwvdlee ·
Still no news on this subject?
SM still isn't able to process incomming MIDI signals?
That SM lacks decent MIDI out support is bad enough, but not even MIDI in is reliable.
Seriously... how is this possible?
Every time I visit the forums, it's quieter than last time. SM is dieing and it is Malc himself that's killing it by an utter lack of support. If the most serious bugs and stability issues were fixed, people might be able to release SM plugins that would demonstrate all it's other features. As yet, every project I tried was forced to a halt due to bugs and the lack of stability in general.
What hurts most of all is that this bug is obvious and should be very, VERY damn easy to fix, and if I had the code I'd probably fix it in a few days. But this has been lingering on for far more than a year. Then again, there are other significant bugs that should be equally trivial to fix, and nothing's being done about those either. Instead, development is focussed on "kewl" stuff and leftovers from FlowStone. All very interresting and nice to have, but utterly useless if the most basic functionality is flawed.
Malc... time to grow up. Stop doing only the fun stuff and start doing what needs to be done.
infuzion ·
mwvdlee wrote: Still no news on this subject?
Well, Malc is on holiday, so don't expect anything soon. Also, he has rarely shown his face for about 2 years now? There can be user-made workarounds.
mwvdlee ·
infuzion wrote:
mwvdlee wrote: Still no news on this subject?
Well, Malc is on holiday, so don't expect anything soon. Also, he has rarely shown his face for about 2 years now? There can be user-made workarounds.
Since the original bug report was posted well over a year ago, "soon" has long since gone.
I've tried numerous workarounds. The problem is that SM simply doesn't report all new MIDI signal triggers and I have found no way of detecting them; SM is supposed to provide this information, but it doesn't. If you do know a workaround, then by all means please tell 🙂
Also I know of no workarounds for the stability issues. One interresting stability issue I encountered is that SM gets unstable when inactive for a while because Windows will swap memory to disk and SM can't deal with memory not being retrieved quick enough (it could simply return "0" as a fallback while memory is swapping back from disk to RAM, but instead it crashes). I tried keeping the memory active by having some code that makes sure every bit of memory is accessed at regular intervals; it only made SM less stable.
infuzion ·
Yes, SM does have memory issues for sure. Getting better though.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker