Colin Nicholls

I'm with you, @Tez, we can be crazy together.

For what it's worth, I temporarily switched back to 2019.01 and the frequency of audio dropout toast was much less. Then I re-installed 2019.07 and I'm back to seeing it every few minutes. 

It doesn't really impact my work (yet). 

I do wish I could download the installer for 2019.05 and others, just to compare behavior.

Ah... thank you scook. Clearly I paid no attention to that at the time 🙂

As you were, everyone...

Um... I just rolled back to 2019.01 to perform some tests, and my control bar modules are justified. Also, the right-click menu gives me the option of justifying them. This feature was added in 2019.07, right?

So, why is it still available when I roll back to 2019.01? Are some components not replaced /reverted by the full installer?

(Note: I would have gone back to 2019.05 if I could, but the most recent older full installer I have is for 2019.01.)

I'm concerned because obviously now I am unsure if my tests really indicate 2019.01 behavior....

Some more information based on recent experiences.

Following the advice in this thread, several days ago I turned off [  ] Always stream audio through FX and it has made no difference.

It's not tied to specific actions in the UI as far as I can tell. I don't even have to be doing anything in the UI, just sitting pondering my next move, and POP I'll get the toast. I haven't been timing it so I can't say that it happens every 4 min 17 sec intervals (😀) but to be honest it does kind of feel like that. Perhaps I'll start a stopwatch next time.

It's not crippling because I've even had it happen right before my mouse clicks the PLAY button and of course Cakewalk just starts the audio engine immediately.

But I have to think there is something abnormal going on.

My evaluation is that this is definitely a change in behavior, at least in my experience. It started happening since I updated 2019.07 and/or updating to Windows 10 1903. I can't exactly say which of these two events was the trigger.

I went through the usual post-update optimizations (disabling on-board audio, other unimportant services, etc).

UPDATE:

Launched Cakewalk. Opened project. Started stopwatch. Continued working in Cakewalk.

First audio dropout: 1 min 39 sec

Restarted engine by clicking on icon in Control Module; restarted stopwatch, continued working in Cakewalk.

Second audio dropout: 4 min 17 sec

...I kid not. I'm not saying this is anything other than a coincidence, but a pretty freaky one. I'll collect more data.

Third audio dropout: 9:23

Fourth audio dropout: Just after I closed the project, I wasn't timing specifically at that point.

Thanks for chiming in, Noel. I'm now content with my current level of understanding of the behavior I'm observing. Go back to working on the next version!

39 minutes ago, David Baay said:

Just to be clear, LatencyMon numbers will be microseconds (us), not milliseconds. In any case, 255 peak is not great, but shouldn't be a problem except, possibly, if your  ASIO buffer is extremely low, like 16-32 samples (333-667 microseconds at 48kHz).

I have very occasionally seen a dropout occur with the transport not running. It may be related to having Always Stream Audio Through FX enabled in  preferences.

One thing you can do is keybind the audio engine on/off, and toggle it off when doing big edits (or a bunch of small ones) that don't involve a lot of listening . I sometimes do it when dragging a big pile of MIDI notes to avoid graphical response delays because Cakewalk is prioritizing audio streaming. I also toggle it off when walking away from the DAW for an extended period just so it won't be wasting CPU cycles with a project idling since I have all the usual power-saving features turned off.

David,

You're right of course. μSec not mSec.

[x] Always stream audio is enabled. Good point, I haven't really paid much attention to that option.

I run ASIO buffer at 256 samples typically.

I wish there was more information available about the reasons behind the "Audio Dropout: The audio engine has been stopped unexpectedly".

This is happening to me when I am working with clips in expanded take lanes - just moving them around. Playback is NOT active at this time - there is actually no reason for the audio engine to be running at all, but by default, it is. I grab some clips and move them, holding down SHIFT to ensure they don't change their timing, release the mouse, and BAM, dropout toast.

It doesn't happen every time - and I have seen it happen when zooming in on the time line, also.

Additional Info: It often happens when I'm not making any actions in Cakewalk at all. It doesn't seem to be tied to actual activity in the UI.

LatencyMon isn't reporting any issues; typically 140 ms, peaked at 255 ms. All green.

7 minutes ago, Craig Anderton said:

However, it hasn't been updated to VST3, so it can't take advantage of the features that spec offers (e.g., shutting off when not passing audio). So in that respect, it's dated.

Hm... ok, I'll allow it 🙂

I think the word you're looking for is "timeless". They work great; they sound great; they look great; stable coding, not frequently updated with buggy fixes.
To me, that's the opposite of "dated". But each to his own.

I don't understand why they are considered "dated"

Thanks for the additional information, guys.

I've never used FX chain presets; just haven't had the need before. I will research further as my curiosity leads me.

Is this a known issue? I was opening an older project and saving my Sonitus FX settings into new presets, in new banks.

When I opened a new project and inserted the FX to select the new presets, they weren't there!

Workaround:
In order to truly create a persistent new preset, I had to run Cakewalk "as administrator".

After creating the presets (again) following the same process, I then exited Cakewalk and then re-ran it, normally. This time, I could see the new presets in the Sonitus Preset manager

This is probably due to Sonitus storing the presets in an INI file somewhere where a normal user doesn't have permission? Maybe? But then, I'd expect an error when I tried to save the preset in the first place, I think.

Anyone have any insight to share on this?

Update:
I have confirmed that the new preset data was written to:

      C:\Program Files\Cakewalk\Shared Plugins\FxEqualizerDX.ini
      C:\Program Files\Cakewalk\Shared Plugins\FxDelayDX.ini

So, yeah, I guess it makes sense this would require elevated Admin privileges.

@mfanning , you might find this relevant:

Last year i upgraded my DAW and compared performance of both a PCI and USB interface (Echo Layla 3G and Scarlett 6i6 USB) on both computers. My findings are described here:

VIVALDI is the new ROSSINI, part 1

VIVALDI is the new ROSSINI, part 2

Buried amongst the rambling on computer specs, you will find some comparable Audio IO performance values.

I figured it out. It's not a "border".  The icon is sitting on top of a button.

If you hover the mouse over the icon, it lights up, indicating that you can click it in order to display the UI for the VSTi. This works for MIDI tracks that are driving the VSTi, so the button is available under the MIDI track header icon as well.

This behavior is described - with an accurate screen shot of the header icons - on page 754 of the documentation. The fact that the icon is rendered as a BUTTON and not as a simple ICON is not highlighted in the text, but is consistent. And of course, I'd rather that clickable items are obviously clickable (i.e. they look like buttons and hover-highlight) than be un-discoverable, plain vanilla flat graphic.

Of course I knew that you can click on the header icon to bring up the UI, but I had partitioned this knowledge away from considering the visual appearance of the icon, in "theme design mode".  Duh!

Bakers: 1, Colin: 0

1 hour ago, msmcleod said:

So in summary, if the output is going to something "internal" then it's got a border around it, otherwise it's not.  

That's what I'm seeing too. Could be useful. Thanks for testing.

At the risk of getting tedious, OK, so I don't usually have "Show Icons" ticked for Track Strips but I can see that when I do enable them, I don't see the border effect on the icons themselves, just the header icons.

However, as shown in the screenshot from page 751 in the PDF documentation (see below), the header icons don't appear to have the border in the version that the doc screenshot was taken from:

This has always bothered me somewhat, but I've been tweaking my theme and I finally decided to ask this question here:

Why do some track types overlay (underlay?) a grey box on the track header icon? It seems that "Instrument", "Synth" , and "MIDI" tracks that are directed to a VSTi  are affected:

It seems sad that the beautiful, clean "Instrument" and "Synth" track icons will never be displayed in the Track View as cleanly as the "Audio" and un-bound "MIDI" track icons.

Just for kicks I changed the instrument header icon to a blue rectangle with a completely transparent background, and re-loaded:

What is the benefit of having this extra grey border or background?

Concerning MIDI tracks:

Interestingly, if I switch the output on Track 5 to direct to a hardware MIDI output, the border vanishes, looking just like the icon on Track 2:

So, there is clearly some logic controlling the border display, to do with output destination. Is there anywhere that this is documented?

Personally, I'm not a fan of the border, and especially when tweaking the icons to look their best in a custom theme.

Perfect for that Prince remix! Kudos for all the work that goes into this.

4 hours ago, David Baay said:

D'oh!  ln all my decades of computer use, I never realized this was possible. I have always 'escaped' by finding a place in the UI where it's disallowed to drop the object. 

Thanks for the 'pro tip'.  😎

...and I use Ctrl-Z!

1 hour ago, Starship Krupa said:

What color is [take lane note text]  on everyone else's systems? I swear I thought that it was white or at least grey at one point on my system but I haven't tried using that area in such a long time. 

It's white (on charcoal) on mine, when using my current version of Polar Blue 2019. I then switched between Blue Aston, Mercury, and Tungsten and the text color was unchanged.

For what it's worth, I'm using the Pref>Color>Preset of "Normal" but as soon as I save and close the Pref dialog, and then go back in, the preset name is "Normal*" (note the addition of the asterisk) so I suspect that there is an attempt to show that some colors are overridden by the theme? The priority of colors between a "theme" and a "color pref preset" is murky...

Martins, are you creating a theme with no way to test it out? You can't load it in Cakewalk yourself and play back and observe?

Perhaps you'd like to answer Noel's questions on the other thread you posted first.

15 minutes ago, SteveC said:

They seem to be OK here using both the original and your updated 2019 version.   Any chance they're being overidden at the Colors level?   Selecting anything other than the Normal preset can darken those, even using Bright...  as counter-intuitive as that seems.

 

Oh for goodness' sake. I seem to be striking 0/2 recently. This is going to seriously damage my reputation.

You are correct, Steve, it seems that somehow my environment changed such that, when I explicitly reselect the "Normal" preset under the Colors preference, the problem goes away. Arghh. I'll update my post above to reflect this.

SOLUTION:

Re-selecting the present under to Preferences -> Colors page to "Normal" resolved this issue. Cakewalk is now respecting the Clip Background colors of the selected theme.

Leaving this here in case it helps others in the future. Sorry for the confusion.

ORIGINAL POST:

Theme Polar Blue (SteveC) in SONAR Platinum:

Theme Polar Blue (SteveC) in Cakewalk 2019.07:

In case it is not obvious, in 2019.07 the clip background color is not being respected from the theme, but is retaining the default dark colors from the underlying Mercury/Tungsten themes.

I think this reverted with 2019.07. I am going to try and revert to an earlier release of Cakewalk to see if I can  isolate this change.

Themers, please let me know if I am being crazy here...

Additional Info:

I do believe that the base themes Mercury and Tungsten are also not respecting their previous colors. If you switch between Mercury and Tungsten in SONAR Platinum, you can see the Clip Background colors do change slightly. In 2019.07, however, this is not happening - the colors are the same in both themes.

UPDATE:

I reverted to 2019.01, then 2018.08,  and they are behaving the same way. I could swear this is a relatively recent change but perhaps I'm crazy. Or, perhaps during the re-install, a later component (with the bug) is not changed but stays at the 2019.07 version?

Here's a tutorial/walkthrough on controlling a VST parameter using external MIDI controller:

http://www.prodigalsounds.com/blog/post/2019/08/05/Using-a-MIDI-controller-with-Guitar-Rig-VST-in-Cakewalk