David Baay

Still most likely a jittery control on the MPK and only coincidentally stopped when you rebooted because the MPK was powered down or the control was bumperd to a non-jittery position. I don't think there's any way for CW to be triggering this given the controls as not motorized. If you have a control assigned to CC73 in the AKAI's setup, try un-assigning it or assigning it to a different CC to confirm. Sometimes physically exercising controls can stop the jittering or they just need to be parked in a different position.

Can't repro that here.

Oops. Typing too fast, and don't know what possessed me to use forward slashes; recently typing URLs, I guess. I think he's still on CbB = Cakewalk Core.

Scroll tot he bottom of the Function list in the Global Bindings context and you will find a section labeled CAL Program Files.

Open Master.ins under %AppData/Roaming/Cakewalk/Sonar (or /Cakewalk Core for CbB in a text editor. Find Drum[*,*]=1 under the "[Yamaha Drum Kit]" (or similarly named) section and change it to Drum[*,*]=0. This flag is what tells CW to represent notes as diamonds in the PRV. Save the change and restart CW to have the .ins file re-read.

If you go to the Folders tab in Option > Global you can see all the paths. Default for CAL in S8 is Documents\Cakewalk\SONAR 8 Producer Edition\Sample Content

Options > Global > General tab, uncheck 'On Stop Rewind to Now Marker'. Using arrow keys to move the Now Time can be implemented using CAL. See post 23 in this thread on the old forum: http://forum.cakewalk.com/FindPost/1365944

Me too, but it's more about the burden and inconvenience of maintaing separate machines than financial limitations. If the DAW were my primary income source, I might think about isolating it, but then more for stability (as in unchanging) and security of the ecosystem than for performance. In my experience, significant audio performance degradation doesn't usually manifest as slow death by a thousand cuts of all the incidental software installed on a machine; it's usually all good until some single entity completely trashes it, like a new or updated plugin, driver, O/S component, hardware or configuration change or a problematic update to the DAW app itself. The thousand cuts might shave 10% off the ultimate performance capability of the machine in terms of a low and stable DPC latency and fast RAM/disk response that are the foundations of good, low-latency DAW performance, but they're not going to make or break the servicability of the system.

Possibly it's used by some of the old plugins or ancient dialogs that haven't been updated...?

I just Googled "has no bugs" site:discuss.cakewalk.com. I got two hits; one was yours and the other was "Please name one bit of complex software you own that has no bugs". On the old forum you get "As if Cubase has no bugs... LMFAO.." and "I swear this is probably the same cat dropping his Logic-has-no-bugs propaganda..." Regarding your issue, check the .txt file that was created along with the .dmp file for more info. If the crash is in the plugin I would send the dump to the plugin vendor first. If they find that the trigger is something non-standard that Sonar is doing, they can refer it to the Bakers themselves with details from their analysis.

Really? Seems unlikely that Noel was wrong or that he or anyone else would have found it necessary to squelch your evidence to the contrary without explanation. What people and what issues? I continue to see little or no difference between Sonar and CbB in my projects one way or the other either in audio or UI performance. When I run them at the limit (or a little above it with some crackling), I see different patterns of core loading in the Perf Module of the two apps but the audible result is essentially the same. The visual difference may be more more a function of how the Perf Module animation is rendered.

I'm not seeing that, either. FWIW, on my company Lenovo laptop I used to get slow mouse behavior when I had an MS Word doc with embedded images open in the background. Never figured out what that was about, just chalked it up to overall Stinkpad wonderfulness.

Just the usual... run LatencyMon and see what's causing DPC spikes - possibly your antivirus is still scanning and hogging bandwidth. https://www.resplendence.com/latencymon

Unless you're using Aux tracks, FX in a track FX bin will affect only that track while FX in a bus FX bin will affect all tracks that pass through the bus. If you aren't seeing FX bins in tracks, you might need to enable them via the Track Control Manager at the top of the tracks pane and/or by switching to the Advanced or 'None' Workspace from the default Basic if this is a new installation, or just drag the tracks pane wider to reveal them.

OP's issue was almost certainly plugin-related. Clicks and pops from empty buffers are usually more audible in louder passages and are more likely to occur in realtime playback than offline export, whereas a tick in a quiet passage would more likely be due to a spike from some kind of DSP error from a plugin misbehaving under fast/offline bouncing. What's your hypothesis?

I'm afraid you might be out of luck. A Project Template could save this configuration but you would lose MIDI tempo and other content when importing to a project started from the template rather than opening MIDI files as new projects. And I checked to see if Workspaces save this setting but it appears not.

I've not used this plugin before now to know how it behaved before the most recent Windows update. It doesn't appear to have any effect on my mouse pointer or UI reponsiveness in general, but it is a major CPU hog with an 8ms lookahead buffer that requires quadrupling my normal ASIO buffer to get smooth playback in even the simplest project that normally shows virtually no activity in the Perf Meter. The audio engine drops out immediately with a nasty glitch otherwise. Enabling Plugin Load Balancing also helps somewhat.

Your understanding of the issue is faulty. The issue is not with audio output; it's with MIDI input. Sock Monkey's understanding of the FP-30 and the need for a driver to be installed was also faulty, but he was not wrong in pointing out that your suggestion was irrelevant to getting MIDI input to work.

I tested every major version back to Sonar 7, and it appears the lowered magnetic strength/intensity has only ever applied to slip-editing clip boundaries and not to moving clips in the track view. This would be clearer if the documentation specifically mentioned slip-editing since moving a clip does move its boundary. In any case, like you, I find the behavior unexpected. IMHO, moving clips with reduced intensity should behave the same as moving notes and other events in the PRV. But at this point it's a feature request, as it was apparently never intended to work that way for clips.

Okay, I was able to repro issues attempting to snap the clip at bar 86 in track 12 to some of the clips in track 11. I haven't completely figured out what's going on, but deleting tracks 3-5 got it working. Seems to be some linkage/interaction there, but I'm not immediately seeing it.

Go to Device Manager and confirm you see the MIDI ports appearing disappearing from the Software Devices section when you connect/disconnect the FP-30 with the power on or when you power it on/off. If windows doesn't see them, the DAW won't, either. I don't think the FP-30 needs drivers for the USB-MIDI ports to work. It just needs to be powered up. Try a different USB port if available, and try booting your PC with the FP-30 already powered up or vice versa - powering up after booting.

Well this is interesting... I can't replicate either problem in this project. Clips are moving smoothly between other clip landmarks, and snapping to every candidate as expected everywhere I tried. EDIT: I take that back. Movement is still behaving like snap intensity is maxed, but I am able to hit every landmark so far. Keep in mind that it matters where you grab a clip. If you grab in the left haf, you're snapping the clip's start to landmarks, and if you grab in the right half, you're snapping the end. And if you grab a group, it's the start and end of the group that snaps.

I can't repro that problem; will need to see a project that does it.

Snapping clips to other clips isn't a common workflow for me but I just checked it out and am not seeing any problems. Can you link a simple project with steps to reproduce the issue? EDIT: That said, I do see what you mean about the intensity always being maxed. Lower intensity is working as expected for notes in the PRV, but not for clips in the track view. I usually have snap at or near maximum and just disable it completely when I want to make a fine adjustement, so hadn't really noticed.

To resize multiple/all track heights, select them and hold Shift while changing the height of one.