azslow3

? To use AZ Controller it should be installed first. All relevant information is on https://www.azslow.com/ there is a video which demonstrate initial installation. Once installed, Cakewalk Plug-in Manager (in Utilities menu) will have Control Surfaces / AZ Controller section and SPP files can be imported. X-Touch One is one strip controller. It internally has MCU (8 strips) emulation, but from DAW (Cakewalk) perspective the device will be 8 strips in MCU mode. That has consequences. Using the controller in "native" mode with explicitly constructed for it preset should be better. Note that I don't have that controller, the preset was created by one of the users and I have no way to check how good/bad it is.

Taking the art of this device into account, I don't think its Mackie emulation is useful, even in case it exists. Use ACT MID, deactivate Mackie on device and remove Mackie from Control Surfaces in preferences. Is music part works without surface modules? If yes, ACT MIDI is not blocking not assigned controls, but Mackie plug-in blocks everything.

Are you sure you have followed the video on page 1 and matched Windows sample rate with project sample rate? Note that existing project have fixed sample rate and the audio interface set to it on project loading. Windows does not re-set it automatically and it produce sounds only in case current rate match settings.

"A concurrent" has finally implemented up-sampling (in pre-release), as usual (for him) with max flexibility, so up-sampling individual plug-ins or whole chains, up to 768k. Not that there was no other options (project sample rate can be changed on the fly there and it is not fixed to the audio interface rate), but for performance that is nice ? Sorry for off-topic...

Please notice what scook has written. Some comments: * Cakewalk projects have no bit depth (but fixed sample rate). * what you see as "96/16" means your "Preferences/File/Audo data/Record bit depth" is currently set to 16. New recorded files will be saved as 16bit. * if you change the setting to 24, you can still see 16 till you re-open project (Cakewalk glitch) + Cakewalk can't work in 16bits at all, only 32 or 64 + Bit depth settings are global, they are not saved with projects (will influence any open project)

I don't think this device support Mackie mode: https://www.midiplus.com.tw/en/product-detail/Origin62/

Most recommendation from "producer" sounds reasonable (even so for older Windows versions, may be you can find for 10...): https://support.microsoft.com/en-us/topic/error-windows-explorer-has-stopped-working-057f3872-6252-67e3-2c5a-88c9c633fe41 This (and alike) normally helps with many strange system problems (sometimes also cleans system files and improve system performance on "old" installations with many system updates): https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image

I have just checked "Record Latency Adjustment" settings. Cakewalk applies the settings for currently used device. I mean Cakewalk is working correctly (till it mess specified settings after driver mode change, but at least it display these messed settings, so easy to notice and correct when required). So, "Record Latency Adjustment" for me by default show "BEHRINGER USB Audio" (it is the first in the list). But since at the moment I use "M-Audio FireWire", I have to select it first to change options ("Manual Offset" and "Use ASIO Reported Latency"). Without doing so, keeping "BEHRINGER" selected, changing options has no effect (on M-Audio). That all could be "as desired", if not a bit misleading fact the number after "Use ASIO Reported Latency:" is always for currently used device, independent which device is selected in the dialog. I think Cakewalk should show current device and it settings by default (so what it really going to use) and not display ASIO reported number when different device is chosen (since that number is unknown for other devices). That will avoid confusion with this part of the settings.

ASIO4ALL can invade computer audio... That I had (btw disabling/removing it not always help, only Windows complete re-install or major Windows update can help in that case, the reason is unclear...). But I have several ASIO drivers in the system (including Realtek), sometimes active simultaneously. That populates Offset Device dialog and make the selection shown wrong (it selects the first from available, not current). That was never a problem for me. I repeat, I don't claim there can be no problems with 3d party ASIO drivers. I just claim what is shown in that strangly formatted Cakewalk dialog is not an indication of a problem. @Sheds before changing the interface, check your computer/settings. In particular: run LatencyMon, it should be under 1ms; check your Power Plan is set to Ultimate (or at least to Performance); till you have proved good power plan, explicitly check USB power saving is off.

@John Vere In your video "Record Latency Adjustment" (7:30) note is not accurate. For some (historical?) reason, Cakewalk list not only currently used device there, but also other devices. Whenever dialog is open, it select "the first" in the list, which can be currently unused device. Even more, Cakewalk can mess with these settings in case driver mode is changed and the sequence of devices in one mode differ from the sequence in other, it seems like Cakewalk remember/show manual offsets as a list, ignoring devices. So the shift set for one device appear as a shift for other after driver mode change. That is clearly a bug. Cakewalk IO settings (MIDI and Audio) are periodically messed since years, I guess there is some general deep problem there which is hard to fix. What I want to say, the fact some interface appear in "Record Latency Adjustment" drop box (and even selected by default) is not an indication something should be changed/removed in the system.

"Device" and "Manual Offset" are connected, select Steinberg and set 10. After saving, open dialog again. You should find that offset is still 0 for Realtek and 10 for Streinberg. About computer optimization for audio there are many threads and forums. Enabled Realtek by itself should not influence anything, at least not when unused (by Cakewalk and Windows). Getting most stable drivers under Window, which means RME device, is pricey. Steinberg should work fine when computer/system are ok.

You can disabled Realtek on BIOS level or Windows level, but no one really cares. In Record Latency Adjustement there is a possibility to set manual shift for all devices you have, on dialog display it select the first... but only the setting for currently active device is used. So select Steinberg and check manual shift is 0 (or set correctly, in case you have measured it). For Steinberg, ASIO reported value should be fine (or very close to real), so set to use it. Note that even in case ASIO reports correct value, it is for device only. In case you connect something with own latency to the input (f.e. digital mixer), extra manual adjustment should be used. There are many detailed guides how to measure the value to set there, quick method is just loop record output, zoom to the sample level and notice the difference.

Somehow thinking that configuring a controller for a DAW is "intuitive" and can be achieved without reading the documentation is common. That was also my approach at the beginning. And I was so frustrated from the result of configuring "ACT MIDI Controller", that I have started to write my own ("AZ Controller")... Later I have learned that existing in Cakewalk instrumentation is not bad and can fulfill many wishes, once learned ? BTW I have written in depth documentation about "ACT MIDI Controller" (interleaved with tutorial how to achieve the same in "AZ Controller", but that can be skipped): https://www.azslow.com/index.php/topic,107.0.html

"Generic surface" and "AZ Controller" have no such limitation. Alternatively you can write your own plug-in, Cakewalk Surface API is Open Source under MIT license, "ACT MIDI" controller is also open source. But that is tricky.

Sorry to say, but "ACT MIDI Controller" part is misleading... "ACT" button, "Active Controller Technology" group and "Exclude from ACT" in the options tab have absolutely nothing to do with MIDI learning the controller, BTW most users will want transport buttons "excluded", to use them as transport buttons when playing soft synths or working with FXes. Historically "ACT" has several different meanings in Cakewalk, mentioned options are related to "following context" and "dynamic plug-in mapping". From MPD232 pictures, it has encoders (knobs can be turned endless). For controlling DAW, so for the bank used with "ACT MIDI Controller", it is better to configure them as Inc/Dec2 (and set corresponding option in "ACT MIDI Controller" by Ctrl+Clicking corresponding cells). Banks for MIDI learn inside soft synths better set to finite (not all plug-ins understand encoders and recorded MIDI can have strange results otherwise). All switches to be used for DAW controlling ("ACT MIDI Controller" supports 8 in total, but "Generic" and "AZ" Controllers have no limit) better set to CC Momentary, pads to Note without After-touch. All controls used for DAW must have different CC to avoid troubles, on separate from performance controls channel (to avoid clashes). Controls for using with plug-ins can use standard CC (to use without learning) and "unassigned" CCs to learn (CC numbers are described on midi.org and many other Internet resources). Learning own device (reading the documentation for the device and related software) and learning software in question (in this case Cakewalk documentation, Control Surfaces section) is a good way to make a device work as desired. Randomly selecting/clicking sometimes works, but the result is random....

For the whole project in a DAW (with DAW and plug-ins parameters) the number of things to control is huge. And so the mapping has to be "smarter" then in case of one plug-in. That is what ACT try to target for Cakewalk. For occasional arbitrary control or control of small subset of parameters, MIDI mapping can work. From the video about "MIDI Remote Integration" assistant it is nice from graphics and workflow perspectives. From the end result that is not what some people call "deep integration" provided by custom scripts/programs/presets, which BTW take long time to create (and required MIDI/DAW/programming knowledge). If you need a tip what you should change so it works with User mode Arturia encoders, let me know ?

It depends what encoders send when they are turned. Check if that can be changes in User mode (unfortunately from the documentation seems like not) or try DAW modes (different). "Cakewalk Generic surface" support reversed controls, "AZ Controller" supports almost all possible variations, but "ACT MIDI Controller" does not support that at the moment. Note that in case you want "ACT MIDI Controller" and you will not find DAW mode which works, ask Cakewalk to support Keylab style encoders. I am almost sure msmcleod will help (also "ACT MIDI Controller" is open source, theoretically any C++ programmer can make related modification ?)

Physical encoders technically send relative values, and that is good for DAW control since they are always at "right position" when you change which parameter the same encoder controls. CbB has to be told to use such values, after that it will "get them right". In "ACT MIDI Controller" you need to Ctrl+Click on cell to configure that, in "Cakewalk Generic surface" that is in "MIDI message interpretation" section, in "AZ Controller" it is in the Value Action parameters. Several "ACT MIDI Controller"s assigned to the same MIDI input can course "MIDI leaks". Controller block assigned messages, but these blocks are not summed. So only blocked in the last controller for particular MIDI input messages are really blocked. In case 8+8+8 limit in "ACT MIDI Controller" is a problem, "Cakewalk Generic surface" may be better solution. For ultimate flexibility there is "AZ Controller".

Alternative way: https://www.azslow.com/index.php/topic,178.0.html

I am a bit curious why the first list does not even mention one of the best small factor interface for Windows... I mean RME Babyface Pro FS. It is possible to discuss some UA or Audient sound better/different, but for drivers and features under Windows, RME is still the best. Without extreme tweaking, the latency is also the best. Unfortunately the price is also on top... So if stability, features and latency have no value in your case, there are alternatives. If you are ready to pay extra for mentioned properties, there are no alternatives. ?

The surface plug-in is vs700.dll from https://github.com/Cakewalk/Cakewalk-Control-Surface-SDK/blob/master/Bin/x64/VS700.dll It does not matter in which directory it is, but you need to open command console (type "cmd" in windows start, you will see it, right click and select "run as administrator"), change to the directory with the file (something like "cd C:\the\directory\path") and then run "regsvr32 vs700.dll". Notice in case you get an error.

Latency has little to do with the power of CPU, especially with just one not CPU hungry plug-in like EZDrummer. The system has to be tuned for music, that is in general not easy with notebooks. 7ms RTL should be sufficient for e-drums. If that is just output latency, so toward ~15ms RTL, then it is noticeable (but still playable). Apply some system tweaks and check system latency, there are many guides in the internet. As I wrote, TD can work on lowest or close to lowest settings without death optimization. The only case I couldn't bring TD latency under 12ms (RTL) was on very old Atom based box. On almost 10 years old CoreDuo (Celeron) I could use next to lowest settings. With "power save" power plan any audio driver glitch.

TD11 with lowest settings has RTL 5.4ms (3.2ms output) at 44.1kHz. And that is stable and usable with EZDrummer for sure, assuming your computer can handle that. Yes, that latency is not from top class. But significantly better latency have only interfaces over €200, and you need strongly optimized for audio computer for that. Till you are in €700 category, where 1.5ms output latency is possible with moderate optimization. You write about 1.5ms from €1 interface, on computer which is not even optimized to run Roland driver without problems...

Why are you not using Roland (Edirol) ASIO? from your first post I guess you use e-drums. BTW your audio equipment (umc, roland, build-in) is not capable to work with sub 5ms RTL, I mean 1.5ms you see somewhere is fake. Note that headphones with 3ms RTL are approximately the same as 0 latency with real drums (your head is about 1m away from drums, that is 3ms for the speed of sound).

Yes, (most) extra tracks are buses. The concept of "Track/bus output" in Cakewalk more or less match the concept of "Parent send" in REAPER, so I create folders based on original output. But I still create explicit sends, for the reason explained before. Unlike "simple" converters, I also convert FXes. So converting buses is not just complicate the result ? And you can select buses and delete them quick (requires SWS and simple macro if I remember correctly, have not done that for a while).