azslow3

Thanks for the feedback. I will try to fix both issues tomorrow.

You can try: https://www.azslow.com/index.php?action=downloads;sa=view;down=93 Command line utility, no GUI. Running without parameters print how to use it. That is the first version, it has bugs for sure. So check the output for errors and let me know if something goes wrong. Note that REAPER sometimes silently ignore mistakes, so even in case there is no errors during conversion and import, check that parameters are really changing when switching between presets. For mono plug-ins use "-l2s" option. SPP files don't have information about routing, RPP files do. That option set "left to stereo" (audio) routing, as in your example RPL (since the plug-in was mono). ----------------- The rest of that post you can skip. Depending from your skills in computing, the following can be "too scientific" to understand The names of plug-ins are different in Cakewalk and REAPER (they use different ways to construct the name). But both identify plug-ins by IDs and these IDs are consistent. They are in encoded as a part of the preset, you can't see them (easily...). Generated RPLs are not binary equivalent to self made, just in case you will wonder why generated RPL is different from your test RPL. Cakewalk and REAPER are using different "factory to external" presets matching approaches (with some plug-ins Cakewalk works more natural, with some REAPER seems like working more logical). Also the difference in preset origin is sometimes saved into preset, in your example presets in RPL include the name of "*.preset" files you was using for transfer, in SPP that are just modifications of "default.preset".

And this site is about Cakewalk. And after all these years, I still have no cakes from them... And I don't know where should I walk... ? "Ultimate Vocal Remover" can remove vocal, but that does not mean it can't remove the rest/split into several tracks/etc. BTW by default it creates 2 tracks, one with vocals only and one with the rest... Yes, that required READING. Sure, who is RTFM these days... Yes. Because programming freaks realize faster that without RTFM programs don't do what they want... Wait... there is ChatGPT4 now! It can write programs without asking the user to read any documentation first Well, just last week a college has asked me to "fix" his JS code. The code was looking "modern", but a kind of strange. After an hour I have re-written almost everything so it did what it had to. Only then I have asked him "how you have written that code?". The answer was... "I have asked ChatGPT...". GitHub is a platform for open source projects. It is not forcing providing binaries and installers, but many people do (in fact GitHub has build-in feature to auto-recompile on changes). There is source code, documentation, place to publish issues (and a possibility to link version in which the problem is fixes) any more. Website + Forum + download area + developers repository + issues tracker "all in one" for open source projects. For commercial projects outside GitHub you just don't see developers repository and issues tracker, but they are exist and they look similar. BTW Cakewalk control surfaces API and binaries are also on GitHub.

Any reason you have not started with the first link in the list (UVR)? The one which has an installer? BTW many project on GitHub have ready to use installers. The place just indicate the project has open source, not that the project is for computer freaks only... I have mentioned "original" demucs/steeper links because there is detailed information what they really are. I prefer that over descriptions like "brilliant"/"perfect"/"best".

For just removing vocal or separating instruments, there are many free solutions with complete description which AI/training DB was used. F.e. https://ultimatevocalremover.com/ https://github.com/facebookresearch/demucs https://github.com/deezer/spleeter Commercial solutions normally laud in case they have made something completely new and distinct, so if you see just common words about separation, that means inside is one of free algos, may be with a bit tweaked DB, but don't expect significantly different result ? F.e. moises at least 3 years ago was using spleeter algo (I just have not found more recent posts, it can be it still use it).

@johnegenes@gmail.com Looks good, I mean I will be able to convert.

@johnegenes@gmail.comI had a look, and I can try to write SPP to RPL converter... But for that I will need an example from plug-in in question. So an SPP with 2-3 (not more!!!) presets included and corresponding RPL (with the same presets). Upload these 2 files somewhere and PM me the link. It can happened the result will work with some other plug-ins, but not all. So for other plug-in separate examples may be needed. The reason is existence of several preset formats and corresponding differences in SPP and RPL. Note that I am not working for Cakewalk nor Cockos, so I do not have access to the documentation/source of these formats (for RPL more information is "known" and developers are more friendly in explaining internals, but for SPP that is not an option). There are some plug-ins for which that will not work (I couldn't understand preset structure). But with some luck your EQ is not in that list...

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