3rd Party VST issue

Dorico
#1

Attached is a file that exhibits the following anomaly in playback.

When using a 3rd party VST (e.g., Pianoteq) the half note in the bass sometimes plays back as an eighth note staccato.

This is repeatable (but not consistently so) by doing the following:

  1. Select the half note in the bass clef.
  2. Play from that point (type p)
  3. when it finishes press p to start playback again.

Sometimes it plays back as a normal half note, other times it plays back as a short staccato note.

You may need to repeat playback several times to exhibit the problem, but it will happen fairly soon.

This problem does not occur when using the default Halion player. Originally I thought this was the same as the first note in the flow problem with articulations, but I have a full measure of rests at the beginning of the flow. So this is something else.

It seems that the staccato notes in the treble clef are affecting the playback of the bass clef voice on subsequent plays (but only some of the time).

It also happens if you interrupt playback after two or three of the treble clef chords and then begin playback again.
test.dorico.zip (176 KB)

#2

I have the trial of Pianoteq 6 here and I can reproduce the problem as you explain. It happens not so frequently, but it does.

Strange thing really is, that it doesn’t happen with HALion Sonic SE. I don’t have many other instruments here to test with, but Retrologue and Padshop also behave fine.

That it only happens with Pianoteq would suggest that it is a problem on the instrument side.

Anyone else experiencing the described behaviour with other instruments (Ivory, Kontakt,…)?

#3

Ulf, I think you might be right that this is an instrument issue. If fact I think it is a Pianoteq 6 VST 3 issue. I’ve tried Kontakt, Aria Player, Pianoteq 5 VST2, Pianoteq 6 VST2, standalone Pianoteq 6 and none of these ever exhibit this problem. Only the VST3 version of Pianoteq. I’ll file a support issue with them about it.

#4

Revisiting this issue with some midi data. I have a support ticket submitted with Modartt but wanted to at least give you some more data. Pianoteq has a midi trace feature in the Options tab. Three screen captures are shown here: File “note on-off normal” shows what happens when it works correctly. Files “note on fail” and “note off fail” show what happens when it doesn’t. Note that in the latter two midi traces there is a flurry of “all notes off” messages immediately after the “note on” or “note off” event. So Pianoteq seems to be doing what it is told. The question is what is creating these “all notes off” messages.

By the way, the only thing you need to exhibit this problem is a single half note in the score. When starting playback directly from that note it will sometimes fail and sometimes not. If you select a rest of any length prior to that note then it will never fail.

note on-off normal.png
note on-off normal.png1126×460 68.1 KB

note on fail.png
note on fail.png1118×474 64.2 KB

note off fail.png
note off fail.png1114×464 63 KB

#5

Have you got “humanize” switched on in Dorico?

One of the failed cases looks a bit like the bug when the first humanized note started before “time zero” in the score.

I wonder if the other one is when the last humanized note ends after the “end time” as calculated from the notation.

FWIW sending “all notes and controllers off” messages at the end of playback is fairly standard - it resets the synth back to a well defined state, as well as cleaning up any notes that really were hanging.

#6

This looks like Dorico may perhaps be not clearing the buffer after doing all notes off, so it’s accumulating a few of them. That could indicate a Dorico bug. However I would expect a plugin to handle multiple all notes off messages without problems

#7

Couple of comments.

@rob - Humanize doesn’t matter. Problem exists even when it is turned off.

@Paul - The issue isn’t the number of all notes off events, it’s the fact that it starts happening between the note on and note off event in the fail case. I showed two files in this case because it wasn’t possible to fit the entire midi stream in a single screen. Compare the two failed files with the normal file. Normally there is no all notes off between the note on and note off for the existing notes in the score. But in the failing case, they occur immediately after the note on event and continue until the the note off event and then continue again as normal.

@everyone - this is only an issue with a third party (in this case Pianoteq) VST3 format. VST2 works in all the plugins I’ve tried. Halion works all the time also.

#8

That is very curious because HALion is also VST3. If it was a more general problem I would expect HALion and other plugins to cut the note short too.

#9

This is why I am reporting it. I will note that this is Modartt’s first VST3 plugin, so it could be something on their end. The other problem they had (the mic feedback issue reported elsewhere) was an initialization problem of the VST3 plugin. It was also a VST3 only issue and only with Pianoteq. So this could be a similar problem. But the midi stream might indicate a Dorico problem. I don’t know.

#10

[Post edited]
I didn’t know about that MIDI monitor in Pianoteq and I had now a close look myself and found the following:

On start and stop Dorico sends All Notes Off and All Controllers Off messages to all 16 MIDI channels; these messages have always the same time stamp.

In the non-failure case, the first Note On has a time stamp slightly higher than the All Notes Off.
In the failure case, though, the first Note On has exactly the same time stamp as the All Notes Off, and also, in Pianoteq’s monitor the Note On is displayed before the first All Notes Off on that channel.

So this would explain the shown behaviour. Pianoteq starts generating the first note and then breaks off again because of the All Notes Off command at the same time.

Again, this is another indication that Pianoteq VST3 is behaving badly, because earlier versions and other VST instruments can cope with the same situation.
Looks like the VST3 version somehow reorders or differently prioritizes messages.

#11

Ulf, look again at the midi trace. Scroll up and you’ll see the note-on event. You may need to stop playback as soon as you notice it fails, so the data doesn’t Scroll off the top.

See the files I posted also. The note-on and note-off events are separated by a lot of all-notes-off messages.

#12

Damn it :wink: Already before reading your post I took a closer look again and then edited my previous post, but then you came already with your new one. So please have a look at my edited post…

#13

hmmm. I might consider this a midi chase issue. It seems that the all-note-off events need to be time stamped earlier than the note on event so that midi events can be guaranteed to be ordered properly.

This would explain why when starting playback from a rest before the first note always works. I tried tests as small as 1/1024 duration, and these work.

#14

But all other instruments (or at least the ones we tested) can cope with it as it is…

#15

All other instruments that you know of.

Consider that pianoteq vst3 is the first one to take advantage of multiple cores to process an incoming midi stream. Midi events are ordered by a time stamp. So multiple cores can operate on events with the same time stamp in parallel. The only way to guarantee the proper order of midi execution is to time stamp it appropriately.

Any chase events that Dorico inserts into the midi stream to prep playback need to be time stamped earlier than the actual notes or you get what we’ve observed here.

#16

I’ve tried with the VST2 version of Pianoteq 6:

Here I saw always the proper order of events in the monitor, i.e. the All Notes Off/Controller Off messages for ch 1 to 16 and then the Note On.
It happens rarely, but I also saw that the All Off messages had the same time stamp as the first Note On, still, the Note On was displayed after the All Offs.

So again, this suggests to me that the VST3 version reorders the messages somehow.
Because Dorico does not treat instruments differently, it sends out data always the same way.

#17

Reordering midi is fair game at any given time stamp.

#18

By the way. This is not the first time we’ve seen this problem. The steam 5371 thread is the same issue. This one with VEPro which is also a vst3 device.

#19

The STEAM-5371 issue is completely different - that is about negative timestamps. We don’t know that the events shown in the Pianoteq window are actually correct.

#20

That’s right. I do believe that that what the Pianoteq monitor shows, is really the order of how it plays back events but not how they actually arrived and that there is some reordering taking place beforehand. To me the logic looks like: When events with the same time stamp arrive, take first the note events and then others.