Elena Kolpakova

Respecting the Global Snap for Staff view is very inconvenient. Normally the precision of editor and track views are different. PRV has an independent Snap options exactly for that reason, e.g. I always have it at 32nd in the PRV and Smart Grid globally. With Staff view it's even worse as there's no way to zoom in horisontally in a hope that Smart Grid would pick the right snap resolution, so you have to change the Snap all the time as you switch between SV and TV. I think a good solution would be to add the same independent snap settings to the staff view as there are for PRV, i.e. this I know this has been a workflow showstopper for a couple of colleagues of mine, and every one of them has reverted to the previous version.

After I'd read the section one point one of Bandlab's Terms of Use, I came to conclusion that that document is pretty much the EULA for CbB too. So in case anyone's looking for it, here it is: https://blog.bandlab.com/terms-of-use/

Looking for the License Agreement and having troubles finding one - where is it located these days?

This is brilliant and works great! Thank you so much! And a very smart idea to work around the limitations!

Is it possible to break from a (forEachEvent) function? I know (break) and (return) do not work, and (exit) ends the script execution entirely. Perhaps there's a (goto) at least? Or, is it possible to (delete) an event outside (forEachEvent) function, e.g. by its index in the selection? Or could I iterate over events without calling (forEachEvent)? The reason for the question is that the default, bundled undupe.cal doesn't work with polyphonic sequences. So I wanted to write my own, but it seems it's pretty much impossible at this point. My last hope is for some undocumented features of the language to be there like a loop break I asked above. Any other ideas are welcome of course. I guess the edit commands could be useful but I feel lazy to dig into those if there's a way to avoid them.

Yes, I think this depends on the workflow which is probably different for many of us. This is probably the reason why Logic has two types of Stack tracks - those where audio routing is implemented and those where it is not (used purely for organising tracks). On the other hand I don't really see how having my proposal should affect you tbh. Imagine that ONLY WHEN NEW audio tracks (or the audio part of the instrument tracks) are added to the Folder track, THEN they are automatically routed to the Folder patch point where they are summed together. IF you use the Folder track purely for organising other tracks in your project, THEN you're not going to add any FXs to the Folder tracks's FX bin/pro channel, and that will essentially output the sum to the Master bus or the bus set up in your project as the default output. Which is practically the same as it is now except the fact that it goes straight to Master/default out. EXISTING audio tracks when moved to the Folder should not change its output, so that the rest of your project routing is not immediately f**d up when you move the track into the folder. Although I could see two menu options in the Move To context menu: Move To Folder & Route to Folder Output, Move To Folder & Keep Current Output And OF COURSE you should still have the option to change the output of the track within the Folder to a different output if needed. If you ever worked with NI MASCHINE, it's the same there. By default, Sound (Instrument) is routed to a Group (Folder), which is rooted to Master (Bus). But you're free to change the output port of the Sound to any other available destination, so that, say, 15 sounds are routed to its group, while the 16th is routed somewhere else. Also, as I mentioned, MIDI track outputs (and MIDI parts of Instrument tracks) should not be affected by the Folder - it doesn't make a lot of sense. I only mentioned MIDI patch points above because having those is something I wanted for a while now (for MIDI Sends), but it really is a different feature. Or perhaps I didn't understand you. Anyway, I hope bakers will find the best solution to this as they have resources to properly think it through and test it.

I have a bunch of feature requests for track handling. 1. Turn Folder tracks into Aux tracks so that FXs/ProChannel can be applied to the Folder output. When a Folder track is created, make sure a corresponding audio patch point is created. New audio tracks created in the Folder track are routed to the corresponding patch point automatically. Audio tracks moved in the Folder track should keep their current output assignment. 2. Introduce MIDI patch points and advanced MIDI routing. Sends from one MIDI track to other MIDI tracks should be possible, so that MIDI events of one track are put to the outputs of multiple MIDI tracks at the same time and there's no need to copy paste events from one track to another. 3. Make sure current MIDI effects have good modern UX/UI to cover the basics in real time: transpose (quick +/- octave buttons), delay (or time offset), velocity increase/decrease, humanise - this is gonna be used heavily for creating double tracks and layered sounds. 4. MIDI events on the MIDI track should take precedence over the events received via the patch point when there are duplicates, e.g. same note with the same timestamp or mod wheel with different values. I'm unsure whether the MIDI-related automation should be sent via the MIDI send at all, perhaps only clip-based automation. 5. Folder tracks should only affect the audio tracks in terms of routing, i.e. when audio tracks are created within the Folder, they get routed to the audio patch point of the Folder by default, but when MIDI tracks are created within the Folder, they are not routed to the MIDI patch point of the Folder. 6. Nested Folder tracks - this is self-descriptive enough I believe. I'm sure I haven't thought all of this through properly and would probably need to test it after the first iteration, but you get the idea, I hope, and should be able to develop this further yourselves. I also kinda really like the non-destructive MIDI editing per clip from Logic for velocity, quantisation, etc

Yes I tried that and also a limiter on the master bus, but to no avail. It all just dies. But I managed at least to narrow it down to Massive X now. It happens with MX loaded either directly or via Komplete Kontrol. The moment I hit the Record button, sounds from MX die with a single nasty click. The issue doesn't happen to me with any other plugins. Too bad, their 1.1 update comes with really good and inspiring sounds... Now looks like I'll have to wait for the fix.

Hmm, got myself a nasty project while using 2019.09 - when trying to record some MIDI data on a synth track, the sound from all tracks in the project gets lost and the level meters in the sound card mixer software indicate continuous clipping coming from CbB. The project contains two synth tracks (both are Massive X 1.1.0 each loaded inside Komplete Kontrol 2.1.6). First track contains two track lanes for MIDI data (notes and MIDI controllers) and six automation lanes (various synth controls). Second track contains two track lanes for MIDI data (notes and MIDI controllers) and no automation lanes. The lane of the 2nd track designed for MIDI controllers has no data on it. In fact, I want to record it, so the lane is armed for recording. Project recording mode is set to Sound on sound as I want to hear the lane containing notes while recording the mod wheel. Now, depending on when I start recording from Stopped state or from Playback state, the behaviour varies: 1. If I hit the Record button from a stopped transport, then I hear the metronome ticking the count-in measure followed by an explosive crackle and silence with the level meters in the sound card software displaying continuous clipping. The only way to resolve this is to reload the project. 2. If I hit the Record button during playback, then I can still hear the first synth playing, able to record the data, but can't hear the second synth (the one I'm recording), which shouldn't be happening in Sound on sound mode. I could upload the project if it helps. Also once I got into that silent state, I tried changing the buffer size from 256 to 512 in Preferences. Then all of a sudden I could hear both synth playing again, but with heavy crackling as if it fails to fill the buffer. And this would soon stop with a dropout. However, no toast notification pops up to indicate the dropout code.

Sounds great! I also wasn't much of a fan of the Ctrl+PageUp/Down keypresses keeping the playback, but that wasn't much of an issue for my workflow. So I'm looking forward to the change you've just described! I also like the consistency of such implementation. Also, I understand the case for mixing as you described it, but for me looping a part has always worked wonders in that regard. And in those rare occasions when I needed to start playback from the loop start before the loop ends, a combo of [W]+[Space] was always there. Anyway, thank you very much for the support and bringing hope I can enjoy CbB again 😊

Unfortunately, I couldn't find the "Stop and Rewind to Landmarks" action in key bindings. Funny how this is considered a feature, but it's been one of the reasons I chose Cakewalk in the late 90's against Cubase - just can't stand the playback not stopping after rewind. I really hope that bakers will make this feature at least adjustable. Otherwise it destroys the experience accumulated over 20 years... Very close to a showstopper to me, to be honest

Is it possible to revert the Rewind behaviour to the one in previous versions? The fact that it keeps playing after the rewind button has been pressed, breaks my flow as it feels counter-intuitive and introduces an extra button press: [Space] to stop + [W] to rewind, instead of a single [W]. Typically when I work on a part, it's looped and I face two cases. In 2019.07 and earlier versions: Case1: Often, I need to Stop at a particular moment that I want to edit. Therefore my Stop behaviour doesn't Rewind to the loop start, to keep the focus of the problematic region. Once I'm done editing, I want to listen to the results in context, therefore I Rewind and Start playback. In short (Stop doesn't rewind): [Space] [Space] [W] [Space] Alternative (Stop rewinds): [Space] [Ctrl]+[Space] [W] [Space] Case2: Equally often, I need to Stop to get back to the beginning, because the part I need to edit is around where I started, I just kept on listening after the problematic part, for context/pleasure. Because my Stop behaviour doesn't Rewind to the loop start, I conveniently used the Rewind button to bring me back. In short (Stop doesn't rewind): [Space] [W] [Space] Alternative (Stop rewinds): [Space] [Space] [Space] You can tell, that my preference up till now was much better - it relied on two keys instead of three and needed less key presses. The 2019.09 breaks this flow: Case1: remains unchanged In short (Stop doesn't rewind): [Space] [Space] [W] [Space] Alternative (Stop rewinds): [Space] [Ctrl]+[Space] [W] [Space] Case2: adds an extra and very unwanted Space press In short (Stop doesn't rewind): [Space] [Space] [W] [Space] Alternative (Stop rewinds): [Space] [Space] [Space] Not to mention, that historically, many tape machines would not start the playback automatically after the rewind process had completed, unless you stopped the rewind with the play button. So the 2019.09 also breaks my intuitive expectations.

Wow, these are the best changes ever! I can finally, FINALLY, use lanes for proper MIDI drum programming. Or string parts layering. Or left/right hand piano layering, etc. And then, automation editing, copying, pasting suddenly just works. Absolutely fantastic improvements. Really well done and thought through! Most of them are so intuitive you don't even notice the changes until you close a project and think to yourself, 'Wow, Cakewalk has been working like a charm today - such a pleasure to use it!'

And here's another which I finally caught. It's not unique to 2019.07, but annoyed me for years now. Would love to see this fixed. Short Description: some VSTs get all MIDI ports selected on the corresponding MIDI/Instrument track as a MIDI In port after the track is armed for recording. Reproduction steps: Insert one of the problematic VST synths in a new project. Create a corresponding MIDI/Instrument track if not created automatically. Notice that by default the MIDI In on that track is set to None (Omni). Arm the track for Recording. Expected: Typically, the MIDI In port of the track is then switched to "All Inputs - MIDI Omni" Observed: For some synths several MIDI ports are selected at the same time which looks like this Known VSTs affected: All NI synths (Komplete Kontrol and Maschine 2 are especially hurting in that regard) Adam Szabo's JP6K and Viper TAL U-no-LX-V2 chipsounds (but chipspeech is fine) AudioRealism ABL3, ADM (but ReDominator is fine) Novation V-Station Cakewalk z3ta+ VST known to work fine: LennarDigital Sylenth Reveal Audio Spire U-he Diva, Repro-1, Repro-5 AAS synths Xfer Serum Cableguys Curve 2 Cakewalk Z3TA+2 This behaviour is consistent on my machine, i.e. it survives reboots, CbB restarts, is independent of the project and project template. Also while testing, I noticed that SonicProjects OP-X PRO II crashes CbB on insert - it's working totally fine in Komplete Kontrol though. But KK is affected by the weird MIDI Input ports issue.

Yes, sorry wasn't at my workstation to post the screenshot with my original post. Here's the screenshot: Here's the reproduction: Start CbB - it loads the Normal.cwt Open an existing project from the Start Screen (in this particular example, the project was created in 2019.05 but I think it doesn't matter)

One small bug observed on my windows 10 1803 machine: After the existing project is loaded, transport section in the control bar is not properly rendered until I select any track. Other than that: Really glad to have the bug fixed that was causing a project crash when opening it before closing the previous one! Also like the selection highlighted on the timeline. Haven't tried how this works together with the loop markers over the same region though - that case was not handled nicely in previous versions.

Maybe it's one of those bugs that were observed in earlier versions for users of NI keyboards, when Omni is selected as MIDI IN on an instrument track for the instance of the Komplete Kontrol VST Plugin. It would somehow turn into several MIDI ports selected at the same time: * Komplete Kontrol - 1 (first physical MIDI out over USB that contains the keybed data - notes and controllers) * Komplete Kontrol 1 (MIDI Out of the first instance of the Komplete Kontrol VST plugin loaded in the instrument track) * Komplete Kontrol DAW (second physical MIDI out over USB that contains transport control buttons) This would cause notes to be recorded twice (one from keyboard, another from MIDI through of the KK VST plugin instance) and other annoying inconsistencies until one manually set the MIDI IN to Komplete Kontrol - 1. So maybe some had projects where those Omni inputs were never manually fixed, and the new version just dies when it faces such tracks. That's a lot of guessing on my end though considering I haven't tried 2019.7 yet 😅