sreams

This is good stuff... but a bit unnerving that almost every tempo change does not occur right on a beat.

It's not complicated at all. One pass and you are done. I guess I could see it not going so smoothly for those who have no MIDI input device. You mentioned lag. What is your ASIO latency in Preferences? Did you try using a smaller buffer size?

I don't think he is looking to alter the audio at all. Looks more like he wants to create a tempo map that matches the existing audio. "Fit Improvisation" in the Process menu is what you'd want if that is your goal. Create a MIDI track, use a MIDI controller to tap out the tempo as you listen to the audio. Then use "Fit Improvisation" and the Tempo Map will be created matching your input. *Way* easier than doing it all by hand.

Ah... thanks. That makes sense. I did try moving the patch change to a later time (1:01:003), but it still does this in that case. Wouldn't that be a situation where the .mid file is no longer consistent with the .cwp file? The patch change would not be sent at the same time in both files... and I would want it sent at the specific time I set it to.

I'm noticing this consistent behavior today. I have multiple projects that have a MIDI track setup with patch changes only. If I export this track to a Standard MIDI file (or drag the clip onto the desktop), the first patch change is not included. If I duplicate the first patch change first (so that there are two of the same patch changes at the exact same time), the export includes only one of them (this is my sort-of workaround for the moment). I've attached the .cwp file as well as the .mid file that is generated by an export. OFAWtest.cwp OFAWtest.mid

Update on this... I contacted AMD support and they have been of little help. I've received two responses from them which suggest they aren't really reading what I've written them - directing me to use manufacturer supplied drivers when I've been very clear (twice) that I have been, and that the issue is the same using drivers from both ASUS and AMD. ASUS, on the other hand, has been more responsive. They've requested a video showing the problem. Thought I'd post it here as well so you guys can see what is happening:

As someone who sets up systems for users of varying experience levels... I can't say that I agree. Hiding the mix controls in the Track View means new users are now hunting for the faders that go with the clips they are working with. When the Fader/Pan/Mute/Solo/RecordEnable are right there on the screen next to the data (and not buried in lower control rows so that they disappear when tracks are minimized), it is a lot easier for me to get new users started. With the Track Inspector, I need to teach them to click on a track first in order to make its fader visible. Hiding controls encourages users to open multiple views at once to do basic things like mixing and editing. This can become cumbersome, especially on systems with 1080p displays, and especially when users start getting into things that actually require other views to be opened. As for me personally... I find that the only time I actually need the Console View (because the Track View is so capable and intuitive once its functionality is enabled) is when I need to copy a track EQ from one track to another. I think that may be the only thing that can't be done without the Console View. Otherwise, I keep it closed so that I have a lot more screen-space for views I really need.

Yeah... for me, the issue with the Track Inspector is that I can only see one track's fader at a time. No relative fader positions are shown. I will often select three or four tracks at a time and use Ctrl to move their faders together. Not having visual feedback on all of the faders that are being moved is not good. The Inspector also requires an extra click while mixing (must select the track before moving its fader). When adjusting the mix for a drum kit with 10-12 tracks, this is a big slowdown. Select track... move fader... select track... move fader... etc. I think the Track Inspector and Console View are invaluable tools, but not at the expense of what I find to be the most fluid and intuitive way to edit/mix: the Track View.

One thing I've always thought makes Cakewalk more difficult to use out of the box for some is the default preference where the Track View shows only some controls. The first thing I do with any system I setup is save the normal template with Track Controls set to "All". I then move the MSR/Volume/Pan controls to the top of each type of track so that they are all accessible even when tracks are minimized. Once you do that, almost everything is right there in front of you to edit and mix, even with the Track Inspector and Console View closed. I also prefer it because it means the fader/pan/mute/etc for a given set of clips is always directly to the left of those clips. No need to hunt for the faders for tracks you've been editing or automating. They are always visually in-line with the data.

I like using the Input Gain control on the Master bus. This allows for the output of any mastering dynamics plugin to still deliver the same output level. As an example... using Waves L2 and setting the Out Ceiling to -1db... your peaks will still be limited to -1db.

Yes... but if your mono tracks with mono interleave are routed to a bus, that bus is stereo (unless you also changed the bus interleave). So the routing is from mono to stereo... and then the L/R from the bus output is merged/summed to mono again for the export.

Update: Haven't seen any responses to my bug reports, but I did gather a bit more info on the issue. I am seeing the same DPC latency spikes when moving the mouse cursor into the text entry field in Notepad. Also... the problem goes away completely after switching from the Radeon driver to the Microsoft Basic Display Adapter driver. It has it's own issues, however (consistently high DPC execution time in wdf01000.sys)... but the problem with text fields is gone. So this really seems to be an issue with the AMD Radeon driver. I really want to use this notebook for live performance, so hoping I can make some headway with AMD.

I'd suggest doing as Noel suggested and disabling that plugin to see if it solves the issue. Maybe also try another non-legacy compressor just as a test to see if the problem persists. If it turns out to be caused by a legacy plugin, you likely just have to be happy with however it is acting.

Okay. Bug report sent to AMD (using the bug report tool in the Radeon software) and to the Microsoft feedback channel.

Good call. After moving the mouse over track name fields, LatencyMon immediately shows a nearly 1000 microsecond spike in dxgkrnl.sys. Otherwise, I'm seeing maximum DPC routine execution times of about 100 microseconds. Update: Also seeing the same spike when moving the mouse over the numerical text-entry fields above the faders in my Behringer X Air Edit software (with Cakewalk closed). Anybody have a modern Radeon graphics card or integrated Radeon graphics and willing to test for similar DPC latency behavior?