Noel Borthwick

Nothing has changed of any significance in 07 that would impact this area. Though Echo made great products, you are running a discontinued 15 year old device that doesn't have officially supported Windows 10 drivers. It's not surprising that it might behave sub-optimally in Windows 10. I suspect something environmental in your system is affecting driver performance leading to the dropout rather than CbB. In ASIO mode all audio is driven by the ASIO driver's thread rather than managed by Cakewalk. If the ASIO thread is starved for some reason it will cause a dropout. Most modern ASIO drivers take extreme precautions to guarantee real time performance of the driver, setting their thread priorities to realtime and other kernel tricks. Regarding why your dropouts seem more likely to happen when idle, its hard to say since there are many variables. PCI devices especially legacy ones, are prone to interference from other devices on the system and can require tuning. Some things you can try: Do you have MMCSS enabled in preferences? If enabled Cakewalk will try and change the driver thread priority to the MMCSS pro audio priority. Check whether toggling that flag makes any difference. Try playing with the DropoutMsec variable in Aud.ini. This allows adjusting the tolerance for the drop out. Do you have share audio devices enabled? Try toggling that off to let CbB exclusively use the driver.

You are using asio or wasapi? What latency are you running at by default? If you are getting dropouts that frequently when running at moderate latency something is interrupting your audio driver. Cakewalk has a fuse to detect if audio processing was unable to complete within the allocated timeslot and pops that message. Unless you have a synth or plugin in the streaming path that is costly normally your shouldn't see dropouts esp when playback is not happening. Does this also happen when playing your project or only when idle?

The easiest way is to use Ripple Editing to accomplish this. Here is a video.

Selected but not announced publicly until they all respond via email.

Could you check what audio driver mode you were using when you had the issue, and what driver was selected?

Glad to hear that @Sidney Earl Goodroe Did this fix the VST2 versions of these plugins or VST3?

Entire Mix will sum everything coming out of ALL hardware outputs. If you have multiple outs used for headphones or are have some special routing it is probably not what you would want. Bottom line is there is no one size fits all solution. You have to pick what outputs you want to render.

As mentioned "Master" is just the name of one of the buses in the default template and has no special meaning. One thing we could consider doing is only select the DEFAULT bus.

Hi Dan, The thing is that there is internally nothing special about the bus called Master. The routing is flexible and its really up to the user which bus represents the entire mix. In fact there is no requirement for there to even be a master bus since all buses get mixed down to the target hardware outs. If you look at the signal flowchart you will see that.

Waves - lost perimeters. Now that would make a great album title ?

If you were referring to my post about program change numbers you may have misunderstood what I was saying. I was referring to the VST3's special program change PARAMETER. This has no notion of banks. Rather its a parameter who's values represent all preset's exposed by the plugin. AFIK there is no way to separate them into banks using that mechanism. Its a linear range of all presets that the plugin exposes. You will see the preset's in the preset picker in CbB's effects window toolbar, assuming the plugin exposes it. All Waves plugin's expose presets if you want to see it in action. Generally the only reason to access presets from the DAW directly would be to program a preset change somewhere during playback. So bank's don't necessarily buy you any functionality assuming that all the presets in the plugin can be set.

This thread has strayed far from the topic of plugin settings loss Losing automation envelope state is a completely different thing since it is host related rather than plugin related. Same with the program change issue which is related to the VST3 spec implementation. If you have a reproducible issue with that PM me a link to the project and we can look into it. As I mentioned earlier sending program changes will only work if the plugin exposes program's to the host. i.e. you MUST see presets listed in CbB's preset picker in the effects window. If not no dice. TH3 doesn't support VST3 presets. I don't have THU to test but I imagine its the same.

@craig The main issue with program changes is that MIDI defines a program change as a value from 0 to 127 and banks similarly. VST3 doesn't actually support MIDI as raw MIDI data but messages like CC's and Program changes internally handled as a special plugin parameter with a floating point range from 0-1. VST3 plugins can expose a count of supported "programs" and in fact if they do CbB will enumerate and show these programs in the preset picker on the toolbar at the top of the plugin window. If that is shown then by setting the flag in plugin manager to "Translate Bank/Program Changes", MIDI program changes in the project will get mapped to the appropriate value of the special program change parameter. Keep in mind that there aren't many VST3 plugin that properly expose their programs this way. Waves instruments are an exception and do support it. So you would in theory be able to send program changes to the VST3 this way. However it doesn't make too much sense since the range of 128 programs would be mapped over however many programs the plugin offers. So you would have to guess what program change number corresponded to the actual program! Not very user friendly. Alternatively a better approach would be for us to directly expose the program change parameter to the user as a plug-in automation parameter. I tested this and in theory this would allow you to dynamically assign a program change via track automation. As long as the plugin exposes the program change parameter this would show up as an assignable envelope for automation. As long as the plugin exposes the programs properly, the parameter values would show the correct program names in CbB. This is not supported yet but I can consider adding this in for a future release.

@martsave martin s can you provide some more information on the steps you you do to run into this issue?

Hi @JoseC, we looked at VCV. This is a completely different issue and its caused because the plugin is a minimal wrapper that doesn't handle chunked data saving. It also doesnt support a default vst program so our code is not saving any state for it. We'll try and handle this corner case where the plugin has no programs and no chunks. This is really an outlier case though. I haven't seen any plugs like this before

We worked closely with softube on integration and support all the necessary back end to integrate with the console one.

Did Cakewalk show the same midi device names in preferences and in one same order as the other daws when you had the problem?

We don't have those to verify. Is this something you can reproduce consistently? If so PM me and I can send you something to test. the main issue addressed had to do with vst3 but there is a secondary fix that may or may not affect it. Are you sure this isn't a problem with the plugins themselves considering they are old? Often auth issues can also lead to similar symptoms.

Over several years we have had a few sporadic reports from users regarding plug-in settings being lost when loading projects. We take any kind of data loss very seriously and many people have tried very hard to reproduce this problem over the last five years with no success. I'm happy to report that we believe this issue has finally been solved thanks to the assistance of several testers and end users. I'd like to call out @scook, @Max Arwood, Justin Mitchell, @msmcleod and the other users who contributed to this search for their invaluable assistance and troubleshooting, and for testing various iterations of the fix over the last few months. Max and Justin in particular spent many hours with me allowing me access to remote troubleshooting sessions on their DAW to try and isolate the issue. This ultimately led to isolating some of the issues with Waves and FabFilter plugins. Some background for those interested in this saga: While the actual problems appeared to be related to plugins from certain manufacturers, this is not caused by bugs in the plugins themselves. Rather, it was an unexpected interaction between specific VST3 features and the order in which plugins are loaded in the host. (This specific issue has preexisted since SONAR X3 when VST3 was introduced). The source of the issue with settings lost when loading a project, was a somewhat confusing part of the VST3 spec that allows plug-ins to send parameter changes to the host for delegation back to the plugin. The issue here was that certain VST's rely on this "parameter feedback loop" from the host to update their internal processor's when loading the project, even though the plugin state has been fully initialized by the host when loading the project. CbB/SONAR did not do this parameter reflection step when loading from projects. Without this step, occasionally a few of these plugins would reset their state to their default parameters even though they state has been fully loaded by the DAW. Whats even more confounding is that the reset behavior was not consistent - it would happen randomly, which makes it very hard to pinpoint the root cause. Why this confusing and error prone behavior was built into the VST3 spec is a subject for another debate I will be reporting this to Steinberg since the specification doesn't call out hosts to support this explicitly, and their unit tester doesn't even flag this as an error which should be an easy thing to do. The second problem had to do with loading fxchain presets and prochannel state. There was an isolated bug where Cakewalk's internal state for the plugins parameters could get out of sync with the actual loaded parameter state when copying or moving plugins around. This issue was also addressed. We have sent out test builds to several customers who reported these intermittent issues and they have all reported it as resolved in use over several weeks. The good news is that as a result of this work we've also optimized our internal parameter management for plugins which speeds up loading projects and various operations like cloning tracks and copying plugins. We're very happy to to put this one to rest finally and make CbB even more stable and failsafe! Stay tuned to see these fixes in our next public release. PS: Please note that settings being lost doesn't necessarily imply that its a problem in the DAW. This symptom can be caused by multiple reasons including authorization problems, demo mode or other plugin installation issues.

I've fixed the crash that @spiffo reported to me. Thanks for your assistance and diligence in getting me a project. There was a potential race condition that could cause a crash when a sidechain was created under certain routing conditions. This is why it was so intermittent and only affected some people. In his project he had a synth track sidechaining to a compressor in another track. It also seemed more likely to happen if there were multiple synth tracks sourced by the same synth output. The take away from this is for problems like this its very important to try and get a repro and send us a dump/project. Its only because of spiffo's project that I was able to fix this issue. There are so many environmental permutations that it can be very hard for us to replicate or notice some of these problems.

Ah I see - I missspoke. What its doing is when lanes are open it treats a browser double click the same as a drag and drop to the master track for the lane. This results in the drop occuring to the FIRST lane not the current lane. I suppose we can consider trying to special case the browser and make it always append lanes if you double click.

I wouldnt worry too much about that toast. All it means is that the system was busy enough that the time to process a single audio buffer exceeded the threshold and caused the engine to stop. The reason it drops out even when not playing is likely because you have synths in your projects or you have "always stream audio through FX" enabled. So its telling you that realtime playback has been stopped. I'm sure there is room for improvement, but it can happen with some more intensive edit operations.

@winkpainThe file menu issue will be fixed. The other behavior of double clicking files in browser when lanes are open is that it will insert to the active lane. I think that is expected today. Its also how it works with tracks - it will insert into the current track. When lanes are closed there is no active lane so it appends...

I can decipher it if you send me the dump file.

Haha no that's fine I just don't receive those directly so asked you to PM me to expedite it. Thanks to the help of @spiffo and @M.O.S.T. Music I got dump files and finally now have a project file that can reproduce a crash with sidechaining. We should be able to address this once I figure out whats going on.