brundlefly

Regarding legato.cal. It's working (or not working in this case) as it always has; it only works as expected with monophonic melody lines. As-written , it is not capable of handling chords. All it does is go through the event list, sequentially, and set the end of each note to match the beginning of the next (with or without a specified gap). In the case of chords where the start of the 'next' note in the 'sequence' is the same as (or close to) the current one, you naturally end up with a note that has little or no duration. It might seem like a simple thing , but it would take a lot of additional logic to recognize and handle chords properly, and this is challenging in CAL because of the way it processes MIDI events in strict order of start times. EDIT: I realize I'm way late to the party, and some of this may have been covered already, but while I'm at it... Regarding copy vs. cut behavior, I think it's debatable whether this is a 'bug', per se, but consistency in behavior when including space in the selection would certainly be helpful. Regarding Audiosnap, it certainly has its share of issues, but in this specific case the problem is self-inflicted by having the Follow Option set to 'Measures' instead of 'Autostretch'. The 'Measures' option make Audiosnap immediately try to 'fit' the clip to the project at measures based on the clip tempo map. If you just want the whole clip to stretch proportionally as changes are made to the tempo, you need to choose the 'Autostretch' option before enabling Follow Project. I understand the OP's wish to have Cakewalk be as solid as possible, but 'bugs' are often addressable by changing one's workflow slightly or just having a better understanding of how things actually work vs. how one might expect or prefer them to work. As such, it's not usually helpful to immediately ascribe 'buginess' to a something that doesn't work as expected before running it by the forum as a simple question: Is this expected, or am I doing it wrong, or is there a better way or a setting I can change to make it work the way I want?

If there's an issue, it would have to be very new. What exactly are you seeing/hearing? Basically you're saying that if you open a MIDI file as a new project, and then import that same file into a new track(s) in the same project that corresponding events won't have the same velocities. Is that right? Can you share an example file?

This was fixed in CbB. The workaround was to Alt+Tab to another application, and then back to Cakewalk.

Historically, the fix for dropped MIDI notes was to increase the value of the MIDI "Prepare Using" Buffer. Long ago, the default was 500ms; when SONAR X1 was released the default was reduced to 250ms which caused dropped notes in some projects just as you describe. In the 2019.11 release the following bug was reported fixed: - Setting the MIDI "prepare using" to 256 ms or lower causes missed or stuck notes. Along with that bug fix, the default was reduced to 20ms with the following notes: - The Default MIDI Prepare Buffer size has been reduced to 20 msec. Limitations preventing the MIDI buffer from being set lower have been removed. There should be no need to change the buffer size from the new default value anymore, since the engine automatically raises the internal size when necessary. - On first launch, Cakewalk will reset the MIDI buffer size to the new default value of 20 msec (Preferences > MIDI - Playback and Recording > Prepare Using n Millisecond Buffers). Notwithstanding the note about the engine automatically raising the internal size when necessary, there may still be situations where it's necessary to set the starting point higher, such as when using FX that use look-ahead buffers that trigger a lot of Plugin Delay Compensation. Some synths may also be more sensitive to it. I suggest trying a value of 50 or 100 or more, and see if it helps.

I'm also curious about the need for a 7/8 groove-clip in a 4/4 project. In any case, I would just blow off the groove-clip feature entirely, make a regular MIDI clip that's 7/8 long, and copy-paste as needed with snap at an 8th or with landmarks enabled to snap to clip boundaries.

Just to be clear, when you say "MIDI track", are you really using separate MIDI and Audio tracks for input to and output from MTPower, or is it a Simple Instrument track that combines MIDI and Audio features in one track? If the dipping/ducking is really related to the guitar signal it sure sounds like you have a side-chaining compressor on the drum track taking input from a send on the guitar track, but that wouldn't happen by accident, and would be hard to forget unless this is a project you're coming back to after a long time or was created by someone else....? But it would explain the behavior since a prefader send wouldn't be affected by muting the track unless you deliberately altered the default behavior by setting LinkPFSendmute=1 in the Config file (AUD.INI). If that's not it, you should share a copy of the project somewhere so we can figure out if the issue is in the project or in your DAW setup.

You may need to enter a more negative dB value for Other Beats in metronome properties. I usually go with -1 and -7dB for First Beat and Other Beats, respectively. I think the default is only 3dB lower, and does not provide enough 'contrast' for my taste.

No, but it does rule out that it's independent of the environment in which it's running, and the project content (i.e. Spitfire synths). Hmmm... that's quite different from "The worst thing about this is that even after rolling back, I'm still having issues with drop outs on Spitfire's OPW... now all of a sudden it's killing my projects. and "I'm getting serious choking even after rolling back." If rollback did in fact resolve the issues, and they are all related to Spitfire then you should report that in the 21.04 Feedback thread. I reported an issue with Izotope Iris 2 during EA that turned out to be related to the large number of automatable parameters it exposes interacting badly with the new automation code. But that was fixed, and was only noticable on my system at very low buffer settings of 32 samples. Even then, it wasn't causing 'serious choking', just crackles and pops showing up sooner than expected. In any case, it sounds like something about Spitfire synths, specifically, is also causing an issue with that new code in which case the Bakers will need to look into it. It will help if you report the symptoms and conditions in detail.

I long ago lost count of the number of reports of issues caused by updates that were eventually traced to some other root cause. Rollback pretty much eliminates the updated code as a cause of the issue. I suppose it's possible some other system issue was precipitated by the download or installation process, but you should still check DPC Latency whether you believe anything else has changed or not. Also, have you checked that interface driver mode and buffer size are unchanged...?

Check your system DPC Latency: https://www.resplendence.com/latencymon New hardware/firmware/driver updates can drive DPC latency up. Low is good - preferably no more that 200-300us (microseconds) - but stable without spikes is even more important. Bluetooth and WiFi drivers are common offenders, especially BT. They can be disabled in BIOS if/when not needed.

Pan one hard left, one hard right, and bounce to a new track with Channel Format set to stereo in the bounce dialog. Depending on your pan law setting in Preferences, the levels may change slightly.

Switch to the Edit tool. Smart tool wants to move the split point by default, but Edit tool will default to slipping the boundary. I'm out of practice so don't know offhand what modifier keys might allow doing this without changing tools.

You can either disable the Comp Tool or just avoid clicking in the lower half of clips where its active.

Thanks for confirming. I suspected that might be the case. As a 'MIDI guy', my most common use for punch is simply to define an end boundary when recording hardware synth tracks, so punch range is often from zero to end of the project. I generally don't experience any issues starting projects at zero, and do it all the time, but I would like to be able to re-number measures from 0 for the case that a piece starts with a partial measure of 'pick-up' notes, or needs to give time for a synth to respond to initial controllers or patch changes.

fermata (n.) 1876, musical term indicating a pause or hold, Italian, literally "a stop, a pause," from fermare "to fasten, to stop," from fermo "strong, fastened," from Latin firmus "strong; stable" A fermata will usually be preceded by a rit. in performance, whether notated or not, but the fermata itself is just a pause/hold/hesitation. An any case, the fact remains that no more than one, fixed tempo is needed to control the timing from that start of one note to the next. As I said, give me any example in MIDI, and I will demonstrate. This is the one thing I agree with, and a solution is was given.

To be clear. The clip starts at time zero in my case as well, but the audio within it is late. PM'd the recipe, and posting it here so others can repro: - New project from Basic template at 125 bpm with ASIO buffer at 1024, 48kHz sample rate. - Insert a send on the metronome bus to a physical loopback from an out to an in (lightpipe in my case so the big buffer dwarfs the hardware latency) - Set the Input on the default audio track to that loopback input, and arm it. - Record a couple measures of click with punch enabled from 1:01:000 to 3:01. - Zoom in and note the click transients are all 1024 samples late = about 43 ticks at 125BPM. - Disable punch and re-record, and the clicks are right on the money. I have my Manual Offset dialed in so the recorded click on a phase-inverted track will null perfectly with the live metronome. Same result if I use the correctly compensated click recording on another track as the source instead of the live metronome. And same result at all ASIO settings - audio is one buffer late.

I'm still seeing the issue that audio is laid down one buffer late when Punch In starts at time zero. Punch in a measure later, and it's good. I have not yet tested to see what happens close to - but not at - time zero.

After seeing both you and Tom report that punches are early vs. my experience that they're late, I did another test with punch-in starting later in the timeline instead of at 1:01:000 as I had done initially, and got the same 'early' punch result as you. Will need to verify both cases work correctly when Noel gives us another update.

You do this now by inserting a time signature change, and then another one to change it back after the measure(s) with added beats.

Loop back a send from your metronome bus via physical patch from an output to input (preferably separate channels from your main/monitor out and instrument inputs). If your manual offset is set correctly, the recorded clicks will land exactly on bars/beats to the sample when compensation is working.

For me, compensation is now correct without punch enabled, but audio is still late by the ASIO buffer size when punch is enabled. EDIT: When loop-recording with punch enabled, compensation of all takes is correct, and loop recording alone is also good. Only punch alone still has an issue.

A Fermata is usually a pause of all instruments, and only requires a single, lower tempo to the achieve the desired pause. Any changes to individual notes within that pause can and should be done with duration. Excessively dense tempo changes can cause problems with FX processing, and other playback anomalies. Give me any sample project and I can reduce the tempo map to have no more than one, fixed tempo per note start that will be indistinguishable on playback from the one with curves and nodes between note starts. I generally perform tempo variations in real time rather than drawing them, but I did enough editing in the old tempo view to know that it was quite awkward because you couldn't drag or 'sculpt' existing tempo changes; you either had to re-draw them completely, or painstakingly click above or below a tempo with snap enabled at the correct resolution to prevent inserting a new one, or manually edit values in the list. The new envelope implementation should be much more user-friendly for this purpose once you get used to it.

You had me going there for a minute, @Noel Borthwick, but I tested and then checked the flow chart to confirm: Hardware Inputs come in after Input Gain. Only inputs from audio clips and soft synths are affected by Gain.

Late to the party. For future reference: Select the clip. Edit > Select by Filter (uses the same filter dialog as Find) Shift+Drag the selected controllers back to the original track with Drag and Drop mode set to 'Blend'.

M:B:T time 1:01:000 is locked to SMTPE 00:00:00:00 in Cakewalk, and cannot be changed. If the song starts with a partial measure of "pick-up" notes, then the first downbeat will have to start on 2:01:000. For this and other reasons, I do not find automatic tempo detection to be very useful. I've posted versions if the following manual procedure using Set measure/Beat At Now (Shift+M) many times, and still find it give the most predictable and precise results. Easier to do than to describe: Note that this was originally aimed at aligning the timeline to a MIDI clip, but tabbing to transients in an audio track works the same as tabbing to MIDI events, and it's not necessary to show transient markers in order for the tab function to work; just read the word 'event' as 'transient'. In some cases, you might want to tweak the Now time position if the transient marker is not accurately placed. The main thing to understand is that Set Measure/Beat At Now is basically telling SONAR to set the previous tempo to make the specified Measure and Beat of the timeline fall on the absolute time at the current Now cursor location: the playback of audio is not affected, and MIDI event start times and durations are adjusted automatically so that they also play back with the same timing rather than following the tempo changes. You're effectively stretching/compressing the timeline to fit the existing playback timing. 1. Trim and drag the clip to align the first event wherever it should be in the timeline. 2. If that time is not 1:01:000, use Set Measure/Beat At Now (Shift+M) to "pin" that first beat so that it becomes the reference point for determining tempo. 3. Count out several measures listening to the clip (or go to the last event if the clip is short) set the Now time at the beginning of that event by tabbing to it, and use Shift+M again to set the correct measure and beat in the timeline to the absolute time of that event (i.e. "Now".) 4. Cakewalk will alter the tempo at 1:01:000 (or the first point you "pinned") to make the timeline match the clip without altering the playback timing of the clip (or any other clip in the project), and add a matching tempo value at the beat you set to serve as a reference for setting subsequent beats. 5. If the clip was recorded to a click, and/or was quantized, that may be all you need to do; if not, you can set additional beats every few measures or every measure, or even within measures or beats (note that fractional beats are entered as decimal values not ticks, so 02:480 is 2.5). 6. If the clip didn't start at 1:01:000, go to the tempo track, and change the tempo at 1:01:000 to match the first tempo SONAR inserted (this gets trickier in a project with mixed MIDI and audio) That's about it. For a very long clip, I recommend setting the first point at 8 measures or so to see what beat the last event should fall on. Then undo the 8-measure 'Set' , and set that last event to establish an overall average tempo, and roughly align the whole clip so that it's easy to see what beats other events should fall on in the middle of the clip, and decided how many you need to snap to tighten up the timeline match. Setting the first 8 measures is just an interim step to figure out how long the clip is without listening and counting 100+ measures or whatever it is.