azslow3

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.

Note that in your screenshot there is a track "Kontakt 1 Main" and "Plug-Ins" list doesn't include Kontakt... So you have found tracks which mentioned Kontakt, not Kontakt in the synth list. Depending how someone defines track names that can be close to the same. Some users name tracks based on sound kind, not plug-in type. Also if the goal is find all synths, searching particular one doesn't help.

I don't know if A-Pro source code is available (not in standard Cakewalk repository), so I can just guess. Most probably A-Pro surface plug-in switch the device to control map 0 during initialization. That make sense, to avoid support busy with questions like "I set up how I want it to control Sonar, but it doesn't work" The plug-in is hard-coded to work with particular MIDI messages from all controls, when user change something that can break the logic. If the source code is available (Mark probably knows), it is possible to avoid Control Map switch. Otherwise the only way is change corresponding byte(s) in the binary, but I can't found any MIDI protocol specification for A-Pro and I don't have the controller to find corresponding command (plug-in sends a bunch of CCs and SysEx at startup, I guess one of them is switching the Map).

https://www.azslow.com/index.php?action=downloads;sa=downfile&id=104 Command line tool, for one file. But example BAT to scan current directory included. The result can be redirected to file, f.e. cwpsynth_dir.bat > all_synth.txt

I will try... may be tomorrow, but that is not hard deadline 😏

I have just tried and it couldn't find Kontakt, at least it was not listed in plug-ins. While I am not going to re-create that tool, if you write what you really want and implementing that is relatively simple (for me), I may consider to write that. F.e. a command line tool which list all synths in specified project (can be saved into file, run from a batch script which search CWP files, etc.) is not a big problem. Project management with sophisticated GUI is problematic...

I guess the confusion comes from existence of: "revived" plug-ins: info about VX-64 in Sonar 2024/2025 Revived plug-ins are Sonar/subscription locked VST3 (original are unlocked). VX-64 is not in the list (at least not yet). Original VX-64 plug-ins are from pre-platinum time. They can be (I have not checked recently, but there is no reason that no longer work) installed offline, in case the user has corresponding license and installation files (8.5 - X3).

You need to check Focusrite Loopback is enabled. In Windows 11: 1) right click the speaker icon, select "Sound settings" ("Soundeinstellungen") 2) in appeared panel select "More sound settings" ("Weitere Soundeinstellungen"). 3) in appeared panel select "Recording" tab ("Aufnahme"). Try to find something like "Focusrite feedback". If not there, right click on any and select "Show deactivated devices" ("Deaktivierte Geräte anzeigen"). Right click on Focusrite feedback (I guess it should be there), select "Activate" ("Aktivieren") (obviously in case it is deactivated). 4) you should be able to select it as input in Audacity and other programs. And hopefully it can record Sonar then. PS. You could record in Sonar because it is in the set of ASIO input channels, unrelated to windows settings.

Have you followed all steps in my last link? I mean "Expose / Hide Windows Channels" "Lautsprecher (loopback)" input in Audacity is not Focusrite loop-back input (it is WASAPI output, the feature I have mentioned before, it can loop-back record the system + apps which use WASAPI, but not ASIO). As a check, you can use steps described later, so set Input of some program in Windows audio settings to "Loopback".

It can be Will is right and you can, at least there is one report of success: But he doesn't mention if he was using ASIO in Cakewalk. I suggest you try. If that doesn't works, try disable Loopback input in Cakewalk and try again. Sure that is not going to work with two ASIO applications, they can't run in parallel with Focusrite.

WASAPI does not require anything to record any WASAPI output (so loop-back, f.e. system sounds), except recording application should be able to work that way (from my knowledge Sonar doesn't, Audacity does). But that doesn't work with ASIO outputs (at least in my tests). Real interface loopback logically should support all directions, but was primary intended to record something (not ASIO) into DAW (ASIO), I mean not other way around. At the moment I don't have Focusrite to check.

These apps are not (only) for on board sound and they are not in the category of "generic drivers", they allow flexible audio routing in case (any) hardware interface and OS own features are insufficient. Generic drivers can disturb dedicated ASIO drivers, it is recommended to remove them in case of problem, as a part of troubleshooting. And keep them removed in case they are not needed, to avoid these problems appear. That is a good advise for everything not used (not only for audio processing). But when you explicitly use something for a good reason, and that can be generic driver, it is fine. If it works. In this thread there was no discussion about any "problems with audio". It is "how to" thread