foldaway

Thanks. I just sent it before I saw your message 🙂 I gave it quite a few goes opening in safe mode with my best guesses but there's a ~200 plugin instances & I just haven't got the time at the moment! Which leads me to a small feature request! It'd be really nice to have a check list of used plugins when starting opening in safe mode, such that the plugins can be ticked/unticked to determine if they are loaded or not. nb. not individual plugin instances but by the plugin itself. This would massively speed up locating issues!

I'm unable to successfully open a project that loads correctly in Cbb. On trying to open the project, the last toast notification says "Project successfully opened" but the UI then freezes for a few minutes. It then detects the crash (with crash code 'Application Hang') & saves a crash dump file, so that's something. Noel can I send you the crash dump?

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

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!

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.

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.

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.

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.

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.

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.

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.

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.

I have noticed that when I use Shattered Glass Audio - Pheonix VST effect in a project, CBB becomes very unstable & will crash quite quickly. Sometimes straight to the desktop, sometimes with a unhandled exception dialog box. I've not yet been able to pin down an exact mechanism for creating a crash but here's a few ways that work sometimes while playing; - disable / enable the plugin - remove a neighboring plugin - disable / enable a neighboring plugin