azslow3

I don't know any DAW in which Mute works for Input (audio or MIDI). Mute means "mute the output" (everywhere). "Input echo" / Record mode (f.e. "Sound on sound") / "Record arm" control what goes where and when. "Input stream" and "Existing recording stream" can be merged differently (even at the same time) for output and for recording. There is no "enable input" in Sonar. There is just one "MIDI Bus" in one MIDI track in Sonar. It can't distinguish different controllers if they send the same MIDI messages. And you can assign "One controller" or "All controllers" as an input. But there are "Drum maps" and MIDI filtering/converting plug-ins which give some routing/filtering possibilities (plug-ins are always "Effects", so applied after recording). All that is still in DX MIDI domain and with limited MIDI routing. MIDI in Sonar is not change like 20+ years. May be devs have plans to touch that in the future, but that is unknown... In other words, if you need/want intensive MIDI processing in the DAW, use another DAW(s).

I have tried several times to understand how to work with tempo in Melodyne when it is inside a DAW. But I have failed to understand the logic (if it is there at all...). If you have Studio, you can do multi-track tempo manipulations standalone. If material tempo is recognized/assign correctly, tempo changing of any kind is working predictable (including making tempo constant from free style playing). But if Cakewalk way (AudioSnap) produce reasonable results, render Melodyne and then do tempo change in Cakewalk. It can happened that is working fine without Melodyne rendering these days, back in time that was not a good idea...

I don't have membership, so I don't know for sure... but from all announcements: if (1) someone has membership, (2) new core plug-ins are installed, (3) VST3 "Replace if possible on project load" is enabled, then all unlocked Sonitus DXes will be auto-replaced by membership locked VST3 Core plug-ins. That route is one way, so it seems like if someone ends the membership: a) explicitly added or auto-replaced new plug-ins will stop working b) implicit plug-ins may stop working, but I don't know (and I can't test) if implicit plug-ins are auto-replaced. By implicit plug-ins I mean FXChains and Style Dial PC knobs. I couldn't find any info about (b).

Hi Bruce, I am glad you have solved the problem. And sure, once a problem is solved, it is easy to find from where it was (from Sonar change-log for 2025.07):

OP has already mentioned the driver name of the interface: RME Fireface. In other words, he already has an interface with build-in matrix mixer and more routing capabilities then M4 and SSL2 together... I guess there must be a reason he tries to use extra software. ASIO4ALL and VB-Matrix are in different categories. And till "old school" ASIO is finally vanished from Windows and replaced by something "modern", software which workaround artificial Steinberg limitations can be useful.

Hi Bruce, I have installed Coconut and Sonar is still running fine. I even connected RME and set it as the clock master, to be closer to your environment. Tested with M-Audio (2x4), RME (4x12) and Phonic (12x12), at 48kHz, all ASIO. Sonar is using VASIO-512 / VASIO-8. So there is no general problem with Coconut and Sonar. But I have an idea what can be wrong... Which RME device you use? Do you have other ASIO devices in the system? Coconut expose huge number of own IO channels. It can happened Sonar has some limit on total number of channels it is able to "sense" in the system without crashing. To check that theory, can you install "normal" VB-Matrix (uninstall Coconat), and check Sonar still crash?

I can't understand the meaning of that statement. Sonar definitively can work with VB-Audio Matrix (I have never tried Coconut, but seriously... if someone needs Coconut, it is time to invest into proper gear...). Just to be sure, I have tried all combinations. So ASIO /WASAPI. With Matrix loaded and not loaded (obviously IO selection in Sonar has to be changed to get sound). But as with any VB staff, the user has to understand what this software and many of its settings are doing. Windows Audio settings are important as well, especially when audio drivers for hardware audio interface have "not the best quality". VB programs tend to glitch/stuck if something is configured wrong (or by starting programs in wrong sequence). The only Sonar specific I know, it tries to auto-open devices "early". The settings are scattered across several Preferences pages, it is not possible select complete target configuration (driver model + IO channels + clock source) and only then load it. Once ASIO is selected and applied, Sonar already tries to work with some (f.e. last used in ASIO mode) device/channels. And by default Sonar enables all channels. As the consequence, when default/current Sonar ASIO configuration is not only "wrong", but also stuck/crash (easy to achieve with VB and many "well known" devices), that is not easy to correct. General strategy is: make Sonar work in particular driver mode, let say ASIO. If uninstalling VB Matrix is required, fine (doesn't take long to re-install). But just disabling ASIO device in Matrix can be sufficient. If uninstalling is the only route: change ASIO configuration in Sonar to something which should work after required change. F.e. don't use audio interface which will be under VB control. There are plenty of "virtual" devices, from VB and other software, which can be used at that stage. re-install drivers (VB Matrix). check Sonar is still ok properly configure Matrix/Windows/everything else working with audio attempt to select Matrix ASIO device in Sonar. Most important: don't let any software except VB Matrix use real audio interface(s). That includes Windows/OBS/Sonar/etc. Especially important if real device driver is unable to work in ASIO and WDM in parallel. That should be easy to do after you install VB Matrix but before you configure any ASIO (real) audio interface in it. Just switch Windows/OBS/Sonar to use Matrix virtual devices. let audio interface be the clock master in Matrix (if possible) everything should be configured to work with the same sample rate. When some not primary WDM device simply can't work with desired sample rate (f.e. webcam), that is usually not a problem. But Matrix/Device/Windows/Sonar in different sample rate is looking for troubles. The only tricky software is Sonar, sample rate is project dependent. I will say: if you have projects with different sample rate, use dedicated audio interface for Sonar. Can be combined with external analog audio looping when required. Note that Matrix ASIO sample rate is locked to master. So if you still consider to use different sample rates in Sonar, you will need more then one Matrix configuration. Use audio interface as master with different sample rates or use Matrix Clock as master with different sample rates while keeping audio interface under the same sample rate (if that works better). use pessimistic buffer settings (start at least with 512). VB solution is not going to have low latency. It put extra processing and synchronization into audio chain. Any underrun can produce problems in range from glitches up to total crash, even when in "direct" mode it just produce small pop.

I know it sounds "not right", but try to EQ TXLTimecode output, LPF ~20kHz The plug-in outputs "perfect" digital square. That is not good for audio output. File downloaded from the side you have referenced and one other DAW build-in generator have (a kind of) LPF applied.

Driver related setting are grayed when the driver doesn't allow to change them. So it is locked on AXE IO side. But in general I can't imagine a reason to want 16 bit there. AXE IO dynamic range is significantly more then 96dB and DAW processing is done at 24bit (32 bit float, more when "Double precision engine" is enabled). But you can record/render into 16bit files. Unlike with sampling frequency, I don't think Sonar put any restriction on different depth in one project.

For that money, they had to do something "special" 😏 Merging knows how to do that type of equipment, but "USB part" is hacked in by someone else. That is the first (and the only) interface from Neumann, also I don't know if Sennheiser ever had a company with experience in normal USB interfaces. What I think is "special" in the class of "notebook capable" audio interfaces with small number of IO is... fan... reviews mention it is not really silent... 🤔 Also build-in effects are not stochastic, no reason to record wet. I think many DMs and "DM like" audio interfaces can. DMs effects can be stochastic, so that can make sense. Recording digital EQ and Compressor (f.e. in RME) has questionable value.

Aux Tracks was introduced exactly for that purpose (a possibility to use them as buses, to visually interleave "buses" with tracks, was a side effect...). Many synths and effects produce significantly different result every time you play the track. During performing, people "adopt" to currently produced sound. F.e. all effects with slow continuous (in world time) modulation. There are DAWs in which there is a special "FX bin" which should be applied before writing track data to the disk (useful for audio and MIDI).

"Edit Node" is editing Automation Nodes. The "Level" is the value, in corresponding parameter units. Normally these parameters are not (!) MIDI. They have usual float numbers precision (way more then 100000 possible values...). For MIDI possible values are integers, 0...127 (except for Wheel). There is no hint Sonar supports CC14. But in practice CC14 is a sequence of 2 CC7. So Sonar will work fine with them, there is just no convenient way to edit the data. And the number of CC14 per channel is small. While (N)RPN will use twice number of CC messages in comparison to CC14, that is not important till you transfer that throw hardware MIDI cable. >16k of (N)RPNs are available per channel and Sonar supports them.

CWP is Cakewalk proprietary format. There is no documentation. That is one of the reasons my utilities are not open source (even so developing them for the purpose they are developed from my knowledge is allowed in EU). Note I don't recommend mention other DAWs and my related utilities on this forum... Discussing utilities useful for/in Sonar was (and I think still is) ok.

For 20+ years Cakewalk has not updated the set of "core" plug-ins. Now they are updating them. Note that some related DXes from what I remember are used in Style Dials. In the future they can consider updating "extra" plug-ins, proper locking for particular purpose (f.e. Premium or Style Dials only). I mean most old users have "normal" versions and new users better know the procedure with internal plug-ins is "a trick" which can stop working without warning in any update. It can happened it will work another 10 years, it can happened it stop working in a month. We don't know. The point these internal plug-ins are not in the official list and so can be removed/locked at will.

Style Dial knobs are normal FX Chains which use these plug-ins. For whatever reason Cakewalk has decided not expose these plug-ins directly in all bundles with Style Dial knobs. In other words, they have to have them but don't want they are exposed as "normal" plug-ins (till installed separately). It seems like "Internal" copy is the way the concept is implemented... These are "normal" plug-ins, installed separately. They can be installed from any bundle, including pre-platinum, but the user obviously has to have related license (has payed for 8.x - X3 - SPlat bundle with these plug-ins included). VX-64 Vocal Strip (only) is mentioned in the "new" Sonar changelog, so it is probably installed/installable without prior versions. I guess using "internal" versions is not a good idea, even in case that is somehow possible at the moment, the "backdoor" can be closed in any future update.