foldaway

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

A small request for the hot fix. Could the 'Silent bus detected' & Missing VST dialogs (that pause project loading) be turned into a toast notifications? Thanks

Using Ctrl + Left Mouse Click to open multiple VST GUI's at the same time does not work in 2020.07 EA. nb. reposting as think it may have been missed before & this is quite a workflow killer for those who use a lot of plugins. Thanks.

After installing 2020.07 EA, I can no longer open multiple VST UI's at the same time using Ctrl + Click in the track FX window. & thanks for the update ps. any chance of parallelizing the VST loading to use all available cores?

These are existing (pre-EA) issues that I've rediscovered while trying to load up some projects. MIDI MIDI input assignments for channels are not recalled when a project is loaded. VST/MIDI plugins I've recorded multiple crashes with "The thread tried to read from or write to a virtual address for which it does not have the appropriate access." visible in the minidump summary, in the Cakewalk EchoDelay.dll MIDI plugin & all of Kazrogs Thermionik range of plugins, while trying to load projects. I've attached minidumps for an example of the EchoDelay crash & a selection of Kazrog Thermionik plugin crashes. Possibly worth noting that the project that had the EchoDelay crash also had Kazrog thermionik plugins in it. I recall reporting these crashes before pre-bandlab era, so there may be more information available in your bug reporting system. My main observations from the time were; I noticed that all the exception addresses ended in 8, so I was wondering if Sonar was sending audio buffers that were'nt necesserily 16 byte aligned which could cause access violations if used directly with SSE operations. A workaround that works for some of the projects is to globally disable FX, start playing the project & then while playing re-enable FX. Thanks Kazrog Thermionik Minidumps.7z EchoDelay.dll Midi Plugin Minidump.7z

Thanks for testing. I'm not sure what happened but I can't recreate it now. I've responded to Noel with some further details. Cheers.

Unforunately I'm unable to recreate this scenario now. However, I've been successfully able to recreate an issue that I think could be in some way related. Steps to orhpan VST FX parameter automation data: - insert VST plugin on a channel - record paramter automation for the inserted VST plugin - drag move the VST plugin to a different channel - delete the VST plugin One issue I've had on a larger project was that I couldn't automate a plugin instances parameters that had already been automated & orphaned. I'm not sure though if this (above) method is the same that led to the orphaning, in this project. a few additional notes: - when a VST plugin is moved to a different channel, its automation data remains in place. This is reconnected if the plugin is moved back to the original channel. - if the VST plugin is deleted after being moved to a different channel the associated automation envelopes are not deleted & cannot be accessed or reassigned to a new instance of the plugin. Whearas, if the VST plugin is not moved & deleted its automation envelopes are deleted. Hope the above is clear & helps. Cheers

There appear to be some serious issues with VST plugin parameter automation when the VST plugins are on a bus channel. These are: - VST plugin automation recorded or entered manually is not played back (/sent) to the plugin, when the project is played. - VST plugin Automation recorded via 'Automation Write = enabled' & tweaking in the VST plugin UI, cannot be viewed in individual lanes by pressing the 'Automation Lanes = On' button, as is possible on non-bus channels. I originally bought this up in the EA 1 thread but I think it may have been missed, so I am posting it again here. Cheers

I've been experimenting & there appear to be some serious issues with VST plugin parameter automation when the VST plugins are on a bus channel. - Automation recorded via 'Automation Write = enabled' & tweaking in the VST plugin UI, cannot be viewed in individual lanes by pressing the 'Automation Lanes = On' button. - Automation recorded or entered manually is not played back (/sent) to the plugin, when the project is played.

Hi Lars, I'm talking about loading a project & the possibility of using all available CPU cores to create whatever plugins are used in the project. So that the project will load faster.

Thanks, that would be great

Hi Noel, Sure, not for a single plugin but I'm talking about loading multiple plugins in parallel which would indeed speed up loading operation considerably. In my case 16x faster! When using a project with 100's of plugin instances this would make a huge difference.

I've noticed that when loading a complex project only 2 cores are used for initialising VST plugins. This can cause projects to take a very long time to load. For this upcoming release would it be possible to increase the number of threads used to initialise the VST plugins? If possible upto the number of cores available? I ask as I'm now running a high core count CPU, which is feeling a little under used!