Bug (audio glitch with automation) : U-he synths return audio a few samples prior to receiving MIDI notes !

[Pere Founasse]

https://www.youtube.com/watch?v=KSw0fNV ... e=youtu.be

Reaper dev (schwa) :

OK, well that was a whack-a-mole situation. There is a one-sample bug in the current automation item transition code, but the bigger issue is that u-he Tyrell synth by design returns audio a few samples prior to receiving MIDI notes! So any automation that affects the output starting at the exact time position of the first MIDI note will miss the first few samples of audio.

https://forum.cockos.com/showthread.php ... ost2109151

[Urs]

I think the problem is rather that we smooth out automation. We don't do sample accurate automation simply because it would zipper. And zipper noise is commonly considered a bug.

I'd recommend MIDI Controller (ModWheel, PitchWheel, Breath Control, Expression) for anything that's suppsoed to happen "on time".

[Pere Founasse]

In this case, automation smooth is not the issue. In this video, there is no plug-in automation. Tyrell is not automatised at all. Only the volume track of the parent Tyrell track is automatised. The real issue is : U-he synths return audio a few samples prior to receiving MIDI notes. On the audio file we can see than Tyrell returns audio before the midi note !

[yellowmix]

Disable the PDC. You can find this in the I/O in the plug-in pin connector.

[Pere Founasse]

I have disabled the Tyrell PDC (in the I/O in the plug-in pin connector) and the issue remains.

[Pere Founasse]

Reaper dev (schwa):

The plugin behavior actually does not seem to depend on PDC. For example, if the synth is given a 128-sample buffer with a MIDI note-on occurring at sample 62, the plugin returns a block of audio that has non-silence beginning at sample 49. This behavior depends on where the buffer block falls relative to the MIDI events, therefore it differs depending on exactly what timeline position playback is started, and the buffer size.

Code:

eventlist.Get())->events[0]
0x000001484a27a378
type: 1
byteSize: 24
deltaFrames: 62 // note-on at frame 62
flags: 0
data: 0x000001484a27a388 ""
outbufs[0].channelBuffers32[0][48]
0.000000000 // silence through frame 48
outbufs[0].channelBuffers32[0][49]
-1.31550546e-13 // nonzero audio output starting at frame 49


In any case, there is a 1-sample bug in the automation item transition calculation, which we'll fix, but this plugin just happens to be not appropriate for testing the automation behavior because of its own quirks.

[Pere Founasse]

Reaper dev (schwa) :

The plugin does report PDC, so the behavior is by design. The only reason for a synth to report PDC is so it can do exactly this, return audio prior to the MIDI data. This isn't a bug in the plugin, it's just unusual.

[Urs]

Well, I'm not sure how other developers handle this, but typically digital synths run modulations at control rate. That is, they update them (envelopes, LFOs etc.) every 16 samples or so. Some even do chunks of 64 or more (I guess that's what Reaktor's "800Hz" setting is for instance). Anyhow, we do a control rate of 16 samples for all MIDI events.

Now, with that in mind, the control rate sets the granularity at which events occur, such as note ons and stuff.

With a control rate of 16 for events, the best timing is achieved by distributing those events to +/- 8 samples of where they occur. It is IMHO the best way to deal with the issue of control rate vs. sample rate. It's still an order of magnitude more accurate than MIDI ever was.

#-------

That said, I have sometimes thought about adding per-voice delays such that each voice could have it's output shifted into sync of the control rate with the MIDI notes. But this of course then only works for the Note Ons and not for the Note Offs, which would then possibly jitter even more. Not sure if that's of any benefit.

Our latest efforts go into reducing the control rate for events to 4 samples. This is also the control rate at which we process internal modulators other than MIDI. This is what we've done in Repro for instance, which should process with an accuracy of +/- 2 samples.

[Urs]

Reaper dev (schwa) :

The plugin does report PDC, so the behavior is by design. The only reason for a synth to report PDC is so it can do exactly this, return audio prior to the MIDI data. This isn't a bug in the plugin, it's just unusual.

That's not the reason for the PDC. The actual reason for the PDC is that we internally process everything in chunks that are a multiple of 16 samples. This lets us reduce CPU by a large factor.

PDC is not necessary if the DAW also uses buffers which are a multiple of 16 samples length, such as 64, 256 or 512. In that case, in our most recent synths PDC can be switched off (not in Tyrell N6 though).

[Pere Founasse]

Thx and about this ?

schwa

That's all fine, but the bottom line is, those plugins can return audio prior to the MIDI note-on, so they are not the best test case for automation items that are intended to affect the audio starting on the same sample as the MIDI note-on.

[Urs]

Thx and about this ?

schwa

That's all fine, but the bottom line is, those plugins can return audio prior to the MIDI note-on, so they are not the best test case for automation items that are intended to affect the audio starting on the same sample as the MIDI note-on.

That's correct, Tyrell N6 probably isn't, I'm afraid.

[Pere Founasse]

And it will change or ... ?

[Urs]

And it will change or ... ?

Never say never, but certainly not this decade.

[Pere Founasse]

OK. Thanks. Other u-he synths have probably this issue.

[Urs]

When will it not be an issue? 4 samples? 2? 1? 0?

If it's 0, are you willing to sacrifice 20%-40% CPU so you can draw sample accurate automation of the audio lane? Then, I'll ask, why, if you need sample accurate automation, don't you do it where then samples actually are?