Pressing Start cuts any MIDI Notes being played

Cantabile
1

Hi folks. I have noticed that when I press start on the Transport (either directly in the GUI or via a trigger on my MIDI Keyboard) this cuts off any MIDI Notes being played. Usually (until today) I run backing tracks then start playing MIDI notes so this issue hasn’t cropped up before but for a new set I just need to have the transport playing to run some sequencers but I was hoping I could hold some notes (Pads/Sustaining notes) and then start the transport while these notes were playing but “Start” seems to send a global MIDI Note Off or something… When I stop the transport held notes are fine, only when I press start… How can I get around this?

Hope someone can help?

Thanks!

edit I’ve actually noticed that its not all VST Instruments but UHE Bazille is certainly impacted so I guess is there some way I can filter out the transport trigger perhaps from a specific VST?

2

If you have Pluginguru Unify, you can set its transport to “Don’t follow host” and load any plugin you want to shield from Cantabile’s transport changes inside of it. That’s the only reliable way I’ve found to get transport-independence for individual plugins.

—Kevin

3 Likes
3

Not really sure what’s going on there. Could your MIDI file have an “All notes off” event at the start? Perhaps use Cantabile’s MIDI monitor on the plugin to check what MIDI is being sent to it - it might provide a clue.

1 Like
4

Thanks @Hamlen - I might give that a shot but noticed the V2 seems pretty pricey but I might see if I have something similar (a host within a host type VST) and see if I can get it working.

Thanks too @brad - I don’t actually have any Media Players, I’m only using TRK-01 to play some basic drum sequences and this is working fine/as expected. It is Bazille VST3 that cuts when I press play on the Transport. I have since added another VST3 (Knifonium) which DOES continue playing/holding the note while I press play. So it seems although both patches in Bazille and Knifonium are arpeggiators (so rely on clock info from Transport to sync - not necessarily transport playing), Knifonium seems to take the Transport clock and won’t cutoff when pressing Play but Bazille does. I’m not sure if there is a setting in Bazille that I will investigate using MIDI Monitor to try and narrow down what is happening.

Its not the end of the world - just a new project I am working on where I have this new approach/setup so I can work around. I’ll test a few other synths and see if the same issue occurs and come back with any findings.

Appreciate the feedback from you both - so thank you :slight_smile:

5

Well the MIDI Monitor didn’t provide much information when monitoring the Bazille MIDI Input or VST (no MIDI input being received when pressing Play on Transport and no note off per-se being received - the audio just stops (no tail)) so I guess there is no way to simply filter out Transport (and if I did not sure how Bazille would get clock info). However I did get recommended to try the VST2 version so downloaded this via the legacy downloads on UHE site and I don’t have the same issue so I guess the issue is with the VST3 architecture somehow… Not a huge issue just a little pain as trying to ween myself off VST2s.

I’ll keep investigating but VST2 Bazille seems to have fixed the immediate conundrum!

Thanks folks! :slight_smile:

6

Ah ok. So it’s not a MIDI event causing the cut-off but seems like just the behaviour of the plugin when transport state changes. Probably worth mentioning to u-he to see if there’s a workaround or perhaps it’s an edge case they’re not aware of. Be sure to mention the bahaviour is different between VST 2 and 3 versions.

1 Like
7

Thanks @brad and will do. I’ll report back here with any outcomes from u-he just incase anyone else hits any similar issues.

8

FWIW I have a similar problem with a song where I play free form and then start the transport.

This is with U-HE Repro-1. It’s exactly as you describe: I can be holding a note into Repro-1 and it gets cut when I start the transport

I have moved to the VST3 version, so will “downgrade” and see if the VST2 version is better. I suspect it might be, as I do not recollect this issue when I first put the song together

I’ll check later today and report back.

Happy to to coordinate with you on an issue report to U-HE to see if we can get it changed.

1 Like
9

Hi all

UPDATE to my above post…

Yes, the same behaviour is also true in REPRO-1. If I use the VST2 version, the note holds as required, so I could revert back to that version temporarily.

I’ve also verified the same behaviour occurs in Cubase 15, so most definitely a REPRO-1 VST3 change of behaviour issue .

Note: both versions cut notes when the transport is stopped, which is logical behaviour.

I have submitted a bug report to U-HE.

I was wondering if there is something in the VST3 specification that requires this behaviour, but a question like “does a vst3 plugin have to cut sound when the host transport starts” into Google in AI mode indicates that this is not the case.

1 Like
10

Glad to hear I’m not alone and it does seem to be just my u-he VSTs (VST3 versions) that have this behaviour (Bazille and Diva). I’ll be raising a ticket with u-he also so hopefully they can get this updated at some point. These are the only VST3 VSTi’s I’m aware of that have this behaviour (so far) so fingers crossed. Atleast, as you said, its straightforward to replace the plugin in Cantabile with the VST2 version and load in the same/shared patch!

1 Like
11

I’m glad that you posted this here, as this has been driving me nuts for a while, and hadn’t considered it might have been a VST2/VST3 difference…

Here is a transcript of my bug report to U-HE.

Hi

Load Plugin into Cantabile and set up audio and MIDI routes
Load preset Local/04 Effects/XS Star Drops (or any preset, but this is the one I use in my song where this is an issue)
Without the Cantabile Transport started, play and hold a note in REPRO-1
Now start the transport, and the note being played will be stopped

This behaviour also happens in Cubase 15

This does not happen in the VST2 version of REPRO-1 (note that I had to download a legacy version of 113 as the latest repro installer removes the VST2 version)

Can you please update Repro (and I guess your other synths) so that notes do not cut when the host transport is started? I am moving away from VST2 as much as possible, so would really like this behaviour to match the VST2 version.

It’s a problem for me, as I have a song where I am playing a free form intro and then I start the transport whilst holding a note in Repro. Since moving to the VST3 version, the note is now cut off, which is spoiling the intro

I noted that both VST2 and VST3 versions cut the sound when the transport stops, so it is only the transport start behaviour that is different

Regards
Derek

1 Like
12

There is indeed no such requirement, but VST2 → VST3 migration does require a redesign of how the plugin detects transport stop/start. So if the VST2 vs. VST3 behave differently, it seems likely that it’s a bug in their migration to VST3.

Neither VST2 nor VST3 negotiate transport via explicit midi messages, so midi monitoring isn’t helpful for diagnosing. Hosts communicate transport state to VSTs via API calls.

–Kevin

13

Hi, all

Here is the response I had from U-HE

The note is cut off because of the reset command the host sends to the plugin when starting the playback. When this command is received, we reset audio and MIDI streams.

If the host sends this or not can depend on the plugin format. This could explain why the VST2 is not resetting while the VST3 is.

With the next update we will add a new option to the preferences so users can disable the reset.

Some hosts also have an option to disable this reset. For instance, in Logic that’s found in the track settings. Might be worth to check if Cantabile got this as well.

I am not aware of such an option in Cantabile, but @brad is there a difference between VST2 and VST3 handlinging in Cantabile that is different and is this setting something you can consider?

I’ve asked U-HE when the next update is…

1 Like
14

I’m not really sure what “reset command” they’re referring to.

When starting transport the only real difference the plugin will see is kPlaying fag of the ProcessContext::state variable will be set and the transport position will start updating.

Please pass on my contact details to the person you’ve been dealing with and hopefully we can work this out.

15

Thanks @Brad

Happy to do that, but since then I have had a further dialog with U-HE, so review the below before you think it is worth digging further

I replied

So are you saying that the VST2 version would also respond to this reset if issued by the host, and thus it may be a difference in how Cantabile is managing VST2 and VST3, or that it is a difference between the VST2 and VST3 specifications?

An option to ignore the reset would be good, but I’ve also passed your information on the the Cantabile developer to see what he says.

When do you think the next update will be? I’m happy to do an informal beta test if that helps. For now, whilst I was trying to remove VST2 from my system, I can switch back to using the VST2 version of REPRO-1 for the song I mentioned in my report

The U-HE representative replied

If a host sends the reset, then our plugins usually listen to that reset no matter which plugin format is used.

However, how the plugin responds can also vary depending on the plugin format.

I remember we added the MIDI reset in one of the last updates. We had to do this to fix some issues users reported. Since the current version of Repro does not support VST2 anymore, it might be possible that The VST2 version you used is older and did not include the MIDI reset yet. But I can’t say it with certainty right now.

I also can’t tell you when the next update will be due. We already implemented the reset preference in Zebra 3. Every upcoming plugin update will also include this, but it will take some time until we are able to update our whole plugin line.

I assume they can only be talking colloquially about the “resetting audio and MIDI buffers” when they detect the transport change, and the option they mention in Logic stops the flag you are referring to being set.

I have checked Zebra 3 (VST3 only) and it does indeed have an option to not reset the audio and MIDI when the transport changes state, and that works a treat. If you do not set that option, then any held notes are cut when the transport is started, but if you set the option, then the held notes are not cut when the transport is not started.

For now I will revert to the VST2 version of REPRO-1 for the specific song where I need the transport to start whilst holding a note. That’s a workable solution to me for the time being.

16

The Steinberg docs refer to calling setProcessing() with false then true as a “reset” that hosts may implement at transport start/stop. The VST2 standard does not have setProcessing(). Maybe the u-he rep is claiming that Cantabile is calling setProcessing false->true, and that’s causing a buffer flush.

17

I would not presume to say they are making particular claims. It may be a language/way you describe things.

For now I am happy enough to revert to VST2 version and wait for them to update REPRO

1 Like
18

Correction: Maybe the u-he rep is conjecturing that Cantabile is calling setProcessing() false->true, and that causes the reset.

My point is that this is perhaps what they mean by “reset”. There is indeed dispute among vst3 developers and host developers over whether hosts should call setProcessing() in this way, and whether plugins should honor it if they do, which would explain why Logic might have an option for turning it on or off. Just a possible interpretation.

19

For the record, Cantabile calls setProcessing(true) when the plugin is started, and setProcessing(false) when the plugin is stopped. Transport controls don’t result in calls to these methods.

3 Likes