David Baay

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.

Yeah. me too! This is the kind if issue that could benefit from having eyes and hands on; if you could share a stripped down version of the project that demonstrates the problem I could check it out. I don't have EZDrummer or the Mixwave synth but have a lot of other drum synths. Kontakt and many compressors. Otherwise I cannot reproduce a phase error sending to a bus or aux track with a PDC-inducing plugin on it.

What you're talking about is technically called 'focus' (name highlighted, target of a paste, shown in the track inspector) as opposed to 'selection' (number highlighted, source of a copy, object of keyboard commands). Cakewalk deliberately separates these two states. For one thing it facilitates track-to-track copies In addition to just clicking in an empty area of the track header, the up/down cursor keys will move focus if they haven't been remapped.

What plugin and what drum synth? The FX section in Addictive drums adds 64 samples of PDC that I once reported was not being compensated properly when doing parallel compression. I don't recall if this was ever fixed. Workaround was disable Addictive FX, and use 3rd-party plugins on its output tracks. Other than that, assuming PDC Override is not enabled. It sounds like the plugin is not reporting its PDC, but that would not explain how changing interleave fixes it - that's just weird. Can you repro with a different compressor plugin or drum synth?

Polyphonic audio-to-MIDI is still a work in progress, even for Melodyne, and poly-instrumental polyphonic conversion (i.e. multitrack MIDI from a full mix) is still pretty much a 'no'.

Not able to reproduce a problem immediately. What ports do you have available and what assignments are you trying to save.

I would not have thought it was possible to mis-implement a stretching algorithm. I'd be interested to hear renderings of the same material from Cakewalk and Reaper side-by-side. I'd be really surprised if there's a difference, but if so, you could have the Bakers look into it.

You have to download it using Bandlab Assistant.

Yes, you can select the entire project with Ctrl+A. Then Ctrl+click on the box in the Audiosnap section of Clip Propertie in the Inspector to activatr it on all lcips. And then then use Ctl+click again to change the stretch mode and algorithm on all clips at once.

Not to continue too far off-topic, but just having a soft synth in the rack will force the project to use the Audio clock. Same with enabing the audio metronome. You cannot set the clock to Internal and have it stick unless nothing in the project depends on the Audio clock.

That's the typical experience for other CW users, too. It's especially unusual that this issue has persisted across multiple platform. As suggested, anti-virsu seems a likely candidate. I only ever experienced something like this when windows Defender's Real-time Scanning mode became spontaneously enabled by a Windows Update with no directories excluded.. Another thing to try would be to rename your AUD.INI file (or use the button in Preferences > Config File to Reset Defaults). And definitely get rid of any 3d-party drivers like ASIO4All and Steinberg's 'Generic Low Latency ASIO Driver' installed by Cubase. BTW, CbB is technically no longer supported on Win 7 or 8.1 although I know there are a significant number of users still on 7 with no issues.

This is corrrect. The inability to change sample rate after the fact only applies to projects with clips referencing recorded/rendered/imported audio files. Technically "MIDI-only" refers to a completely audio-free project (no soft synths, no active audio tracks, and MIDI metronome), using the 'Internal' system clock for MIDI timing with MIDI tracks driving direct-monitored hardware synths (or onboard 'Wavetable' synth), but it's often used to refer to any project that doesn't contain audio clips as John is in this case. FWIW, the last time I tried it, CbB wouldn't actually run a true MIDI-only project with clock set to Internal; the transport wouldn't budge.

Make sure the mode is Autostretch before enabling Clip Follows Project and set the Online rendering algorithm to 'Groove'. I've found the Elastique algorithms can get weird in certain situations, especially with percussive/rhythmic parts. I've only ever reproduced a progressive loop sync error like that once, and it was so slight (samples per iteration) that it took hundreds of iterations to get to a 20ms delay.

I'm not aware of any change in this regard. It's always been necessary to proactively restrict MIDI/Instrument track Inputs to the particular port and channel you want a track to record/echo any time you potentially have input from more than one port or channel, whether hardware or virtual. I learned this early on as my first MIDI controller (1988!) sent MIDI on two channels by default.

Yes, I've reported in the past that the 'confidence recording' indication on MIDI tracks shows all MIDI input whether the channel and port are matching the Input setting or not. It's not a big deal for me since I don't often use MIDI-generating plugins, but it's not ideal.

ROTFLMAO! Check my forum history, both here and on the old forum, and ask anyone who's been around here for a while about my ability to tease meaning from inadequate problem descriptions and solve problems. Also note that Mark acknowledged and fixed this issue only after I clarified how to reproduce it. In any case, you needn't worry yourself about my compreshension as I won't be reading or responding to any more of your posts. Cheers, Dave

Oh, no, here we go again... I meant the project setup and actions that produce "nudge are slightly off by a few .0 milliseconds in its jump". BTW, I just did a quick test, and did find it's not possible to nudge back to time zero, specifically, after nudging later from there. This actually rings a slight bell as having been reported previously. I'd have to search. Works as expected anywhere else in the timeline.