azslow3

There is no well defined "Play" nor "Volume" commands any DAW should recognize. The keyboard just sends normal key messages when you press play, you need explain the DAW how that should work. For Keystation: * put transport buttons into Mackie mode (if it is in HUI), see the documentation how * remove ACT MIDI and put Mackie Control, set its input as on your screenshot (no output). Open its configuration (Cakewalk Utilities menu) and set "Disable handshake". The fader works as "MIDI Volume". Some synth recognize it, some not. To control something in the DAW, you can add ACT MIDI, with input set to the first input of Keystation, so the same as keys. And configure the first "Fader" there (see ACT MIDI documentation how). With Nektar you are out of luck, Nektar has not written plug-in for Cakewalk and the device does not use any common protocol (like Mackie). Can be configured, but that is not simple...

From what I know, there is no such functionality in Cakewalk. You can copy FX (and/or settings) from one track/instance to another, so manually " syncing" parameters when required. Or you can copy automations for corresponding parameters. If for some reason your REALLY want sync parameter changes life, you can do this using at least 2 approaches: 1) in case FX in question support MIDI steering and you have some MIDI controller, you can organize MIDI routing such way that both instances are changed by the same MIDI control. That is the only method I recommend for live environment. 2) you can make (project specific) AZ Controller preset which will sync one (or all) FX from one track to another (assuming parameters are automatable, no extra hardware required). Parameters will be synced with some delay (~75ms), the procedure is relatively CPU heavy (all parameters of all plug-ins in question need to be queried as fast as possible to detect changes...). That is why I do not recommend to use it in critical environment.

You need plain Mackie Control (C4, XT, etc. are different devices). You need to disable handshake. And you have to assign correct MIDI ports of Motör to Mackie control (Port 2, so different ports from what you use for keyboard, but they also have to be enabled in MIDI section of preferences to be selectable for control surface).

I use Kimber Kable Hero... Not intentionally, the reason is in fact very sad... But I have seriously tried to listen/measure the difference to "normal" XLRs. So far without success ?

You can check if VST doing what it should (you expect it should). Record/create from scratch a MIDI clip and start manually adjust velocity of particular notes. That way you can be sure what is really sent to VST, effectively excluding the keyboard from the chain. I see your lonely post on NI, which is not answered for more then a week. That can be frustrating...

I have to apologize. I have used the word "driver", but I had to explicitly write "speaker driver". My fault. Thanks for making the test. So, RME works fine with high frequencies, recording them correctly and delivering them correctly to the output. My point was about the next step, what happens with these frequencies in your or my "cheapie charlies" or super "high end" towers? They can be discarded prior speaker drivers or try to drive them. In the last case, they will produce some distortion. Is it "aliasing" as in digital domain or other kind of noise? I have not seen plausible test results so far. But I have seen a test with general conclusion "there is audible distortion" (which is sometimes used as a prove for "better sound" in "high end", when used with 96kHz source... so in reality the sound, while really different, is just worse...). Returning to the topic. If we mix in 96kHz and send output without LPF to our monitors, can we fall into the same "trap" as "high end" lovers? So we listed the mix with some extra audible distortion produced by monitors from existing (and may be even real world correct) high frequencies?

Mackie is a separate surface plug-in. Instantiate it and point to port 3. In the configuration disable handshake. If Code really sends Mackie transport, it should work. You still can use something else for other ports. Note that Mackie plug-in completely block specified port MIDI, so do not point it to normal ports. Also it sends feedback, that can trigger MIDI loops if configured incorrectly (on the keyboard side or setting wrong output port for Mackie plug-in).

Since no one has mentioned that... Audio interfaces can work at 96kHZ or more, so with 48kHz waves, for input and output. But most (exceptions?) drivers physically can not reproduce more the 21kHz. The result is the same as with audio interfaces working at lower rates: analog chain can have LPF so what can not work is cut or follow "lets hope the user knows what he does" scenario. I can not find the links now, but I have seen some tests in the Internet. The same kind as in this thread videos, but checking what really comes out of monitors/headphones when the signal includes over limit frequencies.

I may be see it wrong... But if everything in a project is 48kHz and there is just "saving" into 96kHz... I expect all frequencies above 24kHz should be strictly zero... no? ? I mean it is like using 64 bit depth for recording (from 24 fixed point interface > maximum resolution of any interface), does not make sense at all.

Check you have no "MIDI loops". So Keyboard->Cakewalk->(Something)->Cakewalk->(Something) and so on. It can loop throw "MIDI out" of some synth, external software loopback device or (rare) not properly configured MIDI keyboard. MIDI configuration in Cakewalk and projects could be "bugged" when you have attached Code 61, especially if you have connected/disconnected it (and/or Oxygen) to different USB ports or/when Cakewalk was running. In such case cleanup MIDI devices in Windows Device manager and delete MIDI related .INI of Cakewalk (in Windows Explorer search for TTSSEQ.INI in %appdata%).

I draw the curve such a way that I can control resulting velocity. I mean if your finger can (predictable) produce 30/70/100/127, it can "adopt" to concrete synth. F.e. on my tiny AKAI I had to rise lower velocities, so 1-50 is translated to ~30-60. Then 50-110 is translated to 60-120, 110-127 to 120-127. I have hard time to control lower part, so I "compress" it. Middle I can control fine. For full velocity I have to hit too hard, so I compress it again. Try to hit a key the way you think it should produce pp,p,mf,f,ff. Then put the points which have corresponding MIDI velocity, instead of what the keyboard sends in that case. Then "connect" these points smoothly. BTW NI M32 I could test recently had worse mini keys in respect to velocity for me. Arturia and Akai mini keys was connected in parallel, so that was synth and my momentary feeling unrelated. I have M-Audio 88 Pro, nothing can be done with velocity to make it "good" (not with build-in curves, not with MFX), but MFX can make it less horrible. So do not expect perfect result, sometimes software can not "fix" hardware.

You are welcome. MIDI should be converted, effects as well. Copy to different folder, with all audio, is required to keep the original project untouched after you start edit it with REAPER. In some cases I have decided a bus match the spirit of "a folder" in REAPER. But sometimes that is unclear. In most cases simply "re-arranging" tracks after conversion should not change the sound since routing is converted explicitly.

I always first use Google and switch to images. The back panel of any device is normally immediately visible. I also do not start with manuals ?

CbB is not dead and ReaCWP converts almost every feature which exists in both DAWs (many Sonar/CbB features does not exist in REAPER or have completely different approach, f.e. comping). So there is no active development (no reason for it). But I (the developer) am still alive ?. So if you find some bugs, you can PM me.

OP has mentioned controllers in question: "M-Audio Keystation 32" Why suggest MIDI outs? ? Identical keyboards work in general. MIDI devices are identified by number (at least MS write so), so it is technically possible open several identical keyboards, as long as Windows see them (and I guess it see them). So claiming there is "no way" is strange. But one problem is going to persist, even if that is done: Windows can re-arrange MIDI devices, and there will really no way to find which was "the first" and which was "the second" last time. USB devices have complete connection path, but I do not know any method to map MIDI device id (at least in old MS MIDI API) to possibly existing USB device ID.

You can try to draw your own curve: http://www.azslow.com/index.php/topic,275.0.html

If you have MIDI I/O and configured it, pointed Mackie Control and disabled handshake, with some luck it should work. Is it not working yet? I mean you do not have to reinstall/clean/delete if it works ? I do not have the device, may be you should do something on the device or in KK to enable Mackie mode. Making "normal" integration using native MIDI mode of KK is not difficult. But I do not have the device and no one with device has done that yet (for Cakewalk). BTW you have payed for keyboard ~$200. If you have Melodyne Studio, you have payed even more. And any half way good acoustic instrument is much more. So I do not understand your comment about $80, I think unlike many other good reasons, such money are absolutely irrelevant when choosing the DAW...

These two devices serve completely different purpose. One is primary for steering specific channel strip, other is primary for controlling 16 levels. FederPort16 when comparing to MCU + XT: pro: is cheaper, is smaller cons: has less controls (less buttons and just one encoder). So some foreseen for MCU functions are emulated with button combinations (note that MCU already has 4 modifier buttons). Do not expect absolute integration as with Studio One, it is more like "fallback to MCU for compatibility with other DAWs" then MCU clone. Spend $5 for TouchDAW and try it with a tablet. Real Mackie (like) device will be "real" and more stable, but functionality will be the same. So you can kind of test before buy. You can not be wrong with Softube, Mackie, Presonus or X-Touch Mini. But it can happened they do not do what you want or you do not like the size/controls feeling/etc. In case you can, visit some place where you can physically touch particular device (or use delivery service with free return policy), even disconnected. F.e. I could not predict I hate Novation knobs, X-Touch knobs are a bit "hard", NI knobs have no raster, etc. before I have really touched all of them. Even in case something does what you want, if you hate touching it you probably will hate using it.

Note: theoretical only (I do not have any of these keyboards). The confusion comes from different implementations in different series and different Komplete Kontrol software. In general, DAW integration (of all kind) for all NI keyboards is done in the software. The hardware (the keyboard) communicates with NI driver/software special/proprietary way. * S-xx MK1 was supporting Mackie transport from the beginning (but "Disable handshake" was already needed) * S-xx MK2 WAS NOT supporting Mackie or any other MIDI based DAW integration (they was using OSC) * A-xx WAS NOT supporting Mackie at the beginning Starting from KK 2.1.3, NI has returned MIDI based DAW control (at least for) S-xx MK2 and A-xx. Primary "protocol" is NOT Mackie. And so other DAWs deep integration modules are not Mackie. But NI has also implemented some part of Mackie, at least many users had success with transport. ---- You should have "Komplete Kontrol A DAW" as INPUT and OUTPUT. And it should be enabled in the Cakewalk MIDI devices and then assigned to Control Surface Module (f.e. Mackie Control, with "Disable handshake"). These MIDI IO are provided by software (more precisely by NIHostIntegrationAgent service). If you do not have them (both), you need to solve that first (reinstall Komplete Kontrol, cleanup Windows MIDI devices, cleanup Cakewalk MIDI INI file, etc.).

In some cases ReaRoute can be used instead.

Cakewalk does not internally support MMC for controlling transport from surface. That can be configured, but the same way as other messages. ACT MIDI supports 8 buttons (+1 to switch function of these 8). So you can assign transport buttons to these "buttons" and configure them to do transport actions (what buttons do is configurable in the options tab). User manual and related videos explain how to do this. But you can configure 8+1 buttons in total, not more. Generic Surface supports transport and additional controls (including buttons). But it does not support arbitrary commands and control banks. Both does not support feedback (button LEDs, encoder rings, fader movement, etc.). If your device supports Mackie mode, you can try to use it with Mackie module. The functionality depends from the level at which device emulate Mackie. If all that can not do what you want, for one or another reason, you can use AZ Controller. Configuring it for your needs can take some time. That depends from the device and required functionality. If you have simple device without feedback and just want strip controls + transport buttons, that will take just several minutes with Startup preset. If you have complicated device with feedback and/or want tricky functionality, that can take weeks. To get an idea what can take weeks, check the documentation for preset created by one (smart) user: http://www.azslow.com/index.php?action=dlattach;topic=301.0;attach=429

You can start by checking USB (and other devices) power options, but to get general picture check latency. There are many guides, my own is http://www.azslow.com/index.php/topic,395.0.html Search Latency Monitor spoiler. Here you will find names/links to some utilities. F.e. throttlestop will show you current frequencies and C states distribution. Also check what is working in background, Windows is "smart" and can start some activity when it think the system is "idle". I have bad luck, APM staff on DELL notebooks can hang for several ms. But disabling all extra activity and disconnecting from the net allow using it with relatively low buffers. You can also find guides how to enable "Ultimate Performance" plan. Note that in the standard "High Performance" plan many power saving options are still on (not only for CPU). And standard windows configuration does not show you all options in power plans (see the link toward the end of my list).

Do you mean "ACT Learn"? It was broken for decade... I am not sure how A300 could work for you, if it was the only surface that could be some luck. But once you use more then one surface (so f.e. A300 and AZ Controller), both mapping files are in use (one is "generic" and another has mapping per surface). And that has no chance to work as long as one of them (usually per surface) is broken (once it is broken it will be broken till fixed). Use AZ ACT Fix. It can detect problems in these files and sometimes fix them. And it can make backups / restores when something can not be repaired.

Custom mapping is an alternative to ACT learn. The result is the same, just "learning" is different. msmcleod has Mackie devices and continues development, f.e. see If you want write volume automations and/or want display on controller, devices with touch sensitive fader(s) is the way to go. So Mackie (compatible) or single strip (with one fader). You can try the functionality for cheap, f.e. with TouchDAW on Android/iPad tablet (if your computer is not completely offline). Otherwise you can be good served with Mini or BCR-2000 (depending from the number of parameters you want control directly without switching layouts and available space on the desk). BTW I forgot to mention Softube Console 1. It has native Cakewalk integration (but target Softube/UA plug-ins only).