Recent Posts

Pages: [1] 2 3 ... 10
MIDIIN2 and MIDIOUT2 should be assigned to AZ Controller and then preset reloaded (or Cakewalk restarted). AZ Controller tells the keyboard "I am there and I know who you are", keyboard switch itself into proper mode and everything should work as desired.

Cakewalk supports several ways to control plug-ins (synths and effects). One of them is "ACT dynamic mapping", "ACT map" displays current plug-in which that approach targets. But that is not the only way. Also Launchkey supports different ways. All that can be a bit confusing at first.
I think I got it.
I noticed that whichever plug in item I clicked on, Cakewalk TTS or the Session Drummer, it showed that as the ACT MAP in the AZ Control utility. SO I guess that meant nothing.
But as I was poking around I clicked on the preset name on top, on accident, and then stuff lit up on the Lauunchkey and the controls started working.

Weird. I did try to load the preset several times. Not sure what I missed before.  :-\
I noticed that the MASTER slider does work to change the volume for the session drummer when I manually play some drum sounds to it.
So it seems that somewhere the commands are going to that rather than to control the main board or whatever you call it.
I see in the AZ Control utility it shows ACT MAP to Session Drummer.

I have no idea where that gets changed.
Thanks for the reply.

See attached photos.
The device does indeed show up as two inputs.
One is named Launchkey and the other is MIDI IN2

They are enabled. When I turn the knob I see the last valve shown there in the AZ Control utility there.

And when I press a button or move a knob I get some action in the MIDI track there.
But maybe as you suggested it is not sending the control data but other MIDI?

I am not sure where I assign something TO the AZ Control.
Unless that is in the Control Surfaces section of the preferences. There I do have the option for the Launchkey or the MidiInb2. Which I've tried each.

It doesn't help that every few years when I decide to tinker with recording that Sonar is changed and the menu layout changes. LOL
Launchkey has 2 MIDI port sets. One for "normal" MIDI (keys, knobs/faders as MIDI controls for VSTi) and another "In Control", for DAW operations. Check you have enabled the second set (in Cakewalk MIDI devices section) and and assign it to AZ Controller. Not sure the name of the ports mention "In Control", can be there are named like "MIDI input 1" and "MIDI input 2".

After changing ports, reload the preset (it tries to activate "In Control" mode on load).

If that does not help, I will write more detailed proposal how to troubleshoot.
So... It's been a while since I installed and setup Sonar with my Novation Launchkey 49 MKII however recently my PC I had this old gear connected to died and I decided to set it up on a laptop instead in my hobby room.

I previously used a PC with a creative labs EMU running in ASIO all that stuff but to my surprise the Sonar is actually working with the basic laptop and laptop USB C dock's audio so I figured I would set up the Launchkey.

So far the Launchkey is working to play sounds with midi instruments but I can not for the life of me get it to run the transport controls.
I was previously able to work the sliders and play/stop/rewind with the Launchkey on the old PC setup but not now.
As shown in the screenshot, I had used the AZCONTROL along with the Launchkey61 plug in back in 2017.
I did get the updated version of azcontrol today as well.

So I do have it installed.
I set up the inputs for the LAUNCHKEY.
I used the plugin tool to add the preset.
And I can see the commands in the AZ Control utility when I move a knob or press a button.
I just can't get it to work the transport control.

And all that said... perhaps I am missing something in the instructions and am not doing one stupid thing that it takes to make it work. LOL

Oh, I did install the latest Sonar from BandLab so that would be newer/different than whatever version I installed some years ago.

Any tips guys?

Attached are some screenshots.
I do see that the AZ Control utility shows something about it mapped to session drummer. So that can be a clue. Maybe something needs to be changed?

Control Surfaces/ACT / Re: How to fix some compatibility with Launchkey 37?
« Last post by virtualpaul on July 15, 2022, 02:53:15 AM »
Thanks a lot for your detailed response.

Although my understanding is fairly limited in terms of DAW controller, DAWs themselves and the various MIDI protocols. 

I wrote a small Yamaha TX7 librarian back in the 90s but the sysex protocol was quite simple and I don't remember any of it... ;)

I will take your suggestion and make music with my setup for now.   While using it I'll try to take notes of what I wish for to make my setup more efficient.  If it would save me more time than I would invest, perhaps I will work on this potential 'upgrade'.

Control Surfaces/ACT / Re: Komplete Kontrol M32 review
« Last post by azslow3 on July 13, 2022, 02:13:00 PM »
Control Surfaces/ACT / Komplete Kontrol M32 review
« Last post by azslow3 on July 12, 2022, 10:57:21 AM »
I have started to use Native Instruments M32 keyboard some weeks ago, and I have decided to share my thoughts about it.
To somehow structure the text, I split into pro and cons.

All the following is absolutely subjective. That is just my own perception and I don't pretend to be an expert.
I am a programmer and hobby musician, who just has fun to play piano, keyboard and other instruments.
When I was a child, I was educated to play (classic) piano.

M32 is a hardware device for Komplete Kontrol and Maschine software. Using it for other purpose is foreseen,
but it seems like intentionally limited by Native Instruments. Unlike S keyboards it in general requires computer
display to operate effectively. Its own small display, while informative, is just too small.
Unlike A keyboards, M32 has small keys with questionable velocity response. Fixed velocity and arpeggiator are easy
to engage. All together, that means it was thought to record melodies or chords for "modern" styles of music.
In advertisement Maschine Mikro controller is often in the near. So, it is for people which like to play melodic
instruments using piano like keys instead of pads. Also M32 has "missing" on Maschine Mikro encoders.

Note that unlike most keyboards/controllers on the market, M32 is not a MIDI nor a USB-MIDI device. It can only be used with
proprietary driver, which creates software MIDI ports and route some messages to/from there. Native Instruments software always works
with controlling part of the keyboard directly, speaking with that driver even when the software is used inside a DAW. Only "performance"
part (keys, pitch/modulation strip, knobs in MIDI mode) is routed "as MIDI".
DAWs work with controlling part using (special) MIDI ports and Komplete Kontrol specific DAW controlling protocol. Till that special mode is activated,
the keyboard speaks using subset of Mackie (Control Universal) protocol.

What is good
  • Accessibility. That is the first time keyboard/controller producer has considered spoken feedback natively. Not all people can use monitors and
    so mouse is not an option for them. Logically, hardware devices with many physical controls are convenient to use for such people. Yet in all decades DAW controllers exist,
    no one till now has considered spoken feedback. The trend was adding LEDs, displays and replacing finite knobs with encoders. But all these new features are void
    for some people since there is no feedback they can perceive. Native Instrument has broken that ice. That is a big point for me, even so I am sighted and so I don't have to use
    that feature myself.
  • 4D knob. On small controllers there is not much space for controls. Giving more functions to a single control is an advantage. 4D knob is not touch sensitive,
    but all possible other functions are there. And important is such case, they can't be activated by mistake. Also the knob has raster when turning and so it is well suitable for
    precise discrete functions like jogging or preset selection
  • LEDs under all buttons. And most of them have 3 levels on hardware side (off, dim, bright). Not only that can indicate current parameter state, it also indicate which
    buttons are currently disabled.
  • Encoders. Finite knobs and faders have advantages in many situations. But in general, when controlling a DAW or switching between software instruments or presets, finite knobs should
    be put "into current position" first and that is annoying. NI has considered high resolution encoders without raster. While using them as "switches" is not good, the resolution
    allows cover full parameter range inside one elevation, yet with sufficient in most cases precision. They are touch sensitive and build-in display shows what you control on touching.
  • MIDI mapping. Encoders can be configured to send different messages throw "performance" MIDI port, when in MIDI mode. With unlimited number of presets and fast switching between them. For recording performance, MIDI CCs are sometimes more convenient then automations since they are recorded as a part of MIDI clip. Also many synths don't support all parameters as automations. PC or other switching (while supported) is hard to use, but for continuous parameters these encoders are perfect.
  • Cakewalk integration. Even so I had to DIY it, I like the result (work is still in progress). That is the deepest integration I have managed so far, for convenient recording from the keyboard without moving hands toward mouse all the time. The key trick was organizing control of not KK based plug-ins (effects, directly inserted synths) and overloading buttons (double press).

What I wish could be there (in hardware)
My guess why these features was not considered you can find in "ugly" section.
  • There is sufficient place for buttons near encoders. (over and under). But there are no buttons there.
  • No LEDs for encoders. I don't mean rings, that requires different construction, makes the device more expensive to produce and since in general computer display is required and build-in display indicate current value, rings will not add much. But designed by Native Instrument DAW controlling schema assumes one strip is "current" and encoders control a block of strips (including current one, btw that is strict). So, which from them is "current"? In other words, which encoder should be turned to change the volume of current strip? Only indication in the DAW or touching all encoders till the right is found give the answer on that question.

What is reasonable
  • The price. For provided features, control types, the number of controls and included software, the device is not overpriced.
  • The layout. Designed as 2 hands controller, everything is placed logically and easy to access. I could put that into "good" section, if not the behavior of pitch and mod strips... They are too easy change unintentionally (see "bad" section)
  • DAW integration. Native Instruments has considered special DAW integration possibility, not only "Mackie compatible" way. It took a while, from locking to explicit set of DAWs throw OSC only control and avoided Mackie compatibility. But at the end they took the right road. Again, the feature could be in the "good" section, but unfortunately some related parts are in the "ugly" one.

What is bad
  • Pitch/mod strips behavior It is clear that in such form factor there can be no real "wheels". But current solution has problems. Especially with pitch strip. It is always "locked" (not configurable) and so once you have touched it, and that is easy to do while operating buttons over it, it will stay in "new" position (without any indication). Also both strips are in absolute mode. Long training is required to smoothly start from "zero". With easy possibility to disable strips, that could be "reasonable" solution. But such possibility is not foreseen.
  • Keys. Plastic quality is ok, the shape and cuts are let say acceptable. But velocity curve is bad. There is a small half way controllable area in the middle velocity region. On both sides from it there are huge gaps in which velocity is very hard to get at all. And then there are "almost silent" and "almost max" regions. Apart from mentioned middle region it is not possible to control velocity predictable. So, you play "silent", "as loud as possible" (both with random changes in velocity) or more or less controlled in the middle. Because of gaps, very small change in hitting can be silent to loud, the result is absolute "unnatural" for piano or other instruments with well controllable and bright dynamic range. Explicit curve correction inside DAW (f.e. AZ Velocity in Cakewalk) can partially mitigate the problem. So I could put all that into "reasonable" list, if velocity curves could be configured in the driver, but there is no such feature (at least not for M).
  • Periodically the driver is frozen. That doesn't happend too often, but once in a while the thing is stuck in the mode it is. Keys continue working, some other controls also. But normal operation can't be restored to device is reconnected (just restarting software does not help).

What is ugly
The following is not about comparison between A and S keyboards. More expensive keyboards have better/more keys, lighting guide, displays and some extra controls. There is no point to complain about that, if someone needs these features he/she should consider upper level devices.

All my following speculations are exclusively about software part, which can be easily changed if Native Instruments decide so.
Somehow I have strong feeling the marketing team has prescribed developers team the following:
  • At no time and no use case our cheaper keyboards should be a concurrent to our more expensive keyboard
  • Every time a user use our cheaper keyboard, independent from the use case, he/she should think "this device is ok, but I had to buy more expensive one"
  • There should be no possibility (and no way to make it) to use any of our devices with foreign software at the same convenience level as with our own software

Why I think so:
  • M and A have no displays. But they allow control most settings in Komplete Kontrol. With computer display in front of the user, that could be almost as convenient as with S keyboards. Could be... but it is not. Komplete Kontrol is not opening corresponding view (automatically). For example, when you Browse instruments, the list of instruments is not expanded, the instrument is in fact selected instantly (as indicated on build-in display), but KK update the name several seconds later. Another example is arpeggiator settings,  corresponding section is not expanded (even so KK knows the keyboard is currently editing arp). Sounds like: "works? yes!; convenient? no, but we have other devices where it is". No indication which strip is "current" and no dedicated "record arm" also smell the same.
  • When not working with Native Instruments software (Komplete Kontrol or Maschine), several buttons are disabled and all controls have limited by driver functionality. In other words "we think our keyboards should do <x> and <y> in DAWs, and nothing else". And just to avoid "smart foreign developers" workaround the limitation, they are: not sending anything when "disabled" buttons are operated; not allow control all LEDs, even for buttons usable in DAWs; not informing DAWs when keyboard is switched into Native Instrument or MIDI modes; not sending momentary (pressed/released) messages; not allow completely control build-in display.

    The controller has 21 buttons, 8 encoders and one 4D knob. In DAW mode:
    • 2 buttons are used for mode switching, 2 for octave switching. That is fine.
    • "Browser", "Presets", "Ideas", "Arp" and "Scale" buttons (6 in total!) are completely disabled. Yes, arp is working inside Komplete Kontrol or Maschine only.
    • left and right buttons are working with shift only
    • not all 4D knob operations distinguish between shifted and not shifted state

    Any good explanation for such limitations, other then my guess?

    To somehow "improve" what the controller does in (officially supported) DAWs, all operations inside Komplete Kontrol are explicitly listed, as well as different reactions of DAWs on the same command (in different context). That makes the list of function fill the whole page  :o

I guess after reading "bad" and "ugly" list you can conclude the review is negative... No, that is not so  :)
This world is not perfect and people tend to speak more about bad sides then about good sides of anything.

For everyone who is newcomer to Native Instruments software, that is a good and effectively cheap start (especially when buying during actions and/or upgrading the software during sales, compared with just buying Komplete bundles without having prior versions nor devices, effective price of that device is bargain). But better try the device before buy, it can be A or even S are better for you from the beginning on.

I think my integration with Cakewalk is good. If you are looking for a keyboard for Cakewalk with DAW controlling functionality out of the box, especially in lower price range, M32/Axx can be good investment.

If there is no interest in NI software (targeting "modern" music) nor controlling Cakewalk, there are other small factor keyboards to look at. Keys (quality and velocity response) in M32 are far from perfect (for me).
Control Surfaces/ACT / Re: How to fix some compatibility with Launchkey 37?
« Last post by azslow3 on July 11, 2022, 12:46:55 PM »
People tend to think MIDI controllers are "simple". They are not, especially when it comes to controlling DAWs.
It speaks "simple" protocol (MIDI), but when a rocket scientist speaks "English" and you understand "English", that does not mean you will understand him.
And probably you will be unable to construct a rocket after that conversation ;)

In "forward" direction the controller inform about user actions (like a button press or rotary position change), that is usually simple (at least for this controller).
In "feedback" direction things are a bit more complicated, I mean for example colors of pads.
Note that both sets of messages depends in which mode the controller is, f.e. in HUI what pads send depends from other keys, colors are fixed but display
(separate) solo/mute on/off, depending from current mode, knobs try to "mimic" endless encoders or faders and send corresponding messages (for encoders
the direction, not absolute value). Also note that HUI in general is using (N)RPN MIDI messages, these are sequences of CC messages with specific values.

But all that still was "simple". Real fun begins when you try to interpret incoming messages, and especially when you try to send something back into controller.
Here you need to select correct "destination" (f.e. the 3d track in WAI, solo) and change it (in case of solo, "toggle" the parameter). Also continuously monitor
DAW current state and form required messages when you want update indication on the device (in your case colors of pads and messages on display).

"Known" protocols (on top of MIDI) can help to hide all that complexity from users. So when controller speaks HUI, it knows what to send when the intention
is toggle solo and what to expect as current solo indication. And that information is known on the DAW side as well. That way device producers can implement
(a part of) HUI and don't care about its support in particular DAW. And DAWs can implement HUI  and don't care about particular controller.

When device is too far away from the device it tries to emulate (like Launchkey and Mackie HUI, not only the number of controls is drastically different, also
hardware types of controls are different), the combination just "somehow works". In practice it is drastically limited.

Another problem is that in particular DAW what HUI does is different. That is why for real Mackie units there are DAW specific overlays for most buttons.
Emulating hardware (Launchkey) just select some functionality they are able to mimic, normally taking only "major" DAWs into account.

Launchkey is designed for Ableton. Yes, it can work with other DAWs. But already chosen protocol, HUI, is an indication that is just an "extra feature".
Also it is by design performance controller, so you select one instrument and work with it. Eventually initiating recording, may be solo/mute neighbor tracks.
But that it, it is not designed to help with mixing nor editing (that is way more convenient to do with encoders, jogger and tons of buttons).


AZ Controller supports all MIDI events, in all combinations, including rather specific encodings.I mean AZ Controller can "understand" everything Launchcontrol sends (in any mode)
and can prepare any message Launchcontrol accept as feedback.
AZ Controller supports almost everything Cakewalk allows for Control Surfaces (the only exception is Cakewalk surround) and even a bit more. That is way less then Ableton
or REAPER expose, but that only Cakewalk can change/extend/fix.
There are complete instructions how to use AZ Controller "factory", with examples and tutorials apart from the manual.
You can find "native" protocol for Launchkey MK3 in the internet (search for Launchkey Programmers Reference Manual).
You have the device.

But now to the first statement. Are you ready to read and understand all that, and then apply the knowledge in practice, just to roll your own preset for this device?
A tip to answer that question... Do you think Focusrite(Novation) will not support additional 5-10 DAWs natively if that could be possible by paying for 1-2 hours to related (pro) developer?

Pages: [1] 2 3 ... 10