[Ardour-Dev] Bad visual feedback for KORG nanoKONTROL 2

[David Kastrup]

Hi,

it's probably been half a year since I brought up this topic and the
question is how to continue here.

I have set up my KORG nanoKONTROL 2 in its default mode (as recommended)
and have switched its LEDs to "externally controlled" with the control
application. That means that its push buttons are one-shot, not
toggles.

This conflicts with the advice in
midi_maps/Korg_nanoKONTROL2_With_Master.map which states:

<!-- This NanoKontrol2 map have some special feature. I use 7 channel for the tracks -->
<!-- and the Nº 8 for the master fader, for that reason, the "bank-size" is set to 7. -->
<!-- Some advice: In the Korg control editor utility (Work fine under wine): -->
<!-- 1 : Set the main "RECORD", "loop" and the track "Solo" "Mute" and "Record" button to toggle-->
<!-- (normally they are on momentary) -->

This advice (about setting controls to toggle) is bad and leads to
unfathomable behavior. Instead one should set the LEDs to externally
controlled.

This works great for the Solo/Mute/Record channel buttons except that
the visual feedback is missing when you load a session with any of the
buttons already pressed: in that case the respective button will not be
lit until you switch the control off and on again (using mouse or the
nanoKONTROL2 itself).

When I use

aconnect 24:0 24:0

to connect the Midi output of the nanoKONTROL2 straight back to its
input, all channel buttons will get lit while pressed, and the same for
"Cycle", "<<", ">>", "Stop", "Play", "Record". However, the only LEDs
that Ardour currently controls are the channel LEDs. All others stay
off. The difference is that the channel buttons are declared as

<Binding channel="1" ctl="16" uri="/route/pandirection B1"/>
<Binding channel="1" ctl="32" uri="/route/solo B1"/>
<Binding channel="1" ctl="48" uri="/route/mute B1"/>
<Binding channel="1" ctl="64" uri="/route/recenable B1"/>
<Binding channel="1" ctl="0" uri="/route/gain B1"/>

etc while the transport controls are declared as

<Binding channel="1" ctl="41" function="transport-roll"/>
<Binding channel="1" ctl="42" function="transport-stop"/>
<Binding channel="1" ctl="43" action="Transport/Rewind"/>
<Binding channel="1" ctl="44" action="Transport/Forward"/>
<Binding channel="1" ctl="45" function="toggle-rec-enable"/>
<Binding channel="1" ctl="46" function="loop-toggle"/>

So it would seem that the uri-style controls echo their state back into
the nanoKONTROL2 while the function/action style controls don't.

In a nutshell:

a) advice at the top of the midimap file(s) is bad. The only change
that's actually warranted over the default is switching LED control to
external instead of internal
b) channel controls S/M/R are not lit initially when a session with set
controls is loaded
c) transport controls are never lit

Now for having the computer (and its rotating disk and fan) in a
different room and just taking the nanoKONTROL2 in the recording room,
not getting visual feedback for the "PLAY" and "REC" buttons is awkward.

Any chance someone will change this given suitable feedback/info, or at
least good pointers at what would need changing here? I can submit a
patch for a) but am somewhat without a clue for the rest.

[Len Ovens]

Post by David Kastrup
So it would seem that the uri-style controls echo their state back into
the nanoKONTROL2 while the function/action style controls don't.

Menu action commands will never give feedback. In general they tell the
GUI to do something.

Post by David Kastrup
a) advice at the top of the midimap file(s) is bad. The only change
that's actually warranted over the default is switching LED control to
external instead of internal

Feel free to create a better map and submit it as a pr on github. I do not
know if it is better to leave the current map alone and create a new one,
or fix the one that is there. I would test it well though. If you have a
button that is a CC, toggle will work better. If you have a button that is
a note then button is fine. A note event is expected to be a note on
followed by note off and toggling is done inside Ardour. A CC is expected
to send the desired state to Ardour and handle it's own toggling. This is
really what the MIDI standard is too. There is a parameter for buttons to
make them act CC like and only stay true while the button is held, but
there is no parameter to make a CC work button like.

Post by David Kastrup
b) channel controls S/M/R are not lit initially when a session with set
controls is loaded

Do you know if they light when banked?

Post by David Kastrup
c) transport controls are never lit
Now for having the computer (and its rotating disk and fan) in a
different room and just taking the nanoKONTROL2 in the recording room,
not getting visual feedback for the "PLAY" and "REC" buttons is awkward.
Any chance someone will change this given suitable feedback/info, or at
least good pointers at what would need changing here? I can submit a
patch for a) but am somewhat without a clue for the rest.

There is already a bug filed for c):
http://tracker.ardour.org/view.php?id=7288

But I am not aware of one for B) at this time. If you are filing one,
please see if banking has the same problem. If not, it may be as easy as
resetting the bank at session load. Please note that I have not looked at
the generic midi control code for some time. So I could be wrong. Working
on the Ardour codebase in this area is, in my opinion, a good place to
start. It is not realtime code.

--
Len Ovens
www.ovenwerks.net

[David Kastrup]

Post by Len Ovens

Post by David Kastrup
So it would seem that the uri-style controls echo their state back
into the nanoKONTROL2 while the function/action style controls don't.

Menu action commands will never give feedback. In general they tell
the GUI to do something.

For me as a user, that's gobbledygook in the first approximation. It is
not clear what makes the uri-style declarations different from the
function/action style declarations here.

But then I am not on the user list, and we are talking about things that
a user is not expected to be changing routinely even though there is
some basic-level documentation (without bothering about such
explanations as you give) there.

So let's skip over how to make the documentation relay this kind of
information better for now.

Instead let's focus on the task. It seems to work on the uri-style
declarations for some reason (including when their state is changed
using the mouse rather than the controller itself), so either we want
uri-style equivalents for the GUI commands.

_Or_ we want separate ways to declare how changes of Ardour's state
(affected by the GUI commands or other means) might get relayed back to
a controller. That would require us to add additional lines to the Midi
maps, for output from Ardour to the controller.

Post by Len Ovens

Post by David Kastrup
a) advice at the top of the midimap file(s) is bad. The only change
that's actually warranted over the default is switching LED control
to external instead of internal

Feel free to create a better map and submit it as a pr on github.

This is just a change in the comment. I assume that I can submit
patches to the list when not having a Github account.

Post by Len Ovens
I do not know if it is better to leave the current map alone and
create a new one, or fix the one that is there. I would test it well
though.

As long as we are only talking about fixing the comments, I don't see
the point in creating a new map.

Post by Len Ovens

Post by David Kastrup
b) channel controls S/M/R are not lit initially when a session with
set controls is loaded

Do you know if they light when banked?

First I'd need to know what it means to have the channel controls
banked.

Post by Len Ovens

Post by David Kastrup
Now for having the computer (and its rotating disk and fan) in a
different room and just taking the nanoKONTROL2 in the recording
room, not getting visual feedback for the "PLAY" and "REC" buttons is
awkward.
Any chance someone will change this given suitable feedback/info, or at
least good pointers at what would need changing here? I can submit a
patch for a) but am somewhat without a clue for the rest.

http://tracker.ardour.org/view.php?id=7288

Ah, ok. I was not aware that this was a general shortcoming. I thought
I remembered that this was different with some Mackie Surface emulation
mode of the Korg nanoKONTROL2, but it's been some time since I tried
that and it might just have been a toggle with LED control independent
of Ardour.

Post by Len Ovens
But I am not aware of one for B) at this time. If you are filing one,
please see if banking has the same problem.

What would banking look like?

Thanks

[Len Ovens]

Post by David Kastrup

Post by Len Ovens

Post by David Kastrup
So it would seem that the uri-style controls echo their state back
into the nanoKONTROL2 while the function/action style controls don't.

Menu action commands will never give feedback. In general they tell
the GUI to do something.

For me as a user, that's gobbledygook in the first approximation. It is
not clear what makes the uri-style declarations different from the
function/action style declarations here.

Functions can possibly give feedback, uri can possibly give feedback,
actions can not. However, Functions do not at this time. (they should, in
my opinion)

Actions are the same as key bindings and as such in the same way hitting
a special key on the keyboard does not make that key light up, requestiong
an action via MIDI (or OSC, or script or whatever) can not have feedback.
This is probably good. The problem is that generic MIDI has not been
updated in the functions area and so people tend to use action requests
where functions would really make more sense. There has been work to
change this for control surface code in general, but the general midi code
has not used the expanded set available.

Ardour has two main parts, the GUI and the audio engine which we normally
refer to as libardour. Libardour has two main points of control as well,
the session controls that affect the whole session such as transport
controls and stripable controls which are a group of similar controls for
each track or strip. The uris refer to the strips, functions refer to the
session and actions refer to the GUI. While it is true the GUI can
effectively control both the session and the strips in some cases, it
makes more sense to control session and strips directly if possible. Using
an action to zoom the editor in or out makes sense, using an action to
control the transport does not make sense.

Post by David Kastrup
Instead let's focus on the task. It seems to work on the uri-style
declarations for some reason (including when their state is changed
using the mouse rather than the controller itself), so either we want
uri-style equivalents for the GUI commands.

commands to the GUI should be phased out all together maybe. Anything that
talks to the GUI is not going to ever get feedback. The GUI is just
another controller. Really, I think what you want is A) better control of
session functions so GUI Actions are not required. B) feedback for these
functions to control your LEDs.

Post by David Kastrup
_Or_ we want separate ways to declare how changes of Ardour's state
(affected by the GUI commands or other means) might get relayed back to
a controller. That would require us to add additional lines to the Midi
maps, for output from Ardour to the controller.

I other controls, the feedback is normally sent back as the same control
it receives, I expect most MIDI controlers would expect the same.

Post by David Kastrup

Post by Len Ovens

Post by David Kastrup
a) advice at the top of the midimap file(s) is bad. The only change
that's actually warranted over the default is switching LED control
to external instead of internal

Feel free to create a better map and submit it as a pr on github.

This is just a change in the comment. I assume that I can submit
patches to the list when not having a Github account.

I am not so sure that advice is wrong actually looking at the file. I
notice that all the controls mentioned are CCs. So if they are not set to
toggle, The user presses the button, the control turns on, the user
releases the button and the control turns off. I would expect that most
people expect the solo to stay on even after they remove their finger.
Test this for yourself.

Post by David Kastrup

Post by Len Ovens
Do you know if they light when banked?

First I'd need to know what it means to have the channel controls
banked.

There are two buttons: bank_up and bank_down, in a session with more than
8 tracks, when bank_up is pressed do the lights on the controler show what
the gui shows for the next 8 tracks?

Post by David Kastrup

Post by Len Ovens

Post by David Kastrup
Now for having the computer (and its rotating disk and fan) in a
different room and just taking the nanoKONTROL2 in the recording
room, not getting visual feedback for the "PLAY" and "REC" buttons is
awkward.
Any chance someone will change this given suitable feedback/info, or at
least good pointers at what would need changing here? I can submit a
patch for a) but am somewhat without a clue for the rest.

Yes there is a good chance someone will change this. The timeline for this
change I am not so sure about. I do not know if anyone else has time to
make these changes. I do have them on my list but I also have other things
I am working on right now. (plus I have a life)

Post by David Kastrup

Post by Len Ovens
http://tracker.ardour.org/view.php?id=7288

Ah, ok. I was not aware that this was a general shortcoming. I thought
I remembered that this was different with some Mackie Surface emulation
mode of the Korg nanoKONTROL2, but it's been some time since I tried
that and it might just have been a toggle with LED control independent
of Ardour.

Using the mackie control part of ardour would be better if you could. It
does have transport control feedback to the surface already. The problem
with most controllers that use generic midi, is that they do not have any
display for the chanels and so their usefulness is impared for channel
operations.

An alternative, if you have a smart phone, is TouchOSC with this map:
https://github.com/ovenwerks/ardour-touchOSC/tree/master/1channel-phn
This has the transport controls with feedback and one channel. Or:
https://github.com/ovenwerks/ardour-touchOSC/tree/master/MonitorTransport-phn
witch also has monitor control and a jog wheel.

--
Len Ovens
www.ovenwerks.net

[David Kastrup]

Post by Len Ovens

Post by David Kastrup
This is just a change in the comment. I assume that I can submit
patches to the list when not having a Github account.

I am not so sure that advice is wrong actually looking at the file. I
notice that all the controls mentioned are CCs. So if they are not set
to toggle, The user presses the button, the control turns on, the user
releases the button and the control turns off. I would expect that
most people expect the solo to stay on even after they remove their
finger. Test this for yourself.

Testing it for myself is exactly _why_ I say that advice is wrong.

Should I prepare a demonstration video?

Post by Len Ovens

Post by David Kastrup

Post by Len Ovens
Do you know if they light when banked?

First I'd need to know what it means to have the channel controls
banked.

There are two buttons: bank_up and bank_down, in a session with more
than 8 tracks, when bank_up is pressed do the lights on the controler
show what the gui shows for the next 8 tracks?

Sigh. It doesn't move into non-existent tracks apparently. I'll need a
bit more time to give a feedback about this one.

Post by Len Ovens
Using the mackie control part of ardour would be better if you
could.

That's what I did at first but I was advised against it. It also had
drawbacks (don't remember right now what they were). The nanoKONTROL
can operate in a number of modes with slight differences. I might take
another look.

Post by Len Ovens
An alternative, if you have a smart phone,

Haven't and won't. Too many time sinks already around.

[Paul Davis]

Just to try to be as clear as possible:

the generic MIDI code used by binding maps (and by dynamically learned
bindings) it not capable of doing what you want.

there's a reason why we have dedicated control code for thing like mackie
control devices, the push 2, the faderport 8 and so on.

Post by David Kastrup

Post by Len Ovens

Post by David Kastrup
This is just a change in the comment. I assume that I can submit
patches to the list when not having a Github account.

I am not so sure that advice is wrong actually looking at the file. I
notice that all the controls mentioned are CCs. So if they are not set
to toggle, The user presses the button, the control turns on, the user
releases the button and the control turns off. I would expect that
most people expect the solo to stay on even after they remove their
finger. Test this for yourself.

Testing it for myself is exactly _why_ I say that advice is wrong.
Should I prepare a demonstration video?

Post by Len Ovens

Post by David Kastrup

Post by Len Ovens
Do you know if they light when banked?

First I'd need to know what it means to have the channel controls
banked.

There are two buttons: bank_up and bank_down, in a session with more
than 8 tracks, when bank_up is pressed do the lights on the controler
show what the gui shows for the next 8 tracks?

Sigh. It doesn't move into non-existent tracks apparently. I'll need a
bit more time to give a feedback about this one.

Post by Len Ovens
Using the mackie control part of ardour would be better if you
could.

That's what I did at first but I was advised against it. It also had
drawbacks (don't remember right now what they were). The nanoKONTROL
can operate in a number of modes with slight differences. I might take
another look.

Post by Len Ovens
An alternative, if you have a smart phone,

Haven't and won't. Too many time sinks already around.
--
David Kastrup
_______________________________________________
ardour-dev mailing list
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Paul Davis]

​
There will be ever new control devices in years to come. Having to
recompile for every single one of them is not a desirable feature, so
the question is what the best way to change that would be.

​I don't see things this way, sorry. I have no interest or desire to make
it possible for people to write control surface support in a non-compiled
lanuage, although that is already possible theoretically using lua.

If you look at Reaper and Bitwig, they have control surface support
implemented in various non-compiled languages (Javascript for Bitwig), and
I don't think it really has a dramatic impact on their control surface
support. To the extent that it does, it also creates a divide between
developers willing and able to work on the compiled aspects of surface
support and the scripted parts, which has its own set of downsides.​

If someone really believes that they can refactor the existing control
surface support, integrate it with a scripted/non-compiled language, and
then implement new surface support with the result: prove me wrong. Untiil
then, it just isn't a high priority item to bridge the gap between "i'm
willing to write software as long as i don't have to compile" and "i'm
willing to compile ardour".
​