David Baay

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.

Those velocity settings are working here; the snares at beats 4 and 8 are inaudible over the tambourine hits on the same beats. But I noticed when muting the tambourine row to better hear the soft snares that the tambourine just became a little quieter (Dim Solo disengaged). So I bounced the SS clip to a regular MIDI clip, and found that both the tambourine hits and snare hits were duplicated - two events with the same timing and velocity for each. Did these clips start out as MIDI clips converted to Setep Sequencer clips or were they SS clips from the get-go? As I said, the velocity settings seemed to be working here, but if there is underlying duplication of hits, that might interfere with the velocity response. I suggest you bounce to clips, remove the duplicate hits and convert back to SS. P.S. I thought this might be related to the Flam control. It was centered which should be 0.0, but was showing 25.0 and goes from 1.0 to 50.0 instead of -50.0 to +50.0 as the documentation says it should. Also, when I double-clicked it to re-center, it defaulted to 25.5 instead of 25.0, adding to my suspicion that it's not behaving correctly.

The main difference with CW is that the "button" for setting maps is the Output widget of the MIDI track (or MIDI tab of an Instrument track). You can't get to it from the PRV so it's not as intuitive, but the procedure is no more complicated if you have the Inspector showing. This where CW's track templates come in. Again, different, but equally simple after you've done the initial setup and saved the template - or acquired one that someone else created. As mentioned, I've always recorded drum parts in real time from the keyboard, and having a map in the PRV doesn't really facilitate that, which is why I don't use them all the time. But I've been at this game long enough that I've had quite a bit of experience even with features I don't use frequently. For me the usefulness of drum maps is more in their ability to map different keys to different instruments/channels and to allow muting/soloing individual notes in the PRV. I more often use them for atypical purposes like routing different note ranges to the different horns by channel in a multitimbral synth when composing for a horn section or blocking the passage of notes that don't correspond to the pitches available in a physical music box or tongue drum so that I don't compose something it can't play. I wouldn't have as much use for a "map" that just shows names without offering actual "mapping" functions.

I also use the PRV, and generally don't need to reference kit piece names. Since I mostly play the drums in from the keyboard in real time, I learn the mapping by feel and have a limited amount of editing to do after the fact. If it's not obvious what's what from the pattern of notes and my memory of where they are on the keyboard, a quick click on a note or swipe of the PRV keyboard tells me what/where a kit piece is. That said. I just loaded the AD2 drum map and did not have any issues; just make sure to have the instrument loaded before instantiating the map in order for the output port to default correctly. The page where the map is shared also has project and track templates that will take care of the output assignments and speed the setup of multitrack outputs: https://legacy.cakewalk.com/Support/Knowledge-Base/2007013364/Setting-up-a-Drum-Map-for-Addictive-Drums-2-in-SONAR No doubt Sonar's implementation of drum maps is a bit antiquated, not very intuitive, and can be awkward in a number of ways, but I've never found it to be so bad that it's actually frustrating. Like a lot of MIDI-related processes, it can be tedious, but no more than that.

A simple project with a virtual instrument and no audio tracks should be small enough to link to a post. If you don't want ot share it that widely, you can PM me the file or share it via OneDrive or some other sharing service.

Maybe share that project with just the offending track to see if the problem is reproducible for others. I don't use Step Sequencer that much but have not had issues like that in the past. I would not expect a problem with track mute/unmute to be related to the SS content. Possibly these issues are related to the instrument it's driving; is it SI Drums?

It's possible to see notes in both the drum and notes panes simultaneously, but only while the drum track has focus in the PRV. As soon as you focus something in the Notes pane to edit it, the drum pane will go blank because the PRV is using the output assignment of the focused track to determine where to send the auditioning output. I suppose the developers could jump through some hoops to preserve the visual display of the drum map in this scenario; it just wasn't in the design requirements and probalby wasn't noticed or realized that this might be useful.

What part of "This is not a workaround" didn't you understand? A workaround is a way of overcoming a bonafide software defect or a significant omission in functionality. Moreover a workaround is typically awkward, requires more steps to accomplish and/or yields a result that is not completely satisfactory. None of that is the case here. In fact your "solution" is arguably more awkward, requiring that you enable/disable snap or use modifiers, depending on the situation, that you drag and drop the node with sufficient precision to ensure that it snaps to the correct target, and potentially has an unsatisfactory result (duplicate nodes) unless programmers add logic to eliminate it... oh, wait, that would be just like deleting it in the first place! P.S. If you want to have a discussion about which of us has contributed more to the development and success of Cakewalk and its user community, come back in 30 years and we'll compare notes.

As pointed out, all you need to do is delete the redundant node and (if necessary) change the segment type to something other than Jump. This is not a workaround; this it how it's intended to be used. Creating a new type of snap object to facilitate stacking redundant nodes is not a feature anyone should support.

Personally, I almost always check context menus first when using new software, but I agree Split should be in the Clips menu along with Bounce to Clip(s) which I use frequently enough that I have it in the Custom module.

I quickly got over being distracted by them but am generally in agreement that they add unnecessary clutter to the UI.

I agree, just remove the drum map assignment and do it all in the PRV with both tracks showing. For a simple drum pattern like that, it's generally pretty obvious which rows are kicks and snares without having the drum map labels. Alternatively, you could copy the drums to a lane of the Bass track, mute the clips, and disable Hide Muted Clips in the PRV View menu. This will give you grayed-out drum notes in the Bass track as a timing reference. Or, better yet, play it all in live from a MIDI keyboard to get a natural interplay of drum and bass rhythms. ;^) Time spent learning to play in real time is more productive, more fun and yields better-sounding music than drawing notes with a mouse.