David Baay

I have no familiarity with Opus, but it sounds like Opus is echoing MIDI input to a virtual Out, and your track Input is set to All Inputs. Set the Input of the track to the specific port and channel your keyboard is sending on, and disable MIDI Out from Opus if you're not using it.

I did a quick test, and could not repro the 'soundless note' problem with either input-monitored hardware or a soft synth with an arp and input quantizing enabled. A couple other things I thought of that could have a bearing; - Are there any MIDI FX plugins in the project? - Do you have a non-zero 'Timing Offset' entered under Audio > Sync and Caching?

The purpose of punch recording is to ignore input before and after the punch points, so that's expected. Personally, I would just record the MIDI in a new lane in sound-on-sound mode without punch in and edit as necessary at the overlap point. As for a note played after the punch point not sounding.... - Does it happen with either or both the arp and input quantizing disabled? - What project tempo, time signature and quantize setting? - Is the sound source a soft synth, or input-monitored hardware? - If a soft synth, can you reproduce it with some Cakewalk-bundled synth? - Does it matter how close the the first note is to the punch-in point? - How long is the punch range? - What interface, driver mode, and buffer setting?

The only crash I have ever had with CWAF was related to having a project folder nested within another project folder. It was a long time ago so I don't remember the exact situation, but IIRC, I found it by watching the status bar at the bottom of CWAF to see what folder it was scanning when it crashed. It may also help to exclude as many non-project-related folders as possible. Here's a post about how I set it up and use it:

IIRC, I have had to go into metronome preferences and enable the Audio metronome to get .WRK files playing in the past.

Did you just switch to the floating track view to show the effect of switching to the Preferences dialog? Does the problem persist if you maximize the track window? Also, is CbB referencing the same driver as X3 for Playback Timing Master in Preferences > Audio > Driver Settings?

Can result from having 'Remove DC Offset' enabled in Audio > Playback and Recording preferences.

I discovered a while back that if CbB's Media Browser is defaulting to a path that includes large .ZIP files (even upstream of the directory to which its pointing), it can slow the program launch. If this is the cause in your case, you may need to move those archive files to a different path or change where Media Browser is looking for content.

The messages themselves don't carry port information. There is no 'incoming port' value that you can 'retransmit' or map to some other port. What you're wanting to do cannot be done without extending the message format beyond the MIDI 1.0 spec. For the time being, you will have to use multiple tracks outputting to separate drum maps in order to route CCs to specific ports/instruments.

So basically what's needed in this case is a 'Pass-thru' option for Channel that just passes events without altering their embedded channel. I'm thinking that actually should not be that challenging to implement. The alternative would having a drum map with 128 x16 = 2048 rows (!) to handle explicit mapping all possible combinations of input note number and channel. 🤪

If a drum map is still in place that outputs to the synth, it won't be deleted.

Not sure there's an answer here, but there's a long discussion with additional links and info: https://www.steinberg.net/forums/viewtopic.php?t=103828 Coincidentally, it specifically mentions Lynx having issues with it.

It's an inherent imitation of the MIDI 1.0 message types. Note On messages can be differentiated (and routed) by their note numbers. CC messages don't have that; there's nothing to 'tell' the drum map that a given CC is associated with a given note number. Getting that capability will require imlementing something like Steinberg's proprietary 'Note Expression' or MIDI 2.0's 'Polyphonic Expression', and will require completely re-architecting Cakewalk's MIDI engine.

+1, although that should affect all DAW apps running on the same machine equally. Another random thought: Having Steinberg Cubase 'Generic Low Latency ASIO Driver' installed can cause these symptoms.

Back when dinosaurs roamed the home studio, Go to From was bound to F7. That binding was discarded in X1, but the function still exists, along with similarly handy functions: Go to Thru, From=Now, From=Start, Thru=Now, and Thru=End (formerly F8, F9, Ctrl+F9, F10 and Ctrl+F10, respectively). I could not live without these and restored them with custom bindings.

Any chance you enabled the non-default 'aggressive' ThreadSchedulingModel=3 in AUD.INI (Preferences > Audio > Config File) despite warnings that it's experimental? Many who have tried it had a result like you describe, and many of those promptly forgot they had made the change and blamed the update... as usual. ;^)

There might be a bit of a learning curve related to default keybindings that have been altered or disabled (e.g. 'O' to toggle Envelope/Offset mode), and changes in modifier keys and hotspots to get different tool behaviors, and features that didn't exist previously like Ripple Edit and Workspaces. In particular, I recommend setting Workspaces to 'None' in the upper right corner of the UI until and unless you decide to use them.

Depending on the project configuration and how the bus and insert are being used, you might try outputting the bus to an Aux track that outputs to the downstream, bus, moving the insert to that Aux track, and using the track's solo. Or just re-route the source tracks from the bus directly to the Aux track with the insert, and use that Aux in place of the bus. Otherwise, the only solution is to not use external inserts on buses in a persistent way. Dial in the sound you want, bounce the bus output to a track, and remove or mute the bus. If you can get enough noise going on a thread in the Feedback forum, maybe you can get the Bakers to fix it finally.

Yes 'Stereo Mix' is the output of the soundcard. You need to be recording from the input by setting the source to Line In. I gather ARIA is the name of the wavetable synth in your soundcard, not referring to Garritan Aria Player plugin. Wavetable synths are generally not usable in Cakewalk anyway due to latency issues. You'll want to get a good orchestral VSTi.

Routing notes to different physical or virtual ports should not be a probem; I have done it frequently in the past. Just make sure you're routing the right 'Out Notes' to the right ports with the correct re-mapping from 'In Note' to ' Out Note', keeping in mind the non-standardization of octave numbering as reginaldStjohn noted.

I agree, but would still record MIDI rather than audio, and use Set Measure/Beat At Now to sync Cakewalk's timeline to it.

MIDI buffering was revised a couple releases ago. The default now is 50, and is generous where 250 was marginal and 500 was needed in most cases under the old scheme. I've been running mine at 20 without a problem.

Don't know what to tell you. It is a bit strange, but hard to see how it really matters, unless you think the MME version sounds better? What prompted you to compare them in the first place?

Non-realtime audio rendering is an offline process that does not depend on hardware or drivers. I think it's more likely that TTS-1 just never renders the same way twice. Even if you do two exports with the same driver mode, they will differ enough not to null. I've observed this with TTS-1 in the past. I believe it's a micro-timing issue as opposed to the timbre differing.

So you recorded live performance input as well as sequenced playback from a workstation-type keyboard simultaneously? I assume you had some sort of sync set up with matching tempos between the workstation and Cakewalk...? Were you playing to Cakewalk's audio metronome, or just playing along with the keyboard accompaniment? And how are MIDI and audio being routed and monitored while recording? If MIDI is all late relative to the grid due to audio latency and/or MIDI transmission delay, you might have a lot of notes getting quantized the wrong direction, but I know of no circumstance that will cause notes to be deleted. Possibly you have early and late notes on the same note number getting quantized to the same gridline so one gets masked by the other...? In any case, zoom in a bit and check the average discrepancy between the MIDI and the grid. And watch how it moves when you alternately quantize and undo. If everything is typically late (or early) you can start by nudging the whole clip to minimize the average discrepancy before quantizing. If there's a strong average offset one way or the other, you'll want to see what can be changed in your setup to minimize it. Quantizing isn't rocket science, so long as you have a good handle on what resolution is needed, and everything is within half of that resolution of the M:B:T grid line where it was intended to land, it should give a good result.