Jump to content

foldaway

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

6 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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.
  4. 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?
  5. 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
  6. 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. 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
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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!
×
×
  • Create New...