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.

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.

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

7 hours ago, msmcleod said:

@foldaway - I think this must be a project and/or plugin specific issue. 

It's working fine for me:

 

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.

7 hours ago, Noel Borthwick said:

@foldawayCan you post a detailed recipe for this and also include a link to a project with the problem?
Is this something new you have observed and is it project specific - can you reproduce it in a new project? 

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.

6 hours ago, LarsF said:

If I follow - 16 instances of the same plugin on different tracks?

I'm thinking the quick grouping the tracks, and hold control when you do anything like that - and it duplicates to all selected.

But the same thing with multiple chains, have not tried that.

Or you talk about something all different....

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.

7 hours ago, Noel Borthwick said:

@foldawayAh I see what you are saying. I'll look into the feasibility of this.

Thanks, that would be great

11 hours ago, Noel Borthwick said:

There is no way to speed up the load of a plugin from the host side. Its up to the plugin to get more efficient. Talk to the plugin vendor who are the ones who have the power to do that 

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!