David Baay

I recalled this issue having come up in the past and found mentions on the old forum going back to at least 2012. Here's one from 2017 before the Gibson shutdown: http://forum.cakewalk.com/SONAR-Track-Soloing-Remote-Control-not-working-m3561832.aspx If it was working more recently, it may have regressed, but possibly there's some other contributing factor that can make it fail. The first thread I saw suggested that it could be intermittent and work for a time after re-learning.

That's interesting. I was actually trying to reproduce the issue earlier, coincidentally using Sonitus Reverb, and could not. How big is that transient in your screenshot? Looks way too big to be from "a tiny bit" of Sonitus Delay, but maybe the track scale is zoomed..?

What it doesn't show is that if you do a loopback recording of the MIDI, the re-recorded notes will actually be 10 ticks late in the 192PPQ timeline as expected. So bringing an old project into Sonar isn't really a problem unless you notice that the displayed offset has changed, and change it back to what is was on CbB. Then you'll actually get the wrong musical result. Bottom line: There is an issue to be fixed here, but it's a display issue.

That's just because the track isn't scaled properly in Sonar to show all the notes.

Try leaving the .wav extension off. Sonar will add it automatically. I haven't yet checked the thread that Amberwolf linked, but I don't get that when overwriting previous exports.

I believe the issue here is that the Always Stream..." option will only flush the buffers at the end of live playback. Fast/offline bouncing may not allow that to happen so there's still a non-empty buffer of audio waiting to be streamed or rendered to file when you next the start playback of do another bounce. I thought this had actually been addressed quite a while ago and haven't noticed it myself recently so wonder if it might be related to misbehavior of specific FX plugins that are not getting flushed...? Whatever the cause, one way to handle this on tracks is to freeze the track with some time included for the FX tails to play out in the Freeze Options. For bus FX, having a volume envelope that runs to the end of the FX tail (or overrides it) will do the trick. Since so much modern pop/rock music ends with a fade-out this usually happens automatically if the mastering and final fades are being done in Sonar, but if you're exporting stems or raw album tracks for mastering by a third party, that might not be the case.

That's not exactly what I'm seeing or saying. Sonar doesn't change the offset, musically, it just always references the entered/displayed value to 960PPQ. If the project originates in CbB, the displayed value will increase from whatever was entered by a factor of 960/x, where x is the PPQ setting of the CbB project. The actual absolute delay that results from that at any given tempo will be the same. If the project originates in Sonar, and you change the project clock, you have to continue to enter tick-based Time Offsets based on 960PPQ,

There is confusion here becase he shows swithing timebases for the Offset, but the thing to note is that the 10-tick offset in CbB becomes 50 ticks in Sonar. What was not mentioned is that the project clock is 192PPQ. When you open the 192PPQ project saved by CbB in Sonar, the offset value is re-referenced to 960PPQ and changes from 10/192 to 50/960. If you actually re-record the MIDI via loopback with no transmission delay in Sonar, events will correctly land 10 ticks later in the 192PPQ timeline, but theTime+ field is incorrectly showing 50 ticks. Sonar is not honoring the 192PPQ project setting when setting Time+ in ticks. A reported back in FogBugz days that this issue also applies to setting quantize and snap values in ticks when the project clock is something other than 960. To get the right musical interval, you need to keep thinking in terms of 960PPQ.

Yes, but that is the root of the problem. Sonar - and CbB before it - has many tick-based calculations hard-coded to 960 PPQ (e.g. quantize in ticks). CbB's TIme Offset correctly handles alternative PPQ settings but it appears this got broken when the absolute time offset feature was added to Sonar.

Hmmm... have not seen that. You're not seeing that in the filename field before you hit the Export button?

I still fire up the old hardware regularly, especially the Roland D-110 that was my first MIDI synth module and on which many pre-VST projects were based. I always thought I should learn to play a breath controller but never got to it, and would struggle to learn breath control at this late date I'm afraid. A lot of my projects have wind/brass accompaniment, and a lot of solo piano works could use some. Maybe we can do a little collaboration to help you re-acquaint yourself with Sonar. Here's an example (I've been told I need to give time for my soloist to breath 😜) : https://www.bandlab.com/post/89b09300-f6f9-e811-9f2a-00155d77cb96

Click the 'Advanced' radio button at the bottom of Preferences.

Go to Preferences > Project > Clock, and change Ticks per Quarter Note from 192 to 960.

You'll be back after you run into the first 20 things that DAW can't do - or does awkwardly - that you used every day in SONAR/Sonar. 😜

Couple quick thoughts on this: - After re-saving as a "Normal" .CWP (Cakewalk Project) file, go to Preferences > Project > Clock and change Ticks per Quarter to 960. - To fix the drum track, click the clip to select the whole thing, go to the Event Inspector module in the Control Bar and enter 120 (ticks) in the Duration field. This will change all the drum notes to be a 32nd duration (at 960 ppq which is a convenient length to be able to see them and differentiate them at all zoom levels and will take care of the one hyper-long event at the same time. As I'm sure you know, changing drum note durations has no audible effect because the entire sample is played as a 'one-shot' with no regard to the Note Off timing. - In addition to setting a fixed the drum note length, you might want to apply a drum map to the track by choosing New Drum Map from the Output pick list and selecting GM Drums (Complete Kit) so that the track displays in the drum pane of the PRV with kit piece names and individual mute/solo controls per drum.

This is absolutely impossible More commonly, if you have the shorter clip selected when you initiate the export, that selection becomes the default export length. For that and other reasons, it's best to hit Ctrl+Shift+A to de-select all before starting an export of an entire project. Before Start and End Markers were introduced, I generally used a punch or loop region to define the export range.

I have't seen that for a long time except for an issue that was fixed recently with the clip re-draw frequency during playback at high zoom levels causing the UI to become unresponsive. If it's just this one project, I would tend to suspect some plugin is causing the problem. Based on the track numbers in your screenshot, it looks like your synth count might be pretty high. If it's from a template with a lot of unused instruments, I would try 'Disconnecting' them in the Synth Rack until needed.

Let's make that @Matthaeus Ebonah, the OP.

Is it just the length issue, or you're also not getting all tracks? Sonar has Start and End Markers that earlier version didn't have, but they have to be set deliberately and can be over-ridden in the export dialog.

Is export working as expected in CbB? How about selecting nothing and exporting only the Maste bus?

With the Track Control Manager at the top of the Tracks pane set to show 'All' controls, set the C widget to force a specific output Channel for each MIDI track . Or hit "I" to show the Inspector and do it there. https://legacy.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Playback.20.html

- Go to Preferences > Audio > Playback and Recording and set Driver Mode to WASAPI (Exclusive if you want best performance from Cakewalk or Shared if you want to be able to play audio from your browser or other apps at the same time). - On the Drivers page, uncheck the Magix driver if you see it there, and check the boxes for your onboard audio Headphone/Speaker output and Mic/Line input.

What does the dump .txt file way the crash is ocurring? Have you cranked up the Error Handling Severity at some point? I don't think you would normally see this error reported (bold part is my doing): Enhanced error detection is now integrated into the DAW. This feature is opt-in for now and may be enabled by adding the ExceptionHandlingSeverity value to the Cakewalk.ini initialization file. We appreciate users helping make Cakewalk better by reporting crashes to us as well as plug-in vendors when necessary. To control the error detection sensitivity, you can now add a new ExceptionHandlingSeverity value in Preferences > File - Initialization File. Valid values for this setting are: 1 - Unhandled errors are caught (default) 3 - All access violations are detected and unhandled exceptions are caught 5 - Unhandled errors and heap corruption is detected 7 - Unhandled errors, all access violations and heap corruption errors are caught (this is the strictest error detection mode)

No, MIDI clips allow automating only Velocity Offset with an envelope. I'm not exactly sure why this limitation is imposed, but suspect because MIDI controllers are channel messages affecting the sound of all notes sent on the same channel so it makes some sense to allow only one track-level controller envelope in a world where it's unusual to have events of different channels on the same track. But that does make it harder to keep automation and clips locked together when editing and using features like Groove Clip Looping. I can only suggest you just use actual controller events in the clip rather than envelopes.

Based on automation line crossing empty space before the clip, it’s a track envelope, not a clip envelope.