azslow3

Since I have mentioned that indirectly only in my lengthy post: 24bit and 32bit (floating point) files have the same precision for the sample amplitude. The difference is that in the first the precision of particular sample depends from its amplitude and in the second it does not. F.e. if a track with max level -24dB is rendered into 24bit file, 4 upper bits in any sample will be 0. So effectively it will be 20bit format. 32bits solve the problem, the source with any level has 24bit precision. And there are no "consequences" apart from the file size. 32bit (float) recording in some Zoom devices serve the same purpose. But since that is technically implemented using "tricks", there is some degradation in fidelity in comparison with (proper gain staged) 24bit recording device. Most users claim the degradation is unnoticeable (in the corresponding price range segment) and well worse the fact you can forget about gain knob (it does not exist) and concentrate on more important things...

I have found only one Mytek ADC device, in "discontinued" section. And from its documentation: Now I have got it, we are using FALSE 32bit files, since they all are filled with floating points... ? What is not possible to find in the documentation are characteristics of the device, normally given for middle-range audio interfaces and always known for top interfaces. But sure, in HighEnd world "This is absolutely the best analog-to-digital converter ever created by Mytek" covers everything and leaves no questions (those who ask simply can't understand the whole spirit...).

In fact it seems like L8 is not 32bit recorder (unlike F2/3/6/8, M2/3/4 and UAC-232). So saving into 32bit from L8 make no sense...

Many (most?) interfaces can record with lower latency under 48kHz (the number of extra samples is normally the same, but the sample "length" is smaller). Some interfaces can go even lower with 96kHz, but that is less common. Up-sampling to 96kHz is "strait forward" (and almost all plug-ins are at least tested with 96, since that is "common" rate, unlike 88.2...). In fact the opposite is true for (at least current) 32bit recording. 32bit was introduced to avoid gain staging, great for Field Recorders (when the level is unpredictable) and other similar situations (no wonder Zoom, as major player in field recorders, has adopted the technology). Note that fidelity is not top priority for field recorders... What and exactly how they do that is "proprietary", but from all sources they are not using true 32bit ADC (all ADCs are for physical reasons fixed point), the output 32bit floating point is somehow composed from outputs of 2 different ADCs (in some devices they are 16bits...). Both ADCs are not used with "optimal" gain, the target is avoid digital clipping even in case an airplane will fly right over the microphone, not to retain best fidelity. And so there is quite some "math" in combining the result, which is in any case way more significant then any "dithering". BTW when converting 24bit Fixed-point to 32bit Floating-point there is no dithering, the second has the same 24bit precision as the first one. Note that the consequence of the last statement: saving the input from 24bit interface into 32bit file is just wasting space (extra 8bits in each sample will be constant). It CAN make audible difference, VST dependent. That was discussed many times in this (and old Cakewalk) forum. With practical examples. The reason is again pure technical, some mathematical algorithms used for audio processing or generation "produce" frequencies outside 20kHz. Even when working with a stream of samples which can't have such frequencies. So resulting "numbers" land somewhere in range of allowed numbers, generating aliased frequencies. "Properly written" plug-ins are aware, they up-sample before and down-sample (with LPF) after such (or total) processing. But not all plug-ins are "properly written" (even so some of them are well known as "good"). But a difference between 48kHz and 96kHz in a file (physiologically) can't be spotted by a human. Such claims exist in the Internet, normally in High-end equipment forums/ads/blogs, sometimes even with tests... Note that hardware (including analog) is also a subject of "not properly made". So any such component in High-end chain will produce aliases in lower (audible) range. Such aliasing is so subtle, that it is not only declared as "the difference", but can be perceived as "a feature" (even so in reality that is just "a bug"...) --- So: record into 24bit (44.1/48/96kHz, depending from own preferences and required side-effects, 48kHz is a good balance). process in 64bit. 32bits are sufficient, but have 24bit precision. Every FX in a chain can "destroy" the last bit. After huge number of processing passes, that can "leak" into the result. So, practically that is impossible to perceive, but theoretically it is, and modern computers have power ?... Plug-ins are likely processing in 64bits in any case. up-sample for "buggy" plug-ins (or in general, for safety, if you have sufficient resources...) render/bounce/freeze into 32bit float. Only for the final result (so after maximizer) 24bit is a reasonable option. 64bits is an overkill for persistency do not bother about "dithering" options for anything above 16bit format, no equipment will be able to reproduce that (till you save intermediate files into 24bit, which as I have written is a bad idea). especially when working in 96kHz, put LPF before output to the interface (till you knows what your gear does with "High-end" frequencies...).

This. 19% in Germany...

They have finally implemented "compatible" with Cakewalk takes system... Not that previous one was bad, but for me it always was let say inconvenient (probably just because I was used to Cakewalk approach). 70€... well, the last time I have payed was more then 1899 days ago

So, one indirect way converting CbB -> DAWProject already exist. First convert to REAPER (with ReaCWP), then convert to DAWproject (with ProjectConverter) Till DAW developers put real effort to do this right (automatically or after asking user rendering/converting unsupported by export format parts of the project, like it is done for "Audio export" or saving into common formats from graphic editors), exporting to different DAW, changing there and exporting back is not going to be fluent. So one direction transfer is probably primary application for any export format in the DAWs world.

CbB is current version of OLD Sonar and there will be NEW Sonar which is most probably the next version of CbB. So no EOL. If you want "escape" from Cakewalk products, there is solution (for one other DAW). That is not "mostly the same" nor simple. Every program (including notepad, DAWs, plug-ins, games...) are just "different .exe or .dll". Conversion between formats on the level DAWProject propose is possible, but requires significant programming work (and skills in the topic). From exporting perspective, at the moment DAWProject will just add yet another 2 DAWs into which you can export easily. Also note that DAWProject has quite significant assumptions about project structure, from quick look it is "compatible" with CbB/Sonar. But that doesn't mean any DAW can fit own paradigm into it. And even more important, the evil is in details... OMF and alike formats are simpler and exist for long, the compatibility for them is still not perfect.

I think AZ Controller is the only way (apart from directly programming own plug-in in C++...) which can be adopted for all possible cases. But how "simple" it is depends from the perception of simplicity, in other words that is not "one click for all imaginable situations". If interested (and ready to use AZ Controller), ask on my forum (www.azslow.com). Describe what exactly you want (f.e. "trigger FX bin of current track" or "temporarily disable FX bin for "Keyboard" track when pressed") and do you want completely disable the pedal as sustain or not (f.e. it is possible to make it triggering bin with stopped transport only, allowing using the pedal normally during playback or recording). I can make corresponding presets (for me that is quick), so you don't have to learn AZ Controller (that it not "simple"). Alternative (simple to use, but depending from the hardware and desired result can be not possible/hard to use) ways: MIDI shortcuts in CbB. It may be possible define pedal as "MIDI Shift", so when it is pressed normal keys trigger "command" (from the list of possible shortcuts) MIDI learn within FX. The way normally used for Guitar effects in CbB. "remote" learn for particular CbB control (possible when control in question has that option in the right click menu) using standard ACT plug-ins (f.e. "ACT MIDI" or "Generic surface").

I agree, direct Kontakt integration is a good thing, especially since Kontakt is multi-instrument and so it doesn't "fit" into Komplete Kontrol concept. But how that is bound to MK3? I have found no info if/when they allow that from MK1/MK2/M/A as well (obviously that is no technical show stoppers). Sure, NI can just say "that is S MK3 feature", but I hope (for them) they don't. In general, I completely agree that controlling NI synths with NI controller is a good idea. But for DAW integration, I was writing about a possibility to control arbitrary synthes and FXes, not about one particular (like Kontakt). DAWs normally have some own way (apart from direct MIDI learning) to control plug-ins. What is still not there is some more or less working and common way to select presets, that is what NI (and Akai) try to mitigate with KK/VIP. But preset tuning is more or less the same everywhere. Sure, not for everything, but that is also true for NI MK3, even in the official demo they use mouse once it comes to "unusual" parameter change. PS. strip above wheels is great change, a fix for design mistake they have made originally (on M32 there are strips only... the number of times I have touched them without intention when operating buttons above can't be counted by fingers... )

What I think about M32/Axx you can read here: https://www.azslow.com/index.php/topic,608.0.html I know Sxx is different and so my opinion about it will be different.. But NI has made logical from marketing point of view, but for me "user unfriendly" decisions for all keyboard: 1) these controllers are not "MIDI", they are able to work throw proprietary protocols/software/logic only. That way NI is able to keep full control on what user can do with these devices. And they already have many questionable artificial limitations. F.e. while everything on device technically produce "a signal", many of these signals and feedbacks can't be used at all (even in official DAW integrations). 2) (the consequence of (1)) they kind of enforcing Komplete Kontrol and limiting DAW integrations 3) they (intentionally? I think so...) care keyboards no way used as Maschine devices, so you have to buy both if you feel yourself "limited". There is place for pads on A/S and the price, especially for S MK3, definitively can cover several $ worse pads matrix. But in practice they put bare minimum of buttons on all keyboards and still where possible "killing" the functionality of these buttons. So, as a DAW controller something MCU like is better (faders, more buttons, etc.), for recording/controlling anything except Komplete Kontrol wrapped instruments most other controllers are more flexible and as pure 88 hammer action for the price (of S88 MK3) it is possible to get "real" (long) one. I mean there is a narrow region where NI Sxx are good, but multiplying the number of users which work in the range by the probability they are using Cakewalk as the DAW and the probability they want a bit more then "MCU compatible" mode (in practice with standard integration that means not a big difference), you get the number very close to zero. So NI nor Cakewalk will get no significant profit, while investing into one time development and paying for support. I hope I have managed to explain the point of my original comment

From the amount of feedback I have got about my integration for M/A controllers (probably somehow works with S MK2, but I don't know if someone has ever tried), special integration with CbB/Sonar probably is not worse the resourced required to develop it ?

Originally reported Bus names related problem is fixed. Unfortunately (I guess almost the same, so some cache...) problem exists (for me) with Sends. MIX_PARAM_SEND_OUTPUT returns the same value even after the send destination is changed. At some point the values is updated (f.e. when a send for another strip is added), but it seems like cached over destination changes. It seems like I get topology update notification after changing the destination, but I can't get updated value...

TouchDAW is great in case you have a tablet. It works on phones as well, but since you can't have all controls visible, that introduce some limitations. Another approach is to start with tunable solution: https://www.azslow.com/index.php/topic,295.0.html Unlike TouchDAW, OSC with AZ Controller does not require extra background service. You can tune it for your needs (well, that require some effort...) and you are not limited in the length of track/parameter names. ----------------- It can be just wireless transport buttons is everything you need. Then check https://www.azslow.com/index.php/topic,288.0.html It is web based, no extras on the phone side (and so fast and free to try/use).

I have decided to make the utility more or less "complete". The latest version should support VST2(i) and VST3(i) presets. DX is not planned (I don't think someone will continue using DXes and so converting preset lists make no sense, CWP2RPP supports that for project conversion).

iZotope products are almost accessible, including RX package which includes de-noise. I don't know if Waves Clarity is somehow accessible since I don't have it yet. When there are non-continuous extra sounds, separating voices from the rest can be the way to do. For example with demucs. Recently several other algorithms and programs appear, which can produce even better results. But as already suggested, it is better avoid the noise during recording. Also as I have already suggested before, about anything related to accessibility in music software and hardware better ask in RWP mailing list. You will get answers from experienced in that area people.

I have no REAPER to Cakewalk converter. Target format must be completely understood for that, Cakewalk format is unknown (I can only extract some parts). REAPER has no build-in OMF export, but there is (relatively expensive) software https://www.aatranslator.com.au/ which can do that. I don't know how good it works in practice, nor how good Cakewalk can import produced OMFs.

On GitHub you can access any version of the project. The instructions/links/docs can be version dependent. It is in fact possible to organize more "noob friendly" pages, but that takes time/effort and for free software that is problematic (there is no "sales", so no revenue for "good website"). Typically the instructions are in README.md, which is displayed automatically after top level tree (I also wish GitHub collapse it by default, so the file is really "on top"). But then you need to "recognize" how to install. You probable already know windows/apple/android common icons, so these you perceive as "easy to find". In case of spleeter there is "pypi package" icon, at the very top of the file, so "as top as you can get" in default GitHub infrastructure And the installation is as simple as "pip install spleeter", it does the rest on its own (till there are some problems in particular version, particular architecture, etc.). If you don't have "google playstore", the link to it will not help. The same with pip. And there is no instructions how to get any of them, it is assumed you have it (there is no "please insert Windows installation media... " in Cakewalk documentation, right? ) Why there is no "Windows installer" here? Because this project is platform agnostic, as most command line Python projects. They think in terms of "running in container" (docker icon) or "running in current python environment" (pypi icon). Windows / Linux / Apple is irrelevant. About "Download". As with Android apps, python projects are normally "installed", not "downloaded". Logically there is no "download" link (except for the source...). PS. demucs can be installed by "pip install demucs". They have not put it on top, but mention that later in README (tip: search the world "install").

I have updated the utility: bug which was producing "ERR: in rpl_line" should be fixed now. Small (under ~128k) RPL files generated using buggy version are valid, but bigger (if you have some) should be regenerated. VSTi should be supported now ("-i" option is removed)

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.