azslow3

They always was. They exist like 20+ years, almost unchanged. But as you can guess, I had to have a good reason to write AZ Controller (MPK Mini was my first surface) instead of using or extending "standard" solutions 😉

There are also "standard" solutions, with "Cakewalk ACT MIDI" and "Generic surface"

I don't have TD-50, but even my simpler module works well over USB. Don't forget to use Roland drivers (even so it may work without). The latency of Roland Audio Interfaces is not the best in the world, but ok to play throw Drum VSTs in the DAW (even so you probably will notice the response is slower). MIDI also works fine in terms of latency, when connected throw quality MIDI input (I mean connecting throw "MIDI to USB cable" for $1 make no sense).

Search for GeneralMidiSMFs in: https://legacy.cakewalk.com/Documentation?product=SONAR&language=3&help=INI_Files.5.html

The proposal was to loop MIDI externally and hope SysEx will be delivered (Aux track recording was just to record audio, inside Cakewalk). I have quickly checked, but it seems like that does not work... Several applications can use ASIO, but only some drivers allow that (f.e. RME). Single application can't use multiple ASIO, that is an ASIO creator (and owner) decision. You can wait for Cakewalk implementation, try to use ReWire or other multi-app tricks... or just switch to another DAW with reasonable MIDI routing, find (or create) Ctrlr (or similar) panels for controlling and proceed with music creation. Cakewalk MIDI editing is nice, but (may be apart from Step Sequencer...) I don't think there is something significantly harder to achieve in other DAWs. MIDI routing and processing are definitively not in the list of Cakewalk advantages (only "workaround" style VST MIDI processing and simply no MIDI routing at all). With the DAW I propose you can: open your Cakewalk project and continue or ReWire / ASIO link Cakewalk to use both in parallel. Sorry, I don't have other proposals...

AZ Controller is not communicating with Mackie. You have asked it to control the same parameter and Cakewalk sent feedback to Mackie/iCon. That is not happening directly. So, Arturia -> MIDI -> AZ Controller -> API -> Cakewalk -> API -> Mackie -> MIDI -> iCon. You have controlled fader by controlling the volume (to control the volume of the second track, you need to select the second track in the Strip action for the second encoder).

I just can confirm when msmcleod has already written. Communication between different surfaces is not foreseen by Cakewalk, nor support for multiple MIDI inputs to the same surface. Mackie Control and AZController can do the internally, by only for other instances of themselves. But you can use AZController independently with the second surface, with Action list like "Strip <current>"+"FX (by position or name) (parameter by position)"+"Value (encoder)" for each encoder. In AZ Controller there is no separate INI for mapping (so no separate "C4 mapper" like utility), you assign parameters explicitly within preset (but with this approach AZController technically does the same as Mackie Control with INI). If you want follow track/bus focusing, display currently controlled parameter and value somewhere, implement several "banks" of parameters etc., the preset for AZController will be a bit more complicated (but possible to make).

I was doing exactly that in my test, but for some reason MSSupertLooper was not getting sound. Well, as I wrote, probably I was doing something wrong (or just hit some bug after changing settings without stopping transport... I remember that was "no go" for CW all the time I was using it... ? )

I have tried that, these are inputs. And Cakewalk with some plug-ins support sidechain inputs, so they are shown. I have not managed to get the signal there, but may be I was doing something wrong...

(N)RPNs are implemented using CC numbers you have trouble with. You drive MIDI "throw" plug-ins, when plug-in is capable to use (N)RPN, it will most probably block CCs you mention. But that can be plug-in setting.

6,38,98,99,100,102 (also 96, 97) are used for (N)RPN messaged (https://en.wikipedia.org/wiki/NRPN) If something (plug-in) works with (N)RPN, it will not work with individual CCs which are used to implement them. Cakewalk always was not flexible with MIDI routing. But let be realistic, how are you going to use 3 banks of the same finite controls directly to MIDI, so without catch, even if you remember what all these controls are? ? Well, you can assign CCs from different channels. As long as target interpret them channel dependent way, with that you can avoid assigning "reserved" CCs.

All depends what you want to do, preferences, and the type of the track. In general, you can turn off echo for current track with: Strip <Track> <Current> <Inp. Echo> Value <0> (or <toggle>) For MIDI tracks you normally use "automatic echo" on strip selection ("A" on echo button). With Preferences option MIDI/Playback and Recording/Always echo current MIDI track you just need to select the track to echo it, deselected track echo will be auto-disabled. So you don't need to manipulate Echo/Mute for previously selected track (and really you can't when the option is set). For recording, just check you have "Allow MIDI Recording without an Armed Track" enabled (in the same preferences section). So mentioned Actions make sense for audio tracks (f.e. a button to toggle echo for mic or guitar) and in exotic situation for MIDI tracks, when auto-echo can't be used. PS. unlike ACT MIDI and keyboard assignments with CAL scripts, AZ Controller support feedback (f.e. turning LEDs on controller). So if you plan to use AZ Controller, MIDI controllers with LEDs have advantages. Also note if you don't want/need MIDI controller, AZ Controller also support gamepads and phones/tablets (with OSC apps). The last option can be used for feedback only, f.e. to show the name of current track on the phone (useful if you play away from monitor). It can even speak the track name when you change the selection, useful when you are away from monitor and don't want other display ? PS.PS. "MIDI-Shift" with MIDI assignments is used to inform Cakewalk you use a key for control, f.e. with left pedal as shift you can send 88 commands from 88 keys keyboard. But there was more then one reason for me to write AZ Controller instead of using existing possibilities. BTW you can mimic the behavior in AZ Controller (with unlimited number of Shift/Ctrl/etc. modifiers).

Or with AZ Controller (www.azslow.com). After installation (there are videos) and following "Quick start" (https://www.azslow.com/index.php/topic,9.0.html), you will know how to map a button and what is the Action list for control. The action list for your purpose can be: Strip (Track, <First>, +0 or +<other track, counted from zero>) Function "Select strip" For more buttons, practical is "Dup" button on the Options tab. So you just need to re-learn MIDI and adjust "+X" to define more buttons. You can also do track name based selection. For that you will need to define "Software States Set" in the Options tab, like "Tracks" with States "Drum", "GTX", etc. And then adjust "Strip" Action for the button, changing "<First>" to "Tracks" and then selecting f.e. "GTX". That way your button will select "GTX" independent from the position it has.

It assumes synth MIDI learning is working, and in OP the problem it does NOT work. In addition it introduce yet another mapping (note "I don't use ACT control because it is a bit complicated" in the OP) and it assumes the DAW has good and stable working MIDI routing (Cakewalk tend to mess it). BC Remote Control has mentioned by you disadvantage... Finally, this plug-in cost almost the same as a DAW which can do way more tricks with controlling on its own and in more easy to follow way (since it can use MIDI and directly parameters, including modulating (also by audio)). With third party extensions or scripts it is possible to do even more crazy things there. ? Sorry, I don't say BC plugin is bad or will not work with Cakewalk, I just claim it is not going to help with discussed topic.

https://www.azslow.com/index.php/topic,206.0.html Some controllers show assigned parameters. NI Sxx controllers have displays for that (M32 has tiny display... it also shows current parameter and value, but it is hard to see). Mackie (and compatible) devices have per control displays. And for all controllers you may have a separate window which shows the layout (at least with "Cakewalk ACT" and AZ Controller). So if you have space on monitor (or a dedicated monitor.... or in case of AZ Controller a phone/tablet with TouchOSC or other OSC client installed...), you can have current "labels" for hardware controls.

Softube Console 1 is to control corresponding mixer strip. For "instruments", there are just 2 DAW independent solutions. For both you run the instrument in a wrapper. One is AKAI VIP and another is NI Kontrol. Both work with combined devices (keyboard + controller). AKAI VIP always was just "an attempt". NI Kontrol is well supported. Long time ago there was Novation Automap (with controllers without keyboard), but that line is not continued. All NI controllers use encoders, for me suboptimal for synthes (no "real" feel). But obvious advantage they are always "in sync" with parameters, so you can switch between banks/synthes without problem. If you don't really want the keyboard, there is M32. Even so it has 32 small keys, it has small size and can be used just as controller. They are almost optimal to control all NI plug-ins. Many third party plug-ins also have NKS support. But if you are serious about using Cakewalk and controller, I recommend as first to give your Launch Control a try with AZ Controller. After following "Quick start" (5-10 minutes), you will be able to use "a hint" from my previous post and have your device controlling one particular synth (may be 20-30 minutes for you). You can also try "Startup preset" (there is Youtube step-by-step video), to try "ACT Dynamic mapping" (another 15-20 minutes). After that, you will probably have the answers on following questions: are you really going to use controllers? do you think encoders will work better then finite knobs for you? do you want spend time making good for you layouts/presets or prefer "ready to go" solutions? And then you can start to think which other device to buy (or not...).

"MIDI learn" inside VST(i) is the thing of that VST(i). If you save the project, but the next time you load it the mapping is gone, that means the plug-in is not saving it. So you need to ask plug-in developers what is wrong, host (Cakewalk) has no influence on internal plug-in MIDI mappings. ACT in general is the only option if internal mapping is not saved by plug-in. ACT is using "Parameters" exposed by plug-in, not sending any MIDI to the plug-in. ACT "Dynamic mapping" can be tricky in terms of "remembering" the mapping (configuration XML files can be "corrupted") and focusing plug-in (you don't need it on monitor, but you need select it and "lock" it, then you can close it, focus other plug-in, etc.). An alternative approach is "Direct parameter control". But in your case it is available throw AZ Controller only (Cakewalk own ACT software use it exclusively for Mackie controllers). I must admit that peace of (my) software is not newcomers friendly (even so in practice, when you know what you should do, the mapping will take less then 10 seconds per control... The action list per control is "Rack <required synth> <parameter>" + Value (with default options for launch control), duplicate N times, MIDI learn and change the <parameter> in Rack action for each knob). The advantage over Dynamic Mapping (and MIDI learn inside plug-in) - you can control different parameters of different synthes/fxes at the same time.

Writing a VST3 from scratch is not an easy task... It is simpler to use frameworks, most common is JUCE: https://juce.com/ Also note that as long as you are (A)GPL compatible (your plug-in is open source or you don't distribute it to anyone), you don't have to pay and you don't need Steinberg registration. But in case you want make it close source, even if you don't ask money for it, you need Steinberg registration: https://steinbergmedia.github.io/vst3_dev_portal/pages/VST+3+Licensing/What+are+the+licensing+options.html and some license for the framework (JUCE is not cheap...). But may be you can do the trick with ReaJS (https://www.reaper.fm/reaplugs/ ). Then you can write processing (and GUI) using JSFX (https://www.reaper.fm/sdk/js/js.php, NOT JavaScript). Tons of scripts are already written. ----- But may be you are looking for Control Surface API, that is completely different from VST (and the only way really communicate with Cakewalk). Then you need https://github.com/Cakewalk ----- The only known Cakewalk API for VST3 is proprietary extension for ProChannel modules. It is not documented. There is no full scale DAW API which can be used from VST(3) plug-ins in Cakewalk (it is not REAPER...).

For this controller specialized solutions should work better then Mackie. Original or alternative.

On original Mackie MCU, there is "Control group" section (at least in Cakewalk layout), which switch between Tracks, Buses (AUX) and Mains. To switch from other devices, they have to send corresponding MIDI message (Note 76, 80 or 81). I don't know if Faderport send them (I don't have Faderport).

In year 2024... there is DAWProject ( documented XML format). Studio One is using XML (undocumented). REAPER - way simpler to read then XML own text format (semi-documented). That does not solved the problem with presets for plug-ins, they are in general blobs (even so many use XML, at least in part). So a DAW save FXP/vst(3)preset, but it is up to plug-in to interpret it. Relatively easy "hacking" original identity/version may "force" new plug-in version attempt to parse preset for old version, but the probability of success is strictly bound to plug-ins own presets backward compatibility. Saving project MIDI content as standard MIDI files will not work, the format does not define a possibility to add DAW specific info. It is possible to use "compatible" format, like in Yamaha Style Files, but simpler just use own format.

You first need to understand what NKS is... It is NI proprietary API extension for plug-ins. I have never seen any proposal from NI to integrate it into DAWs (does NI allows that?). It is not "hardware protocol", it is a protocol to communicate with NI software. What DAWs can support is KK (Komplete Kontrol) protocol, used by NI keyboard (throw software, "hardware protocol" is proprietary, not documented and not foreseen to be used by anyone outside NI). That is usually implemented by DAWs "control surface extensions". Possible features are DAW API dependent, but that is true for any controller. If you have M32 or Axx controllers, you can use https://www.azslow.com/index.php/topic,604.0.html. It provides more functionality then "standard" implementations then in other DAWs. I don't have Sxx, so related features are not supported and existing not tested. And I don't know if that will work with new Sonar/Next, currently I have no plans to use them.

DimPro from Sonar X3 times (or early) is plug-in which "will work forever". It requires no online activation (for serial activation in my experience it should be started once as Administrator, it reports "incorrect serial" otherwise). It works under Wine, so it is not even Windows dependent. Rapture Pro is from "online" era.

If "Quick start" is working (you can control track volume), your device is delivering what it should. For the Instrument. Start by looking if you can write an automation for the parameter in question (without controller, just try to add automation line for that parameter or write automation using GUI). If that is possible, you can assign it to hardware slider. If not, (2) and (3) will NOT work (VSTi normally support automations for parameters which make sense to automate, but there are cases when they "forget" to do that). I assume possible. For (2), replace "Strip" Action in the "Quick start" with "ACT" Action, select "Slider 1" in parameters. Try "ACT Learn"... if not working, follow "AZ ACT Fix" instructions I have linked.

The instrument has to support the feature explicitly. When supported, normally you can right click on the control and there is something like "MIDI learn" option. Then you send MIDI, like CC message, by moving/pushing/turning controller and plug-in remembers that. When there is no such option, instrument may response on some particular CCs. Normally mentioned in the documentation for the Instrument. In this case you externally configure the controller to send what is expected. Going with Surface Plug-ins (any of them) require first "MIDI learn" inside surface plug-in and then "ACT Learn" the parameter. As I have mentioned, the second part had quite some bugs in the history of Cakewalk. Check "AZ ACT Fix" utility: https://www.azslow.com/index.php/topic,297.0.html also read https://www.azslow.com/index.php/topic,13.0.html (some comments can be obsolete/fixed, but in general still valid). So using it allow editing mapping without "ACT Learn", but read the documentation, the utility is not intuitive. Note you can use it for control the mapping for any surface plug-in, you don't have to use AZ Controller. AZ Controller is most flexible but also most complicated surface plug-in. There are manual, tutorials and examples. If you master it (will take some time...), you will be able quickly assign your sliders to anything within seconds. To understand how "ACT MIDI" surface plug-in works (and optionally recreate its functionality in AZ Controller), read https://www.azslow.com/index.php/topic,107.0.html From that, even if you can not/will not follow, you will understand why the whole topic is not "simple". Note that ideas behind Control Surfaces in DAWs are almost the same for all controllers and all DAWs. Inside Cakewalk with AZ Controller you can learn these concepts without any background. In some other DAWs for the same you need programming skills (C++ in REAPER, Python in Ableton, etc.), and some DAWs don't have open API in public. So you have an opportunity to look "behind the scene" with relatively small effort.