David Baay

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.

When you open the bundle, you'll get a dialog with checkbox to "Store Project Audio in it's own Folder". If you uncheck it, new files will be created in the global 'Audio Data' folder. The new files will have the project name with sequential numbers in parens. Depending on the version that created the project, the original file names may vary, but recent versions will have named them with the track name and 'Rec' and a number in parens related to the order in which it was recorded. So there will not be collision or over-write of existing files, but in order to reference those files you would need to delete all the new ones, re-open the project and re-select the original files for each "missing"" file as prompted, which could be difficult and error-prone , depending on how many files are in the project and how they're named. My advice would be to let the bundle create a project-specific audio folder and just move on to the new world order. If you find there is something wrong with the new audio files you can go through the drill to open the project with missing files and reference the original files. BTW, I just re-tested this to be sure I wasn't leading you astray and you can trust that you won't lose your original files no matter what you do.

What you're encountering is an 'interoperability' issue; it only manifests when software x is running on platform y and can be eliminated by changing either of those variables. Just as you don't experience the issue with other software running on the same platform, many users do not experience the issue with the same software running other platforms. In your case, since you've reportedly seen it on different systems with different interfaces, this suggests that the specific configuration of preferences and/or project setup/content (aside from just having a lot of tracks) or other software on the system may also be contributing. The blame for an interoperability issue cannot be assigned to either the software or the platform without a proper root cause analysis; either or both could be doing something 'unexpected' per some design 'standard' that causes the issue to manifest. This is not something the forum community can easily help resolve unless someone happens to have seen it and resolved it for themselves.

Use Paste Special (Ctrl+Alt+V), hit the Advanced button if necessary to expand the dialog, and uncheck Tempo. Similarly, you can use Copy Special and exclude tempos from the copy.

This does sound somewhat like an unlicensed plugin but usually they will just go silent periodically or "chirp" quietly. Since you're using Melodyne did you also recently update to 5.3.0.011? This new release is not launching for me so may have other issues. Another thing I know of that can cause loud glitches is plugin incompatibility with the 64-bit Double Precision Engine.

What are you automating? Any chance Offset Mode is engaged in the Mix Module (+ signs in track widgets)?

I have suggested to the Bakers a number of times that they convert all the old CAL routines to native functions, correcting/improving the logic as needed. Seems like low-hanging fruit.

Try this one: http://forum.cakewalk.com/CAL-Script-CleanTrackcal-a-combined-duplicate-and-overlap-remover-m3782351.aspx

I can only reproduce an issue when switching either the FX Bin or the plugin itself off and on, and there are a few twists. In Summary: - It seems CW solved the problem of needing to restart the transport to re-sync by forcing a momentary restart when you toggle FX bins off and on. You can see and hear the transport doing this. - The restart happens both ways with a VST plugins (e.g. Transient Shaper) but only when going from On to Off with a DX plugins. This explains what Glenn saw. With Sonitus Compressor you have to do a manual restart when taking the FX bin from Off to On. My guess is Sonitus EQ will behave the same way. - In my testing, I was initially toggling the FX itself rather than the bin which doesn't force a restart either way (no transport hiccup) but maintains sync consistently both ways with VST plugins, and fails consistently both ways with Sonitus Compressor.

Once upon a time it was always necessary to restart the transport when toggling a PDC-inducing plugin on or off - either way - to reset the PDC amount . I don't recall when that changed , but automatic PDC re-sync does seem to be working for VST plugins. I haven't looked at your project but just did a quick test of my own with the Sonitus Compressor (64 samples of delay) and found the signals consistently going out of phase when the enable/disable state is changed during playback but getting back in phase when I switch back as expected. If it didn't go out of phase the first time you switched it off and back in phase when you switched it back on, that would be unusual. I can't repro that in my project. In any case, it seems likely this is only an issue with DX plugins.

That's the one:

Only way I can think of involves some creativity (read kludginess) and a couple 3rd-party plugins: You can use any of a number of free 3rd-party MIDI FX plugins to change the controller number (e.g. TenCrazy's 'CC Map' - https://tencrazy.com/gadgets/mfx/) but since MFX are applied to the output of the MIDI track you need to get that re-mapped output to the input of the MIDI track driving the synth in order to get real-time results. The easiest and best way (no latency) I know of (credit to scook for finding these) is to use one of CodeFN42's VSTi MIDI plugins like MIDIChFilter to create a virtual port that the second track can use as Input for the modified MIDI. VSTi-based plugins require an audio track to work in CW, so this should be inserted as a Simple Instrument track and then insert the CC Map MFX in that track's MIDI FX Bin and set the desired mapping. Then set both the output of your keyboard and pedal tracks to the MIDIChFilter 'synth' and set the input of your Keyscape track to the MIDI Out port presented by MIDIChFilter (make sure MIDI Output is enabled in synth options when you insert it): https://www.codefn42.com/midichfilter/index.html If you need more step-by-step, click-by-click instructions to make sense of this let me know. If CodeFN42 offered a CC Mapper plugin, that would somewhat simplify things, but I don't believe they do.