brundlefly

Something similar was reported quite a long time ago with Exclusive Solo in the PRV Track Pane. Probably the same root cause:

Yes, I use scroll wheel a lot.

Okay, I thought you were saying that toggling the Master bus interleave to mono and back was doing something to interleave of the source track. But the issue is that Bounce to Clip(s) is is forcing the plugin to output mono until the bypass is toggled. You might want to clarify that in the title, and put the step that triggers the unexpected behavior (Bounce to Clip(s) last. Yes, that seems buggy.

First be aware that MIDI track meters are always registering output regardless of whether the track is armed or not. So the only valid test of whether Input is working indpendent of Input Echo and output/metering/rendering is to try recording something. If recording works and playback works, then it's an Input Echo problem If nothing is recorded, some things to check: - The left-side (input) indicator in the MIDI Activity monitor that CbB places in the System Tray is responding to the controller. - The track Input is Omni (all channels) or to same channel as the controller is transmitting. - The track is armed and/or 'Allow MIDI Recording without an Armed Track' is enabled in MIDI Playback and Recording preferences. - The event types you're trying to record are checked in MIDI Playback and Recording preferences. The last two would affect recording but not live Input Echo so probably aren't a factor in any case.

Can't repro, but not sure how the various actions would be related and might be missing something. Does it really matter that the plugin is set full wet and the clip is bounced and the interleave on the Master is toggled to reproduce the issue? I went through the steps twice from scratch starting with the Basic template and the interleave on the track with the Sonitus Reverb is remaining mono as expected. in the first case, I started playback a few times at various points, and in the second case, I did all the steps without ever playing back.

The question is about the default Input assignment for a MIDI track (or the MIDI side of an Instrument track). The order of synths in the rack has no bearing on this. The way this works partly depends on the setting of 'Always Echo Current MIDI Track' in Preferences. If it's disabled, the default Input will be 'None'. If 'Always Echo...' is enabled or you manually enable Input Echo on a new track without first selecting an Input and there is more than one hardware and/or virtual MIDI input available, the track Input will default to All Inputs - Omni. The only way to get around this behavior is to use track or project templates as Greg suggested. Bottom line: No, there is no option to set a default MIDI Input assignment for new tracks inserted without using a template. I don't know why this has never been implemented as it's been requested many times over the years (decades!). If a track template can do it, you would think a default template could easily be designated for inserting new tracks.

Those were the days - extremely efficient. ! I think the track inspector could use a much better UI. Particularly with transpose slider - it's nearly useless to me....there are many places you can key in numerical settings, but you can't key in a transposition value in the slider widget. I'm pretty sure the Inspector can do all of this in much the same way with the exception of quickly selecting a patch per measure, but that was only possible because that view only allowed editing at resolutions down to a measure! Anything finer had to be done in the Event List. But the ability to "arrow up or down" to increment/decrement any control, including Channel, Bank, Patch and Key+, is still present. Just select the control and use +/- keys to inc/dec by one or ]/[ keys to inc/dec by 10 (or 12 in the Key+ control for obvious reasons). And to enter a specific value, just hit Enter to enable editing. I think advancements in graphical mouse-driven editing has caused a lot of people - including me - to abandon keyboard-based editing, but the capabilities are largely still in place, just a bit harder to keep all the shortcuts in mind because there are so many more view and functions available now. No doubt there are limitations, and keyboard navigation has become more awkward in some parts of the UI, but it's worth re-exploring the possibilities.

Have not used the arranger much myself but thought I would try to replicate your issue. I created a simple project consisting of an Instrument track and a Bounce of the audio from that track to a second track with 48 arranger sections of random length. Initially I just dragged the last section to be first in a new arrangment. I encountered no issue comitting that arrangment to the project or exporting the sections without committing. The one snag I encountered was that there doesn't seem to be an option to use arranger section names as filename tags...? One big caveat: To save rendering time, my whole project is only 1;24 long with the longest section being about 3 seconds and there are no plugins other than the synth for the Instrument track. If your issue is related to the duration of the project and the resources needed to render it, my test won't be relevant.

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.