azslow3

To clarify all that a bit... What plug-in is drawing is common for all DAWs. But each DAW has own controls and extra functions. So the icons inside plug-in are working the same way in any DAW, f.e. "Acoustic Guitar"/"Default" are DAW specific present management sections. Both DAWs can export/import FXP (single preset). FXB can be a collection of FXPs, but that is not forced. Cakewalk is using SPP for collections of presets, REAPER is using RPL. Both are proprietary DAW specific formats. Writing a converter is theoretically possible, but that will probably take more time and effort then converting 200-500 presets... You can use build-in export/import as pointer by Scook. That will work for sure. Alternatively you can try FXP way. You still have to load and export each preset separately, this time as FXP (using VST2 menu in Cakewalk). But then you can combine them into RPL using mentioned utility. So you don't have to import and save each preset separately in REAPER, that cat significantly reduce total conversion time. But check with several presets that such procedure works.

If you can save FXP/FXB, they should be loadable directly (if the plug-in is the same). Alternatively you can try to convert them into RPL, https://www.azslow.com/index.php?action=downloads;sa=view;down=75 I don't think that helps, but who knows...

In each tool the separation is "good" or "bad" depending how target material match a set from training data. In one of recent exercise demucs has separated the voice and guitar way better then spleeter, but it has failed to "find" drums and percussion in that recording, spleeter has found them. It can make sense to separate by different tools, f.e. remove (separate) vocal with MDX/other and then separate the rest by demucs/spleeter. Separation not always have to "sum" correctly. F.e. in re-mixing live recording it is possible to use "the best" tracks for drum replacement, side-chained input for dynamic/eq, etc. For that purpose most important the existence of signal in particular tracks, not fidelity of it.

I also was using Realtek on my 2 notebooks since 2007... On the first one with ASIO4ALL, on the second with native ASIO driver and then with WASAPI. Native ASIO was hanging one or two times, but in general I had no issues. Playable with MIDI keyboard (no guitar nor mic inputs, the latency is not critical). When real RTL does not match reported in the DAW, the recording is misaligned. Under 1ms is not significant (for most people), but running Oblique or just loopback and adjust in settings is fast way to avoid that. X(R)12-18/X32 are nice. Pre-amps are a bit noisy, the latency is not small and some effects have algo-delays but don't have PDC. But for live recording all that is not important? BTW Behringer has Midas MR18/M32 with a tick better pre-amps (and so higher price), otherwise they are the same.

Have you really measured all of them? And if yes, how? Also the frequency is important (44.1 / 48 / 96)? And exact models are also important. The numbers for Focusrite and Motu look like for relatively slow models (not the slowest, but they also have better ). For Behringer I have not really found any 100% reliable numbers, but from the information I could find, measured RTL can be (significantly) different from reported, all posts with screenshots of audio to audio at 64 samples point toward 6ms (reports - toward 5ms). Note that I know that Behringers (with ASIO driver) have good latency, for what they are. It just should not be called "ultra-low", the term they was always using even for Xenyx mixers

My point is that Behringer had ASIO driver for lower units (and Xenix mixers) and was giving better performance then ASIO4ALL (I have compared 2015 after I have reinstalled one of my computers and couldn't find original drivers quickly). I believe in 1ms RTL with 32 samples / 96kHz with Quantum and perfectly optimized special audio oriented computer under low load. Usable ~3.3ms RTL with RME and "normal" computer. ~5ms RTL with some other constellations. Achievable ~6-7ms with most interfaces. But Behringer with "ulta-low" latency is science fiction ?

For Berhinger's low end interfaces: http://forum.cakewalk.com/Behringer-ASIO-drivers-disappeared-m3294586.aspx So they had ASIO driver which was not ASIO4ALL but at some moment they have "cleaned" all references to it (without explanation). It probable was some re-branded generic driver for which license/support was over, but that is just speculation.

This one can help if your monitor is broken but you still want control Cakewalk (not a joke: https://www.azslow.com/index.php/topic,342.0.html ) But if someone has a MIDI controller, there are simpler ways to assign something on it to sustain CC (if controller can't do it by itself, there are MIDI mapping plug-ins) ?

I also disable Realtek in BIOS, on computer which has different default interface. But in general I have not noticed any problems having extra audio interfaces enabled. At least not recently. There was times when NVIDIA HDMI audio was somehow influencing real-time performance, but last years I have all drivers enabled (RME, M-Audio, Phonic, Roland, Behringer and ReaRoute ASIO + HDMI) and everything seems like working ok. What I will never install again is ASIO4ALL (and probably any other generic wrapper drivers). This one can magically disturb other...

For BCR2000 there is most complicated configuration ever made with AZ Controller: https://www.azslow.com/index.php/topic,301.0.html, check PDF in the second post of the thread. Labeling controls is not practical, especially if you map many plug-ins and have several layouts for the same controls. It is better use second (or third) display and permanently put build-in AZ Controller display window there. The size of each "cell" is not limited as on Mackie/X-Touch controller, so you can see meaningful names even for lengthy parameters. If you don't want or don't have place for big display, there are many small HDMI displays which you can put just behind the controller. As I have mentioned before, Cakewalk has tried introduce "rules" for auto-assigning common parameters in ACT. From my experience that is not working well. Manual assignment for each plug-in takes up to several minutes only, so mapping 20-30 plug-ins does not take more then several hours. Just don't forget to use AZ ACT Fix. That will guarantee your time will not be lost (you can try to backup files manually, but that does not solve other problems). PS. Installing AZ Controller and testing it with Mini, Mackie and BCR2000 (with pre-made presets) does not take more then several minutes. But read the manuals for presets, layouts are not trivial.

Please tell me if I have failed to explain something, or you just don't want to use 3d party tools (even so in the second post you have nothing against that) or you for whatever reason just don't want use my tool(s). No problem, I will just shut up But for Behringer X-Touch Mini I have already posted the link: https://www.azslow.com/index.php/topic,377.0.html It implements plug-in ACT control (apart from the rest) and supports coarse/fine changes using the leftmost bottom button (labeled as "MC", I call it "Shift"). As momentary (so opposite to current resolution when turning encoders while the button is pressed) and locked (pressing the button alone toggles current resolution). "Coarse" and "fine" resolutions can be changed to taste (as the whole functionality of the preset). Cakewalk Surfaces can trigger any keyboard keys, including "Control". Standard Mackie surface plug-in does that. In AZ Controller you can generate whatever computer keyboard input you want (f.e. BC2000 preset use that to open/modify/apply tempo change dialog, not used in mentioned Mini preset but can be added in no time). Noticing computer keyboard modifiers are pressed is not supported by API (but can be done on Windows level, that is one from not many possible features which are currently not implemented in AZ Controller, there was no evidence that can be useful...). BTW there is Mackie preset in AZ Controller as well, with ACT support. That was "a prove of concept" only (I was testing I can implement complete Mackie plug-in logic as a preset for AZ Controller), so it was not tested intensively and has some logical "bugs" (will not break the device or corrupt project, just some minor differences). But I guess it is possible to use it in practice (I have never tried since I don't have the device nor its clones).

I have no idea what you want here... You have started with some "claims", continued with some statements. You have got already almost all possible answers. Including RTFM. From that you could easily extract most answers. For your last post, there is no fine control in "ACT MIDI controller" nor in "Cakewalk Generic Surface" plug-ins. Coarse resolution is also not configurable. You want a solution for X-Touch Mini which support ACT, Fine/Coarse switching and tunable resolution for both? It is already mentioned in this thread. You want yet other one? Then I can disappoint you, msmcleod and me are the the only people which was providing surface solutions/improvements last 8 years...

Program change was almost abandoned since most synth and many FXes are unable to switch presets instantly. Note that the list of parameters (and automatable parameters) as well as choosing presets exist in plug-ins API. VST3 has tried to bringing that to the "next level" (effectively killing MIDI support). Queering surface capabilities has not standard at the moment, but at the end of the day that part can be manually done for most controllers within several minutes. And fixed "set of functions" is incomplete (and if someone will try to make it complete, the same thing will happened as in https://en.wikipedia.org/wiki/Gödel's_incompleteness_theorems). As I have tried to explain, even when you know the controller layout and which parameters are available, there is no "one and the only right" mapping between these sets. The whole challenge is create more or less reasonable mapping. For DAW (at each production step, i mean recording, mixing, mastering) and individual plug-ins (can also be step dependent). The number of physical controls is limited. Obviously when you have more you can directly map more parameters at once (as with C4). You can try to use "banks" (fixed, as in Mackie or ACT MIDI or arbitrary as in AZ Controller), but that comes at price. I think one of the most advanced example of pre-made mapping at the moment is NI NKS. At least for instruments with following FXes (for not so clear reason, NKS is not working strait for just FXes, I guess the reason NI has not produced any controller without keyboard yet and so the whole concept is VSTi recording oriented). With a bit of "extra", that is reasonably usable during recording (https://www.azslow.com/index.php/topic,604.0.html). When complete setup is specially designed to work together (NI Maschine, Ableton, Pesonus, AVID have dedicated controllers), the workflow is even more convenient. But generic "device" with general "software" will never play perfect together, at least not automatically. PS. In Cakewalk AZ Controller is relatively simple way to play with "mappings". You can check that hardware definition takes short time, even with devices like MCU. And you have access to all parameters/functions (controllable in Cakewalk, "Dynamic mapping" and "Mackie mapping" including. But in practice you can spend years to find "perfect" mapping for any device with more then just transport buttons (and even just with transport buttons, think about transport and focus dependent button combinations ).

MIDI protocol improvement can't improve the situation with surfaces. All modern surfaces are USB connected, they can use any carrier protocol they want (and some do). F.e. OSC allows bi-directional communication practically without any limits in precision or the length of display(s). There was several attempts to establish "control standards". Mackie, EUCON, NI "Komplete Kontrol", etc. But there are at least 2 problems. The first you have already noticed. Even so there is ONE MCU device, the layout for buttons is DAW specific (there are different overlays for different DAWs). I mean even with just one device you can't make something "standard" which works fine in any DAW, the parameters you want to control are different. And once you have several significantly different devices... There can be some "automatic" mapping (Cakewalk plug-in dynamic mapping in fact has user configurable pattern rules to auto-map parameters of new plug-ins...), may be even AI based. But till computers can read particular user mind, it is hard to tell which from 1000+ particular plug-in parameters particular user want control in particular situation. So there should be a possibility to overwrite the "expert choice".

Heh... I always forget that VSTi are also controllable since a while (since I don't have/use real MCU, that change just doesn't stay in my head...). For Mini, https://www.azslow.com/index.php/topic,377.0.html can give an idea what is possible to do with ANY controller. So there is more then one way to bind a controller to Cakewalk. When people write "MCU has 1001 function in REAPER", they normally use CSI or other third party solution. For Cakewalk there are less third party solutions, but at least one is available. "ACT" is still confusing term. In general, it covers all surface integration plug-ins in Cakewalk (including Mackie). But "ACT Learn" is related to one sub-component, I call it "Dynamic plug-in mapping", which is not used in Mackie plug-in. Note that working with these mappings can be tricky, Mackie mappings are more "stable".

Other can (VST, but not VSTi). No, "ACT learn" is not working (in standard setup), it controls VSTs other way. Not really, at least not REAPER (in standard setup). You mean new Bandlab products? There was no info about Surfaces Support changes yet. Than learn how to do this in Cakewalk... Good idea is start reading the documentation... For alternative options search this forum, that topic is discussed more then 100 times already... ?

Starting with X it is almost impossible to use Cakewalk accessible way. There was some "attempts" from Cakewalk team, in X2 and some promises last year. But nothing has materialized yet. So I recommend to change the DAW from Sonar 8.5 to REAPER, Samplitude or ProTools (on Mac). For REAPER there is (free) OSARA accessibility solution, it works good with NVDA or JAWS. There are also several projects for NVDA and JAWS separately to work with particular plug-ins. More info: https://www.reaperaccessibility.com/wiki/Main_Page For Samplitude there is a set of good written JAWS scripts. I have almost no info about ProTools, but I have heard it is reasonably accessible on Mac.

"New" features page is not the best to check differences in editions. For Cubase it is https://www.steinberg.net/cubase/compare-editions/ BTW have you managed to scroll down the page I have linked? I mean it gives direct official answer on the question "IS THIS TRUE?" (the subject of this thread) PS. For those who want compare the distribution of features with Ozone 9, f.e.: https://web.archive.org/web/20201112012340/https://www.izotope.com/en/products/ozone/features.html

I am for "backward compatibility" in the number of features for similar named products. In phones, cars, computers and software. But the reality is different. New phones loose connectors, removable batteries and sometimes (in my case) readability of the display (even so it is bigger). Computers no longer have "old" ports and buses. Some audio interfaces are "obsolete" just by one number in one text file of there drivers. Software can loose features. Offline activation can be removed in "minor" version update. I mean we have to accept that, I don't say I find all that good. Note that there are significant changes with iZotope as a company. It is now in Native Instruments "family". Ozone 10 Standard is included into Komplete 14. Some priorities and marketing politic was changes and I guess some "cuts" are the result of these changes. We are on Cakewalk forum, for which significant changes are announced. "Cakewalk Sonar" will have the same name but it will be different product. Some have already noted "CbB is free" and "we have payed for lifetime license". In this thread that is "I could get what I need from Ozone for free (or almost)". Will that change anything? I don't think so. BTW what is included in clearly listed. https://www.izotope.com/en/products/ozone/features.html

Unlike with some other products, it is possible to download and install older versions even after "upgrade". So what's the problem? The company has not packed the features you want into the newer version? Don't buy it or buy different edition. I can complain what my newer mobile does not have in comparison with 6 years old one, from the same company and in the same series. But that is just a bad excuse for not checking what I was going to buy...

I have understood there is a different in "gaming" and "audio" sound cards when by occasion have exchanged SB (ISA) with Gravis Ultrasound in my first PC... Decades later, after connecting M-Audio (Firewire) in addition to SB (PCI), I have realized that Creative gaming cards are still not good for music ?

I don't think without this option REAPER is able significantly beat Cakewalk in number of working plug-ins. As I have mentioned, in my tests some years ago the result was opposite. Since OP has observed the effect (or at least claims he had it...), I assume anticipative processing was on. It can be OP experience the bottleneck from completely different part of the system(s), I don't think he is using Studiocat hardware nor similarly optimized system. But we don't know that. Even so I had no problems with render-ahead (f.e. I don't have UAD), anticipative processing can be switched off per track. Till the effect is using some hardware, inability to work with anticipative processing will probably influence offline rendering as well (from plug-in perspective, except for GUI, that is the same). Also most DAWs support some kind of ahead rendering. I mean such plug-ins will appear "buggy" in many DAWs and particular conditions. I guess in the mean time plug-ins developers are aware.

REAPER has so called "anticipative" processing. During mixing (and on all chains without armed tracks during recording) the processing can be not done in time, it renders ahead 200ms (tunable default). Effectively that means the buffer size is 8820 (at 44.1kHz), independent which buffer setting you have for the audio interface. Cakewalk is traditionally "real-time only". In mixing and recording it does everything with the buffer size of your audio interface. Is the first approach definitively better? It depends. There are consequences. F.e. REAPER quantize PDC (plug-ins own "look-ahead" and so latency, not related to performance, driven by algo the plug-in implements) to the audio interface buffer size (previously for each plug-in, in recent versions per track). Depending from the project, the difference can be significant (usable for recording plug-ins normally have tiny look-ahead, way lower then the buffer size). Also general real-time (recording) can be worse with "mixed" engine (several years ago I have tested the limit with one "heavy" plugin on many tracks, Cakewalk won the test). Also unaware GUIs (almost all...) will "lag" behind the audio for the length of ahead processing, 200ms is noticeable. For 2x2 interfaces, so recording just a tiny part of the project per time, and mixing/mastering, rendering ahead is a good idea. What is the difference when the buffer sizes? Everything still has to be processed "in time", but the computer has more "air". PCs are designed for huge throughput, not for strict real-time. PCs are not DSPs. So without time limit PC can do enormous processing (billions of operations) let say in 1s, but if you want just one arithmetic operation but strictly every 0.1ms, you have to death-optimize the same PC, even so you want "just 10k operations per second". And depending from the hardware and OS it can happened that can't be done at all. How that "in time" is defined? So how much time the DAW+plug-ins really have for the processing? Obviously the buffer size multiplied by sampling rate gives the "time window". But that is not the whole story. The system latency can "eat" a part of that time. In practice the most significant influence has the quality of the audio interface and its drivers. In my tests on absolutely the same system and project, RME driver with 48 samples buffer can happily work while (old) M-Audio with 128 samples cracks and (old) Roland with 128 samples sometimes produced "Stopped audio engine". -------------- How to check the impact of your system latency and audio drivers? Most traditional methods are indirect and they don't give final and easy to interpret answer. Unfortunately Cakewalk also can't report that. In REAPER open Performance Meter and enable all RT settings (not default), including "Hold RT" (but set/unset it to have "current" numbers). Disable anticipative processing. Try playback a single track project, a bit more heavy project, may be even your current Cakewalk project (ReaCWP allows open them in REAPER, not perfect but should be sufficient for performance tests). Is RT longest-block is far from minimum or even over the limit on empty project? There are definitively big problems with system latency, ASIO drivers or both. RT longest-block is ok but not "stable"? There are problems with the system (not optimized). Then check RT longest-block stability in projects with plug-ins. Ignore "initial" jumps, many plug-ins (especially VSTi) lagging at startup. But that can uncover problems with disk related system latency, not visible otherwise. Compare the behavior between different interfaces you have. That can show the "quality" of them (ASIO drivers, not audio...).

I have started "collecting" audio interfaces on e-bay. I mean for someone with Realtek and SB5.1 it is questionable to spend even 100€ for some "device" with unknown outcome (not even 5.1 capable!). It happened M-Audio FireWire Audiophile was around for cheap, and it is still on my desk as "default" interface (after several seconds with Shure headphones, I have recognized that Music Audio Interfaces are not the same as platinum USB cables... each computer upgrade I check if Realtek can do the trick as "default"... but no, at least not yet... lol). Later I took Phonic Firefly. I had to pay more for it, but will way less then for new with 8 channels, able to work standalone and without ground loop issues. There will be someone who wants "professional" FireWire device relatively cheap, as long as: * it works under Window 10/11 (without driver installation tricks) * there are PCIe FireWire cards I mean if FA-101 can be used under Windows 10, it is better mention that when selling on e-bay (or alike platform). And if you have PCIe FireWire which works good (so TI based) and you don't need, it may be worse to include it.

AZController can also send OSC on record/play/mute/etc. toggles. Can be used to auto-change something in OSC capable mixers (Behringer, RME) or do something else wireless way (f.e. NodeMCU+LED matrix). In that direction but without DIY hardware, the approach can be REST commands from custom Control Surface to REST capable smart devices (bulb, power-plug, relay) (f.e. https://www.shelly.cloud/). AZController does not support that at the moment, but if someone really need it, I can add...