foldaway

Hi to all who might have an interest in this thread.  Just wanted to provide a quick update.

The fundamental issue was specifically related to Plugin Load Balancing being enabled & I'm happy to share that Noel has found & resolved the issue & the fix will be in the next Sonar release!

Cheers.

Hi Noel,

Thank you for taking the time to respond. 

I've been testing in Cbb & Sonar.

I've just seen your PM & I'll respond further there shortly.

Thanks.

I've raised this issue in part in the feedback loop but no devs chimed in, so I'm hoping given the new forum that it might be more visible here!

I've created the following support requests;

Request #1738158 : Timing of MIDI events sent to plugins on busses is not correctly latency compensated
Request #1734819 : Time sync info provided to plugins on busses is not latency compensated
Request #1749864 : Timing of plugin automation events on busses is not correctly latency compensated

These are very concise & include simple example projects that clearly demonstrate the problem.
These bugs (present in latest Sonar & Cbb) cause large timing errors when using MIDI/song position sync/automation on busses.
These all appear to be closely related so hopefully the required fix will be common to all too.

As bugs go, to me this kind of bug is 2nd only to a bug causing the wrong notes to be played!

Hope one of the dev team sees this and comments!

Cheers

On 6/28/2024 at 7:32 PM, David Baay said:

That's not likely an inherent issue with Instrument tracks but some error in the conversion process causing the track to be associated with the wrong synth in the first place. Because inserting synths in FX bins is such an old implementation, I wouldn't be too surprised if there are issues with audio/MIDI port enumeration changes when deleting the ones in the FX bins. The right sequence of conversion steps should avoid that.

I would recomment the following approach to avoid having ports crossed up or having to recreate the MIDI and synth audio tracks, preserving the existing FX and track settings:

- Save a copy of the project, save presets for any synths that aren't using a default, and then delete all the synths from FX bins and re-save it.

- Using the original project as a reference, insert the first missing synth by Insert > Soft Synth, and don't have Sonar create any tracks for it.

- Assign the input of the audio track to that previously hosted the synth in its FX bin to the newly inserted instance, click the icon to open the synth UI and assign the relevant preset.

- Assign the ouput of the relevant MIDI track to the synth in the rack.

- Select the MIDI and Audio tracks, right-click and choose Make Instrument.

- Test playback.

- Repeat the insert, I/O assignment, Make Instrument and test playback for each synth.

I tried using Make Instrument to convert fx+midi tracks, in a copy of the project.  While this worked in creating Instrument tracks, the song position latency error remained.

I also tried saving the synth presets, creating the Instrument tracks fresh (alongside the existing) & loading the synth preset, then moving the midi & fx (following the original synth across).  This lead to the strange issues I mentioned in my last post.

I thought I'd mention the failure cases, just so people can avoid them!  but I've yet to try your more complete approach so maybe that'll work!

Thanks

Sadly I have to take back my praises for Instrument tracks!

I've just tried converting a slightly larger project (only 23 audio/midi tracks) by adding fresh instrument tracks & moving the midi & fx over.

After converting just 7 instruments, everything went very wrong!  My favorite example being that clicking an intrument track icon to open the vst plugin instrument, starting opening the wrong instruments! ?

So I guess I'm back to hoping the original bug/issue can be fixed in a future release!

11 minutes ago, David Baay said:

There are still situations where MIDI timing can drift progressively out of sync by a few samples per iteration when looping at random points at certain tempos but it's usually avoided by looping exactly on bars/beats. I believe Jamstix uses song position so I might try experimenting with that later.

 

I tested with loop start/end exactly on bars & the drift was much larger than a few samples.  So I'd be interested to see how Jamstix does!

Alas, not quite out of the woods yet!

Some interesting additional notes;

Converting an audio + midi track into an instrument track, does not solve the problem...  Unless, I create a new instrument track routed to the same bus!  Definitely something strange going on here!

Creating a new instrument track via D&D from the plugin (/instrument) browser works as expected.

Even when song position sync is working correctly.  Playing a loop causes de-sync, which appears to be variable in nature!  nb. this happens even when Latency delay isn't enabled.

6 minutes ago, David Baay said:

Glad to help. Separate Synth  Audio and MIDI tracks should be okay as well, you just need to get the audio into synth track via the Input from the Synth Rack rather than the FX bin.

Yep, just tested and all good! ?

Haven't touched Instrument tracks or the Synth Rack for a long time, as previously had a lot of problems but looks like they're great now.  Much relief ?

Thanks again.

I have just tested the same situation with "Simple instrument" & "Instrument " tracks instead of the original seperate fx+midi tracks & the song position sync problem is avoided! ?

Thanks David for highlighting this as a possible cause.

7 minutes ago, David Baay said:

I created a comparable project with Sonitus Delay delaying a track by one beat and nulling against the same audio manually offset by 1 beat. I then added CW's TS-64 Transient Shaper which adds a significant amount of plugin delay to the Sonitus-delayed track and confirmed the two tracks continued to null. I then moved Sonitus to the bus through which that track was outputting, and the project continued to null both before and after restarting playback. For good measure, I tried moving Transient shaper to the same bus and other buses and tracks, and the project continued to null as expected.

So I think this issue is either specific to ShaperBox or possibly involving the live synth which I'll test next.

Thanks but I'm pretty sure you're just testing the PDC in your project, as none of these plugins has a sync based on the song position, which ShaperBox does.

It is specifically the song position information being relayed to the plugin that doesnt appear latency corrected on the bus.

Also note, that when Latency Delay is set to 0, the issue still exists.  (...should have set it 0 in the demo project!)

Here's what the ShaperBox oscilliscope looks like with & without the error.

1 hour ago, Glenn Stanton said:

might be time for the doctor. the plugin doctor... https://ddmf.eu/plugindoctor/

Thanks for the recommendation.  I had a quick read of the manual & while it looks really good for analysing audio performance, I can't see that it provides any view of time sync information from the host.  Which appears to be the source of the problem.

1 hour ago, David Baay said:

I installed the plugins, but the demo of ShaperBox isn't doing anything - possibly because I didn't want to install the 300MB of presets and other content. I can see that Voxengo is set to add 1000 samples of delay to the synth audio track, and I can hear that delay vs. the metronome when engaged, but with ShaperBox not doing anything, there's really nothing to hear.

EDIT: As I re-read the OP, it seems I may have misunderstood and this isn't even about PDC but more about tempo-syncing. Is that right? Also, as I read that Voxengo "Latency Delay introduces 10000 samples latency itself and delays the audio signal by 10000 minus the specified amount of samples or milliseconds, thus eliminating the unreported latency", the expected behavior of the test project becomes even harder to predict. I'll have to experiment with some other tempo synced plugin.

Hi David,

Thanks for your feedback.

Yes, it is about time syncing (/tempo syncing).

I included Voxengo Latency Delay as it was the simplest way I could think of simulating the latency of a large number of plugins.  Sorry, I should have mentioned this in my post!  The fact that the latency is adjustable also means its easy to see the effect in ShaperBoxs background oscilliscope.

I've attached a preset file for ShaperBox in case you want to use it in the demo project.  It should be included in the project as it was a custom preset but I'm guessing it wont load it in the demo.

1 hour ago, pwal³ said:

i notice that shaper is the vst3 version, the others are vst2

I've tested both VST 2 & VST 3 versions of ShaperBox 3 & they both have the same issue.

Thanks for the tip...   & Done

Just in case a dev does see this thread, the linked Support ID Request = #1734819

Forgot to mention.  This occurs in both Cbb & the new Sonar.

The project notes includes intructions to demonstrate the problem

shaper3 preset.vstpreset

As the title suggests it looks like the time sync information provided to VST plugins on busses might not be latency compensated.

First noticed when using Cable guys - Shaper 3 plugin.  When this plugin is in a tracks fx chain, it is synced perfectly with the song time.  However when it's placed on a bus the track is routed to, it is no longer in sync.  The offset appears to be directly linked to the latency introduced through the tracks plugin chain.

To me this suggests that the results generated for VST2 GetTimeInfo calls from plugin (& the VST 3 equivalent) are not taking into account the plugin chain latency.

Also, seems unlikely to be plugin specific as the plugin doesn't know if it's on a bus or not!

I've attached as example project which demonstrates the problem, using SI-Drum Kit (VST2), Voxengo Latency Delay (VST2) & Cableguys Shaper 3 (VST3)

Look foward to hearing from one of the bakers.

Thanks

bus time sync latency compensation bug.zip

Here's my quick guess.

I think BandLab are running the new Sonar as subscription (& somewhat low-key) only for the time being while they squash as many bugs as possible & get the new UI working nicely.
After that they'll have an up to date & very solid product that they can do a big announcement for. Including I'd imagine a one time purchase option for us non-subscription folks.
Imagine how powerful it'd be from a marketing perspective if all the media got to review a thoroughly solid & modern feeling Sonar after the big announcement, I think it'd do really well!
If I wanted to retake some market share, that's what I would do it anyway.

Could a small fee be charged to allow offline use?

This way you could keep track of the active users & not disrupt users that might not have internet access when re-activationon is due.

3 hours ago, azslow3 said:

@foldaway from my experience,  feeding plug-ins with incompatible data can produce way more strange effects then just a crash... VST2 is identified by ID, not by file name. This ID supposed to be unique, registered by Steinberg. But who follow all rules... Unlike UUID, VST2 ID is short (4 characters) and so clashes are likely, forcing DAWs to use some (unspecified) method to distinguish physically different plug-ins with the same IDs.

As I have mentioned, it seems like Cakewalk in general match plug-in in the project with currently installed one. I mean it seems like 8.3 name issue is more glitch/bug then regular (also from OP and discussion, it happens for automations matching, not for plug-in matching). In case Cakewalk is unable to match some plug-in at all, most probably plug-in developer has done that on purpose and attempts to find a "back door" is not a good idea...  

I was mainly thinking of the issue where the plugin .dll is identical across machines but not recognised as idenitcal, meaning a project using the plugin wont  load correctly on one of the machines.  In this situation a replace dialog would be ideal.
From an implementation perspective, while certain safeguards could be put in place such as checking the VST ID, parameter list etc. I'm not sure it would be worth the time.  So I'd be happy with a 'this might go badly wrong, are you sure you want to try?' checkbox.
I wrote a VST plugin wrapper back in the Vista days, so I know what you mean about strange effects.  I had a lot of BSODs during development! but Windows is a lot more robust than it used to be.  Yeah, also familiar with the 4 chr id's that no-one bothered with!
As a side note, I seem to recall having similar issues with DX plugins.  ie. same plugin install on 2 machines but not recognised as being the same.

10 hours ago, Noel Borthwick said:

Yes this is the unfortunate effect of 8.3 names with VST2. We have code to handle loading plugins irrespective of mismatches and we synthesize a better UUID that doesnt rely on short names for that. However for automation it still uses the old format for compatibility reasons. 
I'll think about it some more and see if there is a way to auto detect this and prevent envelopes getting orphaned in such scenarios but its not going to be easy.

Hi Noel,

Would it be possible to implement a 'replace plugin' dialog for missing plugin IDs?  So that in the event that automatic fixup fails there is a mechanism by which
the user can select a replacement plugin to load in place of the missing plugin. I'm thinking specifically for VST2 plugins.

I've had situations where the same plugin .dll leads to a different UUID on another machine, meaning it cannot be loaded. I'm assuming this is related to the discussion above.
I've also had the situation where I've been unable to find the exact same version of a plugin used in an old project where but a later version (with bug fixes only) was available & these also have different UUIDs.  Not sure if the UUIDs include a hash of the file or if this is still related to the 8.3 name issue.

My thinking is that if a plugin has the same parameter layout & binary blob format then is should be able to load the project using that plugin & if it works, then this version of the project can be saved using the new UUID format avoiding the problem in the future.   In fact even if the replacement failed & led to a crash, I'd still be happy that I could at least try, rather than having to redo all the work from scratch.