David Baay

Global Snap, PRV Snap or both? What options do you see when you right-click the resolution button?

Proteus VX will show a UI with JBridge but it's extremely unstable. I gave up on it.

Cakewalk only has Touch mode for writing automation envelopes. If you use automation envelopes for MIDI controllers, you'll be able to overwrite in touch mode, but there is no equivalent for actual controller (or note) 'events' in a MIDI track. EDIT: Comp record mode could help achieve the desired result, but you would likely have to do some editing with the Comp tool in lanes and/or in the PRV after recording the overdub.

Your Console view shows the I/O Module is hidden. Normally the ouput of each bus would be shown immediately above the bus name; enable 'In/Out' in the Modules tab of the Console view to see that. But the top of each strip shows you're 'Sending' the Vocal and Drums buses to Master, and 'Sending' the Master to Speakers in addition to having the Ouputs assigned, That's creating duplicate signal paths; you just need to delete the Sends and you'll be good to go.

This isn't likely to happen because there would be no point in recording controllers that don't overlap a clip with notes in it and CbB will not split the events of a single take across lanes. That said, I've encountered issues in the past with take lanes getting out of order or clips being layered in the same lane when using the Re-Use option so I just have it set to Create New and do the housekeeping as necessary - not that much i my workflow. I don't really have any insight into why arming a track also effectively solos that lane. I just know that it does it for both MIDI and Audio tracks and that it's not the kind of thing that would happen incidentally without being deliberately programmed so I've always presumed it was deliberate.

If the 'existing beat' is an audio clip, try Drum Replacer (included with CbB but installed separately). If the 'existing beat' is MIDI, you can use the Matrix to host the sample. Otherwise you'll need a 3rd-party sampler (assuming you don't have legacy CW synths like Session Drummer 3).

A couple other thoughts in case this is project-specific. - Having MIDI FX in a project can mess with buffering, even if the FX is not on the track that's mis-behaving. Improvments to the MIDI buffering implementation some years ago eliminated some issues from Pre-Bandlab versions but some may persist. - In the past I have also seen issues with a particular note being consistently dropped that would resolve when the note was moved a single tick or the tempo was changed by a single point. I believe this is more common when all MIDI start times and durations are quantized 100% to the grid so that many notes are starting/ending at the same time on different instruments. This isn't as likely to happen if you record MIDI in real time and don't hard-quantize.

Arming at the lane level is causing this (intended behavior I think). Just arm at the track level and let "Sound on Sound" and "Re-use Except When Takes Overlap" do its thing (personally I prefer to force 'Create New Lane' for every new take for total predictability).

I assume you mean Buffer Size in samples...? ASIO buffer size shouldn't really have a bearing on soft-synth rendering so long as you're not actually getting audio engine dropouts. It takes a fairly well-tuned machine (low and stable DPC latency with reputable ASIO interface and drivers) to run cleanly at buffer sizes below 128, but I do it all the time on my desktop DAW and do not encounter soft synth rendering issues. But I have seen/heard dropped MIDI notes on laptops using WASAPI with not the greatest DPC latency, especially if the MIDI Prepare Using buffer is too low.

Try increasing the MIDI "Prepare Using" Buffer under Preferences > MIDI > Playback and Recording. I believe the default is 50ms. My desktop DAW with ASIO runs fine at 20, but my slowest laptop with WASAPI needs 100.

So no limitations/exclusions other than track count? Might be interesting to see what all the fuss is about after all these years.

Maybe have them install CbB and drag-drop to the track view. Or is it a Mac? If it's a Mac, that might explain the file incompatibility as well.

Per the documentation, creating a new group that includes existing and added clips is the expected behavior. You aren't actually creating multiple goups, just incrementing the group number every time you add to it. https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Arranging.34.html To add clips to an existing selection group 1. Click on any clip in the existing group. All clips in the group are selected. 2. Hold down the CTRL key and click the clips that you want to add to the group. 3. Right-click any selected clip and choose Create selection group from selected clips from the pop-up menu. All selected clips are placed in a new selection group. Note: A clip may only belong to one selection group at a time. If any of the selected clips already belong to another clip group, they will be removed from the other group and placed in the new group. P.S. If i were you, I'd definitely be looking for a free or low-cost De-esser!

Yes, we had a number of conversations about this back around 2013/2014 (!) when this actually broke in X3b. It was fixed in X3c but you continued to report it not working. Possibly we never figured out that it was because you had changed the default binding but I thought we had.

Yes, show the PRV track pane. Tracks with numbers seelected will be displayed in the PRV, and the one with the name higlighted will be focused and show notes with colors while the other track(s) will be grayed out. Depending on the setting of Auto Focus/Auto Lock at the top of the PRV track pane, you can enable chanigng track focus by clicking on a grayed note or have unfocused tracks locked against accidentally being edited

Yes, the grid should continue to show because youre just disabling snap without disabling the PRV snap grid.

Cool. Glad to help.

You can't explcitily bind to 'Snap Toggle Extended'; you just have to clear any non-default binding you have and the default will be restored.

I think we've been through this a couple times before. Per the documentation: "The Piano Roll view always obeys the global Snap to Grid on/off setting, even if you specify an independent snap resolution in the Piano Roll view." What this is saying is that if Global Snap is off, PRV snap will also be off. 'N' is bound to 'Snap Toggle Extended' by default. If you've changed this default binding to 'Global Snap On/Off' the PRV snap on/off status will not follow the Global snap on/off.

Yes, 21 samples is a tiny discrepancy that you will only ever hear as a phase error, but you definitely will hear it in the right circumstance. In my book, it's always best to have your record latency dialed in to the sample as a starting point so that when you get weirdness like PDC failures or parallel compression phasing you know it's not your hardware setup. That said, there are many unavoidable sources of latency and sync errors (especially for MIDI guys using hardware synths like me), and at some point you do have to ignore things that you can't hear (or control). But it's amazing what a little phase change can do to the stereo image or the attack sound of a layered/doubled part when one signal is consistently early or late relative to the other.

No, Cakewalk does not offer this option. It has been requested in the past, but not recently that I know of. You can post suggestions like this in the Feeback Loop forum: https://discuss.cakewalk.com/index.php?/forum/8-feedback-loop/

That's correct, the same Manual Offset is applied to all recordings, regardless of the source. I have the opposite issue that ADAT input from synths is over-compensated by the Manual Offset that's configured to make up for the unreported 42 samples of A/D conversion time for analog inputs. It has been requested a few times over the years to have per-input Offsets, but not enough demand to make it a development priority.

If everything is going to be recorded via that preamp, you can add that 21 samples to the Manual Offset for record latency. But if you'll also be recording from your interface's direct inputs (hopefully not simultaneously), you'll have to manually compensate or change your Manual Offset for each case. Having one of your nudge values set to 21 samples will simplify doing it manually.

Okay. yes, I can repro that a project with hundreds of active Prochannel modules exhibits a momentary UI response 'freeze' after stopping the transport (which happens instantaneously) - about 2 seconds for 400 modules across 100 tracks in my case. Once the UI refreshes, re-starting the transport is instantaneous. With fewer Prochannel modules, the 'freeze' is proportionally shorter (e.g. half a second for 100 modules).

I don't believe there's a way to get proportional/percentage changes by dragging; you have to use the Offset Tempo Map dialog. Select All, right-click in the Tempo view and choose Offset Tempo Map (or Project > Offset Tempo Map in the menu), check the '%' box, enter the percentage and OK. Note that 100% is where it is now. 50% is halving all the tempos, and 200 is doubling.