David Baay

Yeah, I didn't want to get too far into the weeds, but I maintain a set of content folders separate from what Cakewalk installs, and the Drum Maps folder contains only maps that I actually use.

I understood what you were doing, but was concerned that someone finding this post might take it to be a tutorial on the standard operating procedure for invoking a drum map. The introduction suggested that the first step is to open the Drum Map Manager, and I suspect that's exactly how a lot of users get into trouble. I'm saying, "Don't open the Manager unless you have to". If you just use the Output assignment of the track to pick an exisiting map directly, there's no chance of invoking an empty map, and it will just work with no fuss most of the time.

FWIW. I don't have the FX plugins but downloaded the trial of Spire, and found the project behaves pretty much identically in CbB and Sonar. It ran pretty cleanly in both at 96 samples in ASIO mode (Roland Duo-Capture EX) on my I7-11800H laptop with Engine Load peaking at around 60% and exactly two late buffers per iteration of the loop - one at Note On and one at Note Off. Staggering the start times of the identical clips in the 54 tracks cured that. Switching to WASAPI-Exclusive, CbB played with a lot of distortion at 132 samples (3ms @ 44.1 kHz) using the Roland interface, but at least did not drop out. Using the onboard Realtek for output in WASAPI-Exclusive mode at 3ms, I could not even get the engine to start in CbB. I had to raise the buffer to something on the order of 18ms to get it playing with an Engine Load comparable to ASIO, and even then it was having audible hiccups with Engine Load spikes. Seeing this, I didn't bother trying Sonar in WASAPI mode. Conclusion 1: Sonar's performance seems equal to CbB in this particular project scenario in ASIO mode. Conclusion 2: WASAPI just doesn't have the towing capacity to pull this kind of load, especially using onboard Realtek for output.

Two other possibilities I can think of: - Can be related to MIDI/Audio driver initialization issues; try starting Sonar with your interface offline to check that. - Remove any large Zip/Archive files from your Desktop or Cakewalk-related paths.

This is all more or less useful stuff to know about how the Drum Map Manager works, but the steps are kind of a recipe for how not to do things. In order to use an existing/built-in map with a known drum synth, all you should have to do is: - Add the synth with an associated MIDI track (or as one or more Instrument tracks). - Click the Ouput selector of the MIDI track (on the MIDI tab of the Inspector for Instrument tracks), choose New Drum Map, and select the relevant map. You can use quick-grouping to assign the Ouputs of all Instrument-per-Output tracks in one go if applicable. - Double-click in the clips pane of the MIDI/Instrument track to open the PRV. - It should open with the Drum Pane and kit piece names showing. - Click a kit piece name and you should hear it; only if this isn't working for some reason do you need to go to the Drum Map Manager and modify the Output port and/or channel to match the synth. This should not be necessary most of the time. That's five steps, but only the second and third are the actual process of "adding" a drum map to a project and opening the Drum Pane. 90% of the time, it should be that simple.

Only nodes/inflection points appear in the list. What happens along the segment in between - the shape of the transition - will automatically move/change with the nodes that define its start and end. If you delete a node, the shape of the segment between the previous one and the next remaining one will take on the shape that previously existed after the deleted node. It should all work pretty transparently, but you might need to change segment types or add/restore nodes after deleting something, depending on the particular circumstances and the range you select. FWIW, I'll repeat something I've posted about many times: It's not musically meaningful to have the tempo changing in between the notes that define a time interval, and I generally recommend using jumps everywhere rather than lines and curves. Those lines and curves are being interpreted and rendered as a series of small jumps, anyway. I believe the default tempo change interval for rendering a "continuous" change in Cakewalk is a 16th note. If this doesn't explain the result you're getting, you should post a quick demo project file with the tempo track in question, and let us know what you're doing and what result you're expecting to get.

No, I was just responding to your post about unexpectedly silent tracks and thinking that if any part of a Drum Map wasn't working as expected, you might remove it without re-directing the track output first - a simple oversight that could lead to unexpected silence. Thought I'd mention it accordingly.

Yes, I understand. I used the shorthand "tempos" to mean either changes or nodes in the tempo track. Copy-paste should work as described in eith the tempo list or the tempo track without special procedures. Only if you're copying other content in some other view do you need to use Copy-Paste Special to ensure you include tempo changes. Bass Guitar is correct in referring you to the Ripple Edit All mode (upper right corner of the clips pane) for this purpose. Ripple Edit All will remove all content across all tracks including the tempo and arranger tracks, and pull the later/downstream content back to the start of the deleted range to fill the hole. The Ripple Edit Selection option will operate only on selected tracks.

Compare your AUD.INI files side by side to be sure. Do you still find Sonar does better with animations minimized? Try using the Pause button to invoke CPU Conservation Mode (limits UI updates to one per second).

When you select tempos in the tempo track or the tempo list in the Inspector, the tempo track is focused automatically, and tempo changes can be copy-pasted regardless of Copy/Paste Special settings.

Definitely not typical. Sonar is running at least as well as CbB on virtually all projects I've tried here, and better on some. I just had a go with Clean Audio Folder on a couple different projects, and it's fine as well. If you don't want to cut off your nose to spite your face and give up on all your experience with Cakewalk, I suggest you work with the forum and/or the Bakers to get it working in your environment. Start with the basics: Reset Configuration File (AUD.INI) to defaults; if it solves the performance problem compare the problamatic backup to the new default and/or CbB's to find the difference(s). For the Clean Audio crash, you'll probably do best to send a dump file to Support.

This could actually be related to problems you're having with drum maps in some cases. If you set a MIDI Output to a drum map and subsequently delete the map from the project (e.g. because it' not working as expected) without first deliberately reassigning the MIDI Output, there's no guarantee that it will re-route to the original synth. IIRC, it will default to the first available port, be it a hardware OUT or some other soft synth.

+1 A while back came up with a set of 20 brighter colors evenly distibuted across the ROYGBV spectrum that I would like to be able to set as both picker colors and as the defaults for new tracks. Right now there are only 5 default clip colors for new tracks that are repeated for tracks 6-10, 11-15, etc., and they don't exactly match the clip colors you get with any of the available track colors. FWIW, my simple scheme is to set the first track to Hue 0, Sat 181, Lum 144, and just increase the Hue value by 12 for each additional track. This makes track 20 Hue 228, Sat 181, Lum 144. In case you're wondering why only 20 colors when the picker has 24, the highest Hue value you can set is 239 which comes nearly full-circle to look just like Hue 0 with these Saturation and Luminence values. To get 24 colors you'd have to use a Hue step of only 10, and at that, the difference between adjacent colors starts becoming pretty subtle (as some of the existing picker colors are now), but you could to that.

Exporting to MP3? MP3 encoding will do that.

Looks like the primary effect is offsetting the knobs in their painted "bezels" and adding highlights and drop shadows so the they appear to be viewed and lit from slightly above center. Does look nice.

@Jeff Payne See this sticky post:

PM sent.

If you can't actually fix the bad switch or get a replacement, you may be able to swap a strip of membrane switches with a good one from a less often used upper or lower octave, and cut out the bad switch so it doesn't generate events at the new location.

I was just in the process of writing the following when you posted: My guess would be that your keyboard controller has a physical problem that's causing spurious Note events to be generated on that one key, possibly due to the slight vibraiton of the keybed when you release other keys. Does it happen when playing other ranges of the keyboard?

@King Burton Check how sends from tracks to buses are set up. By default Sonar does not mute prefader sends when a track is muted, either directly or by soloing some other track. So there can be situations where soloing a track mutes other tracks but not buses that have sends from those tracks. You can change this behavior by setting LinkPFSendMute to True in Preferences > Audio > Configuration File (or editing AUD.INI manually to set LinkPFSendMute=1).

Did this ever go anywhere? I've also seen "phantom" transients come and go in waveform drawing when zooming for years. It was never a huge deal for me, but it would be nice to have it eliminated as visual glitches of any kind detract from the overall user experience and confidence that WYSIWYG and vice versa.

Note that the External Insert UI has an "Offset" field. This is a manual offset that can add to or subtract from the measured Delay. If the processed signal is still coming in 9 samples late, entering +9 in the Offset field should take care of it.

Actually the word "Create" is not included; it's just "New Drum Map", and the idea is that you're adding a new map to the project that can contain multiple maps - just like adding a "new" track, folder, bus, marker, etc. It has to be applied to the Output because it's actually a realtime "mapper" that can rewrite note event numbers, channels and velocities on the fly and send them to different outputs according to input pitch, not just re-labling pitch names in the PRV. As designed, the drum pane depends on drum maps to work. I guess this boils down to a Feature Request to be able to add labels to the drum pane without invoking a drum map, but it may be that the mute/solo functions of the drum pane also depend on the map, and you might lose that; I don't know. All I know is that the existing impementation has always worked for me when I needed it with a minimum fuss and mystery. Maybe the problem is better addressed by determing exactly how the basic process falls down for you in particular situations (e.g. default output assignment, blank drum pane) and having the Bakers find ways to cure those particular issues. And possibly they could put a menu option in the PRV to "Add Drum Map" that opens the pick list and applies the selection to the output of the current track under the covers. I think this would be a better approach than adding a "labeling-only" feature.

When you open a .MID file, the first CC7 event in the first measure of each track is used to set the MIDI Volume widget in the track and is removed from the Event list. When you find/replace all the values, that Volume widget level remains unaltered, and when you re-save as MIDI, that value is written back to the file at the front of the event list. I don't believe there's an option to override this behavior. You just need to set the Volume widget in each track to the desired initial value before saving.

I'm not sure how this happened in your project, but I can't reproduce the doubling in a new step sequencer clip created from scratch. I think something must have happened in the editing process. So far as I can tell, the numerical range of the Flam control is just mis-documented and 1.0% to 50.0% is the intended range; in other words, the flammed sound can only be delayed - not advanced - relative to the initial hit which makes sense. In any case, Flam was not enabled on any of the hits so it shouldn't have any bearing.