Arturia Keylab transport controls
-
- KVRer
- 20 posts since 16 Jul, 2019
Hi folks,
Has anybody managed to set up their Arturia MIDI controller with MuLab? If so, I'd like to know how you did it. I'm having a hard time getting it to work, and couldn't find anything in this forum or on the Arturia forum either.
Basically, I can choose if the section which Arturia calls the 'DAW Command Center' adheres to the Mackie HUI or the Mackie Control system. This section has the normal commands like 'play', 'stop', 'record', 'fast forward' and so on.
I know I have to define the shortcuts in MuLab, but when I try to do it, all the buttons register as Controller 47. I have attached a picture, the first one is the 'stop' button, the second one is the 'play' button. If I run a track, the 'stop' function actually works, but I can't figure out why, if I press the 'play' button, it also registers as CTRL 47. I can't edit the actual CTRL value on the keyboard, all I can do is select the HUI protocol (which makes sense, since it should be a predefined set of values).
I would appreciate any help you can provide, I'm a bit stuck with this.
Thanks!
Andy
Has anybody managed to set up their Arturia MIDI controller with MuLab? If so, I'd like to know how you did it. I'm having a hard time getting it to work, and couldn't find anything in this forum or on the Arturia forum either.
Basically, I can choose if the section which Arturia calls the 'DAW Command Center' adheres to the Mackie HUI or the Mackie Control system. This section has the normal commands like 'play', 'stop', 'record', 'fast forward' and so on.
I know I have to define the shortcuts in MuLab, but when I try to do it, all the buttons register as Controller 47. I have attached a picture, the first one is the 'stop' button, the second one is the 'play' button. If I run a track, the 'stop' function actually works, but I can't figure out why, if I press the 'play' button, it also registers as CTRL 47. I can't edit the actual CTRL value on the keyboard, all I can do is select the HUI protocol (which makes sense, since it should be a predefined set of values).
I would appreciate any help you can provide, I'm a bit stuck with this.
Thanks!
Andy
You do not have the required permissions to view the files attached to this post.
-
dreammachine_nl dreammachine_nl https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=30537
- KVRist
- 60 posts since 23 Jun, 2004
I don't have this controller, but you might try this:
Go to 'Shortcuts' -> right click your 'Controller 47' shortcut;
Choose 'Define Value 2 Range';
Set 'Min Value' and 'Max Value' to 67 for your Stop button (= button pressed) and set Min/Max to 68 for your Play button or try values 3 for Stop and 4 for Play (= button released).
See also: https://community.cantabilesoftware.com ... ind/625/15
Go to 'Shortcuts' -> right click your 'Controller 47' shortcut;
Choose 'Define Value 2 Range';
Set 'Min Value' and 'Max Value' to 67 for your Stop button (= button pressed) and set Min/Max to 68 for your Play button or try values 3 for Stop and 4 for Play (= button released).
See also: https://community.cantabilesoftware.com ... ind/625/15
-
- KVRer
- Topic Starter
- 20 posts since 16 Jul, 2019
Thank you very much for your response. This works for play and stop.
I've been following the link you have posted and managed to find out a few more values (like fast forward / rewind).
I thought I could sniff out the remaining values by using an event monitor.
The strange thing is - if I press one of the buttons on my keyboard, in the shortcuts menu they register as CC# 47.
But in the event viewer any button I press registers as CC# 15.
To some extent, this ties in perfectly with the information in the link you have sent me. The Mackie HUI protocol uses CC # 15 to address the 'port' and CC # 47 to determine if it's switched on or off.
What I can't understand is why the event viewer only shows CC # 15. Clearly CC # 47 is being sent as well.
So CC # 47 set to a value of 68 is play, and it works - why does it not show up in event viewer? (Just to confirm, I have set my 'MIDI input channel targets' so that MIDI channel 1 targets the event viewer).
Another question, my Arturia keyboard send a continuous stream of CC changes, they always have the same pattern:
CC # 99, 98 , 6 and 38
Just out of curiosity - what are these messages? Any idea?
So in the picture below you can see the mentioned sequence (three times), and then me pressing one of the buttons: CC #15 with a value of 15. But what I'm really interested in is CC # 47 to determine the value I have to set for the other buttons.
I've been following the link you have posted and managed to find out a few more values (like fast forward / rewind).
I thought I could sniff out the remaining values by using an event monitor.
The strange thing is - if I press one of the buttons on my keyboard, in the shortcuts menu they register as CC# 47.
But in the event viewer any button I press registers as CC# 15.
To some extent, this ties in perfectly with the information in the link you have sent me. The Mackie HUI protocol uses CC # 15 to address the 'port' and CC # 47 to determine if it's switched on or off.
What I can't understand is why the event viewer only shows CC # 15. Clearly CC # 47 is being sent as well.
So CC # 47 set to a value of 68 is play, and it works - why does it not show up in event viewer? (Just to confirm, I have set my 'MIDI input channel targets' so that MIDI channel 1 targets the event viewer).
Another question, my Arturia keyboard send a continuous stream of CC changes, they always have the same pattern:
CC # 99, 98 , 6 and 38
Just out of curiosity - what are these messages? Any idea?
So in the picture below you can see the mentioned sequence (three times), and then me pressing one of the buttons: CC #15 with a value of 15. But what I'm really interested in is CC # 47 to determine the value I have to set for the other buttons.
You do not have the required permissions to view the files attached to this post.
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
NRPM messages with data. The MIDI Protocol allows any one to define their own messages. NRPM stands for "Non-registered Parameter Message". The MSB and LSB combine (MSB * 2 ^ 14 + LSB) to give the parameter number. The Data Entry MSB and LSB combine (same way) to give the parameter value.
-
dreammachine_nl dreammachine_nl https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=30537
- KVRist
- 60 posts since 23 Jun, 2004
In Mulab, the shortcut intercepts whatever message (CC or note) is assigned to this shortcut. So your CC47 on midi channel 1 (and hence all other "value 2's" of CC47) will not be passed through anywhere else in the program.Rhinetone wrote: Sat Apr 04, 2020 11:18 am What I can't understand is why the event viewer only shows CC # 15. Clearly CC # 47 is being sent as well. So CC # 47 set to a value of 68 is play, and it works - why does it not show up in event viewer? (Just to confirm, I have set my 'MIDI input channel targets' so that MIDI channel 1 targets the event viewer).
.....then me pressing one of the buttons: CC #15 with a value of 15. But what I'm really interested in is CC # 47 to determine the value I have to set for the other buttons.
A solution in Mulab could be to simply first delete all your CC47 shortcuts; then repeat your steps with the Event Viewer (CC47 should be listed now) and figure out which messages belong to which buttons. When you're done, add all your shortcuts at the same time.
Or you could use another program of course, like Midi-Ox.
By the way, in the special case that you might need a CC47 message (or whatever message/note was blocked by a shortcut); just send that message via a different midi channel (2-16) and it will be received anywhere else in Mulab.
-
- KVRer
- Topic Starter
- 20 posts since 16 Jul, 2019
Thanks for your response, but what do these messages actually achieve and why are they being sent?pljones wrote: Sat Apr 04, 2020 11:17 pm NRPM messages with data. The MIDI Protocol allows any one to define their own messages. NRPM stands for "Non-registered Parameter Message". The MSB and LSB combine (MSB * 2 ^ 14 + LSB) to give the parameter number. The Data Entry MSB and LSB combine (same way) to give the parameter value.
I realise this is more an Arturia question, but I'm curious to understand why the controller is constantly sending data.
-
- KVRer
- Topic Starter
- 20 posts since 16 Jul, 2019
Thanks for your input, much appreciated.dreammachine_nl wrote: Sun Apr 05, 2020 6:41 am By the way, in the special case that you might need a CC47 message (or whatever message/note was blocked by a shortcut); just send that message via a different midi channel (2-16) and it will be received anywhere else in Mulab.
Yeah, in the end I used MidiOx to sniff out the values, but here's the next problem.
The HUI protocol uses CC # 15 to address the 'port' and then CC # 47 to determine if the button is pressed or not.
As it so happens, with some of the buttons my keyboard sends the same CC # 47 (but a different CC # 15) - so the function is the same since MuLab responds to the CC # 47.
I couldn't figure out a way in MuLab to set a shortcut to respond to two consecutive CC numbers before executing the shortcut. Is there a way to do this?
As an alternative, I investigated the option to use the Mackie Control protocol (as opposed to Mackie HUI). Again using MIdiOx I have found that in this case, the buttons send note on / off commands.
It works, but now I execute the shortcut whenever I hit the assigned key on the keyboard.
Arturia actually have implemented a secondary 'virtual' MIDI port on their controllers. I have one physical USB connection, but two MIDI ports, both are recognised by MuLab. The keyboard sends on port 1 and the control buttons send on the other port.
In MuLab I can define the MIDI input channel targets, but I would need to split based on the port. Is this possible? I can't split it on the keyboard, both seem to send on the same channel, so I can't make the keys send on Ch 1 and the buttons on Ch 2. So what I would like to do in MuLab is that Port 1, Ch1 goes to the focused module, and Port 2, Ch 1 activates the shortcuts.
Any ideas?
Again, many thanks for your help, it's very much appreciated.
-
dreammachine_nl dreammachine_nl https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=30537
- KVRist
- 60 posts since 23 Jun, 2004
You're welcomeThanks for your input, much appreciated.
As far as I know, this is not possible. A shortcut (actually the midi 'listening' mechanism) responds to the single last midi message you've sent. If you could somehow interrupt or delay the midi stream sent by the keyboard, it may be possible: you could use for example Midi-ox and Midi Yoke (virtual midi patch cable) to temporarily filter out the CC47 message and set all other shortcuts which are based on CC15. Patch path: Arturia -> Midi-Ox -> Mulab, but it will be a bit tedious.I couldn't figure out a way in MuLab to set a shortcut to respond to two consecutive CC numbers before executing the shortcut. Is there a way to do this?
Very good, I already suspected this was possible, but I didn't know which version of the Keylab you had. After some quick googling, I found that the older versions didn't support this? And the new Keylab Essential could do this? Not important anyways, because you said:As an alternative, I investigated the option to use the Mackie Control protocol (as opposed to Mackie HUI). Again using MIdiOx I have found that in this case, the buttons send note on / off commands.
It works, ..
Yes, to make it work the transport buttons should be on a different channel than the keys.but now I execute the shortcut whenever I hit the assigned key on the keyboard.
No, a split based on midi input ports is currently not possible in Mulab. I think it is somewhere on the wish list. Mulab's midi inputs merge all midi. Only a split based on (16) midi input channels is possible....but two MIDI ports, both are recognised by MuLab. The keyboard sends on port 1 and the control buttons send on the other port.
In MuLab I can define the MIDI input channel targets, but I would need to split based on the port. Is this possible?
Are you sure? You have the Keylab Essential? I quickly scanned the manual, there is indeed a global parameter (user) for the midi channel, but faders, drumpads, etc. can have different channels I believe. A keyboard split point and midi zones are also possible, so it must mean that certain midi key zones can correspond to different midi channels.I can't split it on the keyboard, both seem to send on the same channel, so I can't make the keys send on Ch 1 and the buttons on Ch 2.
As mentioned above: not possible. If the Arturia transport buttons and keys can not send on different midi channels, you'll have to fall back on the solution with HUI protocol and CC15/CC47 (with the temporary help of Midi-Ox).So what I would like to do in MuLab is that Port 1, Ch1 goes to the focused module, and Port 2, Ch 1 activates the shortcuts.
One last Mackie protocol (with notes) suggestion which I personally wouldn't prefer, but you could also permanently use Midi-Ox in the patch configuration: Arturia -> Midi-Ox -> Mulab, to let Midi-Ox do some midi port and midi channel mapping.
Cheers, TDM
-
- KVRer
- Topic Starter
- 20 posts since 16 Jul, 2019
Thanks for the confirmation. Would be good if it could be added at some point.No, a split based on midi input ports is currently not possible in Mulab. I think it is somewhere on the wish list. Mulab's midi inputs merge all midi. Only a split based on (16) midi input channels is possible.
Yes, I have the KeyLab Essentials.Are you sure? You have the Keylab Essential? I quickly scanned the manual, there is indeed a global parameter (user) for the midi channel, but faders, drumpads, etc. can have different channels I believe.
I should have been more specific about not being able to assign different channels. You are right, I can freely assign MIDI channels to the keyboard, pads and faders. But the DAW controls always send on Port 2, ch 1.
So the workaround I'll settle for just now is the following. I'll have Midi ch 1 for DAW Control and then reprogram pads, faders and keyboard to ch 3 (ch 2 is already going to an external hardware synth via the physical MIDI out).
This should do the trick just now, although I would have preferred to keep the keys etc. on ch 1.
But this is workable.
Many thanks again for your input, it was a great help!
