David Baay

See this post:

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.

I don't think he's talking about a performance problem. The way I read it, he's saying new AAS instances simply aren't created. I just tried several instances of Lounge Lizard and Ultra Analogue and could not reproduce a problem.

I will give it a shot. Can you confirm this was working reliably in a previous release? EDIT: Working as expected here. What procedure are you using, and is it just tracks are not being created, or also no new instance in the Synth Rack?

This can happen if you've previously enabled Copy-Pasting tempo changes in the Copy-Paste Special dialogs, and are dropping the clip at a different time. This is not new, just maybe more obvious because it's so easy to leave the tempo track showing all the time. Check your copy-paste settings, and also the state of 'Use Paste Special Options on Paste' under Preferences > Editing. Depending on your workflow, you may want to disable that.

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.

Thanks for all the info, Mark. That's very helpful. I see now that based on this, if you have redundant tempo entries and 'Set' a later point, the redundant entries get deleted which shouldn't be of any consequence in most cases. I'll have to play around and see if there's any real-world scenario where it's actually problematic.

Hi Mark, can you expand on this? How exactly do they differ? In particular, I would expect the lists to be the same, and the envelope to be the same as the old 'chart' view - at least so long as the changes are all jumps.

Thanks for the clarification. i see the problem now. I had not noticed there was a tempo at 15:04 before you set 18:01. I have not seen this issue - possibly because I've only been setting whole measures recently. I'll have to try setting some beats around measures and see if I can reproduce it.

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.

I know SM/BAN inside and out, but do not understand what either the documentation or you mean by "create" or "add" new bars or beats. The sentence after the one you highlighted more accurately describes what it does. Nothing is created except tempo changes, and those changes result in existing bar and beat lines moving relative the absolute timing of audio transients or MIDI events to align the timeline to the performance. The same dialog does let you change the time signature of a measure, which can effectively 'add' beats to a measure, but that's a separate operation from 'Setting' a measure or beat to Now. And so far as i know, that also works as it always has. If this isn't just a misunderstanding of the awkwardly-worded documentation, I'll need a specific example of what you're trying to accomplish in order to understand whether something is not working as it always has.

I don't really understand what you're saying here, but what you showed in your original post is working as designed, and as it always has. Cakewalk modifies the most recent tempo to make the specified beat land on the current Now cursor position, and inserts a matching tempo at the point to serve as a reference point for the next Set.

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.