David Baay

Apply an appropriate Drum Map to the output of the MIDI track and you will be able to mute/solo individual kit pieces as well as having them named in the PRV's drum pane.

I use them mostly when recording the first few passes of a new piano improvisation as MIDI. Unless I've already played through it many times before I decide to record it, I tend to hit a lot clams or improperly voiced chords and go down blind alleys (or too well-trodden paths) of harmonic progression, and may still be working out rhythms while (hopefully) capturing moments of inspiration and 'happy accidents'. As mentioened, I always have Create New Lane enabled in record options and usually also Sound on Sound at his point. After recording 16-64 bars of that 1st take and saving it (with 'Raw' or '1st Take' in the title), I'll typically do one of two things: If it was a fairly solid take, I'll record a rough melody/lead over the 'groove' into a new lane, and I'll often do several of those, stopping, rewinding, muting the previous clip and recording another melody or harmony take into another lane. If the initial 'groove' recording is too rough for that, I'll mute that take and do another one, maybe practicing a bit in between to be able to play things I liked from the first take more smoothly. If a take is really bad/useless, I'll undo and re-record, but if it has anything potentially useful in it, I'll keep the lane and just mute the clip. Occasionally I'll do some some loop-recording of melodies/leads to get down a lot of ideas quickly but more often I just stop and rewind for each take or work with a 'groove' take that's long enough (either by recording or copy-pasting) for me to improvise for many bars. I generally do all of this without a click, just playing freely. Somtimes my playing is pretty metronomic all by itself, but some pieces lend themselves to a deliberately free tempo. At some point, I'll re-save the 'Raw' project the way it is and start snapping the timeline to the MIDI, using Set Measure/Beat at Now, so I can start editing, quantizing and maybe smoothing out the tempo variations, re-saving periodically with a suffix like "Snapped thru 17;01, Quantized thru 8;03" (semicolons because colons aren't allowed in file names). Once I have the timing nominally tightened up, I'll often go back and re-record a more structured melody/harmony into a new lane with better timing (because the tempo is flattened and the groove is partially quantized), borrowing themes and riffs from the earlier takes - basically comping by re-recording. Bottom line: I don't generally use lanes for 'comping' in the classic sense, more as a sort of warehouse for alternative takes and ideas and for quickly layering melodies and harmonies over a 'groove' at the composition stage. I develop and polish pieces mostly by re-recording, just using those early takes as a reference rather than copy-pasting and comping a finished track from bits and pieces of different lanes. Eventually melodies and harmonies will often be re-recorded on new tracks with a different instruments, but I may keep the piano melody to play in unison with the new instrument(s). I may do the same to record a bass line on piano, but more often I'll fire up a dedicated bass track for that. In any case, I almost never completely discard those early takes; I'll just save the project with a descriptive suffix in the name and clear out unused takes from the new version or maybe archive them in a hidden track if there's still a chance I'll want to use them later. I often use lanes to build up initial drum tracks in the same way on a single Instrument track before they get moved to dedicated per-output Instrument tracks later on for mixing.

I don't think there's any 100% predictable or easily controllable behavior. Pretty clearly developers did not consciously address how the PRV would interract with lanes when manually entering new events, and some enhancement will be needed to give users positive control. Ideally you would be able to clearly identify and specify the target lane from within the PRV.

Ignoring for the moment your impression that the direct-monitoring sound has changed, if there's a radical difference between monitoring and playback - other than the (significant) factor that some room and 'in-head' sound will be heard while recording - it could be in the project configuration. If this is happening in projects all started from some custom template, possibly that template has changed. Do you hear the same difference recording and playing back in a new project from the Basic template with no backing tracks?

Usually T1 in my experience, but can vary depending on the editing history of the track. The workaround is to move any clips out of that lane to the new lane and let CW put the new notes where it wants. I'm pretty sure I reported this issue in the distant past but haven't been persistently bothered by it since I record most of my MIDI in real time with Create New Lane always enabled.

If the new note is more than ~5 beats past the end of the previous event, a new clip will be created. This can be avoided by dragging the boundary of the clip later before drawing/pasting new notes.

Thanks for the explanation. I'd still be interested in checking it out.

I suggest you run MemTest86 and see if any errors are found. In case you're wondering about the different versions available in different places - as I was - check out this article: https://en.wikipedia.org/wiki/MemTest86

If the sends aren't being returned, you don't need to use an External Insert. You can just remove the EI and send form the Aux directly to the ouputs that you had assigned to the EI. And there's nothing to be compensated because all tracks/auxes/buses are subject to the same outbound ASIO latency of the interface and nothing else, unless ther are plugins that require delay compensation. If there's still a sync error, it's likely related to some PDC issue. Are you using any plugins in the project that you know require compensation? If you can share the project, I'd be interested in checking out the routing and sync on my system.

External Insert has an automatic delay compensationn mechanism. It needs to be set by clicking the button under 'Delay' after assigning the send/return channels. Sonar measures the actual round-trip delay by sending out a transient and measuring how long it takes to return and usually does not need an additional manual offset. When the external device is analog, this delay is just the RTL of your interface's A/D/A converison plus an ASIO buffer each way. It should not matter whether the EI is on a track, an aux or a bus so long as its delay compensation is correct. I should add that this delay compensation works the same as PDC for plugins with lookahead buffers; the tracks that aren't going through the external insert have to be delayed by the calculated amount to sync up with the delayed return signal of the tracks that do.

You can use the forced output channel of each track so you don't need to be concerned about the embedded channel of the recorded/sequenced/drawn MIDI events. The alternative is to get Sonar and use the Absolute Time Offset option in its Articulation Map implementation to change the offset in the region where a particular articulation is used. This is why the absolute time offset in Sonar was originally implemented as an Articulation type rather than a whole-track offset.

Yes, that's a classic use case. Historically the multiple synths would have been hardware synths - and probably different ones - but it's equally applicable to multiple instances of the same non-multi-timbral soft synth. I love making Sonar (and other softwares) bend to my will which is why I actually relish challenges like this. Sonar can do all kinds of coos things that may never have been specifically envisioned by the developers. The complexity may stymie new users on occasion but it can do magic in the hands of an experienced user. With complexity comes power and flexibility. That's going to be difficult unless the synth instances can be be configured to respond to only one channel so you can channelize the program change messages in the event list which is the only way to differentiate them. But then you'd have to channelize the note events as well which would defeat the purpose of being able to sequence MIDI freely in a single track without thinking about which synth is going to respond. And if you channelize the drum map, you'll just be back to sending all four program change messages to each synth on their respective channels. If it were me, I would use CodeFN42's MIDChFilter VST to distribute note events from a single drum-mapped MIDI track to the 4 instrument tracks, and use the Patch widget (or program change events if necessary) on the each Instrument track to set the patch. The Instrument tracks will also give you a place to do individual automations, velocity offsets, etc.

Only if one path is subject to the delay of a PDC-inducing plugin that the other one isn't, andCW does handle that case correctly in my experience. Aux tracks themselves do not introduce any extra delay. Are you seeing/hearing a problem? If so, what's the setup?

Not at my P.C. but I believe you can save new patterns as .PTN files. Have you checked the Ref. Guide? Should be in there.

I have sometimes experienced that it shows no progress and never proceeds to offer me the Install option but has in fact downloaded the file to Downloads\Cakewalk, and I can run it from there.

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.