Colin Nicholls

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.

...and I use Ctrl-Z!

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.

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

@Canopus, yup I think you're right. This is the first time I've seen such an artifact. I'll be sure to thoroughly test a theme switch before claiming such a defect again. Lesson learned!

[2019.07] The latest update(*) appears to ignore any theme override of the Control Bar Performance Modules "Meter color": (image removed) [UPDATED] It's more complicated than that. I switched between several themes and ended up back with the Performance Module respecting the color override. So this must have been some kind of theme-loading glitch. I withdraw my bug report. Sorry about that. (*) Note that I have not applied the 2019.07 hotfix at this time

Yeah, I replaced the image with the one that you supplied. So you should probably update your theme and ensure that the correct image is included with it. Glad to help...

Here you go:

They are pink in both locations. I think they are shared FX Bin attributes so I don't know why they would be different from each other.

This discussion (which includes a tip from Craig Anderton re: disabling HD Audio drivers) might help you. Also this would be the definitive Cakewalk Win 10 optimization reference...

Resolution: I think this is more a case of the color attribute being mis-named. (The color I wanted to change is located elsewhere in three or four separate attributes for MIDI, Synth, Audio, Bus, Folder tracks). Rather than "Unfocused Track Text", this attribute should be named differently - and perhaps "Global Color #10" is appropriate ? Original Post: [2019.07] The "Unfocused Track Text" color (IDR_CLR_GLOBAL_10) does not change the actual unfocused track text. Instead, it changes the Help Module Text, Track View Time display, and others: I've reported this as a bug.

Yup, definitely pink:

I would love to be able to bind "Rename Clip..." from the right-click clip context menu to, say, the F2 key. But it does not appear to be available in the list (or I can not recognize it). I suspect that there are a number of recently-added commands that have not been made available for Key Binding or Custom Module assignation. And while we are at it - the scrolling menu list of available commands under the Custom Module context "Commands >" option is almost un-managable given the size of the list and the sometimes cryptic naming of them. I hesitate to say "add new commands to this list" which will just add to the problem. But I'd rather have the new commands available than not at all.

So you're asking for dialog windows that are currently so small that their contents (i.e. lists) are constrained and therefore hard to use because of the scroll bars that that list has to show in order to navigate the contents? And you'd like either the dialogs to be larger by default or at least re-sizeable? I can get behind that request.

I just updated to 1903 this morning. Cakewalk seems to be running fine. LatencyMon doesn't report any worse figures than before (and they were quite acceptable). So far, the only thing I've needed to do is re-register XLN Addictive Drums due to the computer ID change. *sigh*.

Totally agree with everything @Craig Anderton said, but ironically the August 2019 issue just arrived here and doesn't appear to include his regular Cakewalk column. This is not unusual; I think each of the seven (7!) major DAWs take turns missing a "workshop" column each month.

Is the yellow FX enabled or disabled?

At least, my installation just told me an update was available. Early days, but up and running on 2019.07 here. Thanks, Bakers!