David Baay

I just selected in your quote of the OP, and clicked the quote button. For some stupid and unknown reason, the forum software did not understand I meant to quote the OP. I'll fix it. Tell me with a straight face you weren't referring to that thread when you said: 🙄

Whether plugin-related or something else, I think it's highly probable this is project- or system-specific. One of my machines is a laptop running a lowly i5-7300U CPU @ 2.60GHz with only 8GB of RAM and I don't see slow UI reponse to basic commands like you mentioned just due to high track counts. The only consistently slow operations I know of offhand are changing Screensets and opening the Keyboard Shortcuts view in Preferences. A few things I have seen cause a laggy UI in the past: - Audio driver interoperability, sometimes related to having 'Always Open All Devices' or 'Allow Arm Changes During Playback/Record' enabled. - Splitting Audiosnap-enabled clips at transients and leaving the hundreds/thousand of resulting slip-edited clips Audiosnap-enabled. - Real-time anti-virus scanning of Cakewalk-related resources.

Sorry, but I have to ask: How can a reason be both unkown and known to be stupid? 😜 I believe the issues have been addressed. I will only add that there was coincidentally a recent discussion about the fact that the documentaiotn still says the Quick Grouping affects all like-controls when no tracks are selected though that is actually no longer the case. Given it was documented, this behavior was clearly not a bug, but it seems the Bakers thought better of it when a number of users were caught out by it, inadvertently making undesired changes to all tracks. Absolute power corrupts absolutely. Often the Bakers will make such behaviors optional, but this is one case where they apparently decided it was not necessary and would just clutter up preferences with options that most users would never know or care about. If you want quick grouping to affect everything, you can just hit Ctrl+A which is more intuitive than selecting nothing. And finally, I'll take advantage of this particularly timely opportunity to point out that this is a perfect example of why it can be problematic to make even minor changes to longstanding behavior/appearance of the UI. There are always users who depend on the exisitng implementation and will be aggravated by the change.

Exactly, the button lit shows that FX is engaged, the button lit with strike through shows bypass is engaged... Thanks for making this point😁 No you're misunderstanding me and (inadvertently?) misrepresenting what I said by taking it out of context. 'Engaged' is referring to the way a physical, latching button would work. It's engaged when depressed and latched, and only lit in that state. Physical engagement is independent of whether the effect is to enable or disable some function. Following your Tesla analogy, there are many examples of this in the automobile world. Many of my cars have had switches to disable ABS, traction control, passenger airbags, passenger-control of power windows, etc.. I don't recall if they all consistently used iconogrpahy indicating they were defeat switches, but they all only lit up (or lit an indicator on the dash) when engaged/latched. Why would you not support efforts to improve a standard layout so new users can immediately understand what they are doing? Because I'd rather the precious development time be spent adding a missing feature or improving one that has significant shortcomings or does not work at all. And there will always be users who do not "immediately understand" something no matter how it's presented. Sometime you jreally just have to RTFM... or ask the forum. ;^) If Tesla had followed this same logic we would still be stuck with a future of gas-guzzling polluting cars🥴. In the universe of inane analogies this one takes the cake 🥴.

That discussion was about the PDC button, and the laughing-so-hard-I'm-crying emoji he included says a lot about whether he seriously thought it needed to be changed. FWIW, I have never found it confusing in the least. But then I've been around since before the feature existed so did not come in with pre-existing assumptions about what a PDC button should do or how it should look.

Probably an unavoidable nature of the beast. Sounds like it's using a single 'voice' to play the new note, and cutting of the release of the previous one in a way that's creating a discontinuity in the signal. Zooming in on the bounced/frozen waveform should show that. I'm not sure offhand how much the SI Bass attack and timbre changes with velocity, but you might mitigate it by using lower event velocities and raising the gain/volume to get the desired loudness.

Not in the case that you just want render clip edits to file within the existing track. Bounce to Clip(s) is the correct approach in this case.

Yes, but in the absence of a clear consensus, the answer has to be "leave it as-is " given how long the current convention has been in place and that the majority of users appear to be okay with it based on the dearth of previous discussions about it.

Write is a special case. It's not an enable/disable toggle; it's just a momentary switch (and indicator) to clear (and notify) of any existing Write enables. As noted previously, I agree R! is not following the convention of other Bypass/Override/Defeat functions, but I'm okay with that. Since it's all easily addressed with the Theme editor, and there's obviously no universal consensus to be reached, I propose everyone who cares sets it up as he/she/they prefer and leave the rest of us to our own devices. ;^)

If nothing is connected to the Lexicon's MIDI OUT, there is no need to enable it in CW. Two things to check for MIDI IN functionality: - Does the left-side indicator in the MIDI Monitor that CW places in the system tray show activity when you play the keyboard? If not, doublecheck that MIDI OUT from the keyboard is connected to MIDI IN on the Lexicon. If you don't have a 5-pin MIDI DIN cable connecting the Keystation to the Lexicon, you will need to connect the Keystation's USB MIDI port to the computer and enable that in CW. - If the above checks out, are you able to record MIDI to a new MIDI Track with Input set to Omni and the track armed to record? If both of the above check out but you're not hearing anything, you just need to have a soft synth properly inserted - either as a Simple Instrument track or with separate MIDI and Synth Audio tracks,- and have Input Echo enabled - button looks like ))) - on the MIDI/Instrument track in order for the MIDI input to reach the synth. This will happen automatically if the track has focus (track name highlighted), and "Always Echo Current MIDI Track" is enabled in Preferences as it is by default.

I'll have to think about it but right offhand I don't know of any project state that will make Bounce to Clip(s) unavailable other than not having any clip selected, in which case the whole Clips menu would have been grayed out. Not a common problem in any case.

I started to write a solution using an Aux track in my original response, but then back-tracked because I wasn't immediately sure how I would manage the returns in a transparent way, and I knew whatever I came up with was going to be unwieldy at best. As much as I like getting creative to make things happen, if the spare outputs are available, I'd be inclined to just bite the bullet and sacrifice a couple.

It's a longstanding and frequently lamented limitation of External Insert that each instance takes a stereo pair of outputs. You'll need to use one side of two pairs of outputs.

I'm having a hard time following all the different scenarios you've posed and understanding what your expectation is in each case so I'll just say this: By my count there are 4096 combinations of the following variables (not including side-chaining). No human on the planet is going to be able to keep in mind which of these combinations will produce nulling source and aux tracks. My advice is just to be aware of all these variables and experiment in the moment to get the desired result in a given situation. And maybe make yourself a 'cheat sheet' for specific scenarios you find yourself using repeatedly. - Source Input (m/s clip w/ or w/o Input Echo, m/s live input, m/s synth) - Aux Input (l/r or s from the Patch Point) - Source Interleave - Aux Interleave - Centered or Panned Source - Send Pan Follows Track Pan - Grouped or Centered Aux Pan - Mono/Stereo FX on the source track - Mono/Stereo FX on the Aux track - 0dB or Non-Zero Center Pan Law

No, you have to set everything the way you want. Interleave and mono/stereo input selection are also independent. In my test case, I set the Aux track to receive only the left channel of the patch point. https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Playback.19.html "The Mono/Stereo button in each track forces the track’s audio signal to enter any patched plug-ins as either mono or stereo, whether or not the tracks are mono or stereo. This allows you to use either mono effects on a stereo track or stereo effects on a mono track. Note also the documentation mentions that having input echo enabled (always the case on a live Aux track) will increase the level of a mono clip (presumably also the case for a mono patch point input) by 3dB: "Mono audio clips may be increased by 3 dB in certain scenarios There are some situations where the level of a mono clip will be increased by 3 dB if the track's output interleave (mono/stereo toggle) is set to mono: If the track has mixed stereo and mono clips The track has a synth selected as its input source Input Echo is enabled or the track is armed for recording In summary, whenever the track output interleave is mono and the data interleave is stereo, mono data will be increased in level by 3 dB."

Did a quick test. Works as expected if Pan Law is -3dB Center which is often needed when going back and forth between mono and stereo.

This may or may not be unexpected; I'd have to try it and think through the logic. But I don't see how that relates to the independence of Patch Points and Aux Tracks. I just meant they can be created and named separately, and there doesn't have to be a one-to-one relationship of Aux tracks to patch points. An Aux track is any track that uses a patch point as input.

Not quite. Not looking for a big debate, but curious why you would object to that statement.

No, probably not; just wanted to put my $.02 in for the record. Yes, I've done other button changes/swaps for myself. I probably won't bother with the Read button because I almost never touch it and it's already pretty unobtrusive when 'lit'.

Yes, a Patch Point is essentially just a stereo 'pipe' that any track can use as a destination or a source. Some confusion may arise because creating an Aux track automatically creates a Patch Point with the same name assigned as Input to the track, but the two objects are really independent of each other.

As I said, the PRV can do this once you convert pitch to MIDI which the Melodyne demo can do so long as the source is just a vocal track with no accompaniment

I assumed you wanted Melodyne/RipX-style pitch indicators that can show 'bent' notes. If you just want basic note/pitch indications, you could convert both tracks to MIDI, and show both in the PRV. But I wouldn't think you would need anything visual if you're only concerned with whether you're nominally singing the right note...?

I disagree, and would definitely not want the Bakers to adopt this convention. I'd be okay with adding a slash to the FX and PDC buttons to clarify that they have 'Bypass/Override' functions, but the lit state should still be indicating whether the button is engaged or not, regardless of whether it has an 'enabling' or 'defeating' function. So both states would show the slash. For me the mental conventions is that a project is in 'normal' playback/mixing mode when nothing is lit. Actually, now that I think about it, for consistency with that convention, the Read button would have a slash and have its 'lit/engaged' status reversed in my perfect world. ;^)

The Patch Points that connect sends/outputs to Aux tracks are inherently stereo, and selecting which part of the stereo Patch Point signal to use as input to an Aux track does not affect the channelization of the source(s). This allows, for example, sending/outputting a stereo track to Patch Point, sending/outputting a mono track to the left side of that same Patch Point and another mono track to the right side, and then having any number of Aux tracks receiving one or both sides of that stereo signal as needed. The sources and destinations can 'do what they want' without affecting each other.

Extracting a vocal take from a finished mix would require one of the two higher levels of Melodyne, Editor or Studio. And showing both the extracted take and your recorded take would require the highest level, Studio, as Editor does not support multiple active tracks. Even then, I suspect it might be difficult or impossible to see them 'side-by-side' for comparison. I don't know of any freeware that can do what you want.