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

Len Ovens len at ovenwerks.net
Sun Aug 27 08:24:17 PDT 2017


On Sat, 26 Aug 2017, David Kastrup wrote:

> Len Ovens <len at ovenwerks.net> writes:
>
>> On Sat, 26 Aug 2017, David Kastrup wrote:
>>
>>> 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.

> 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.

> _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.

>>> 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.

>> 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?

>>> 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)

>> There is already a bug filed for c):
>> 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



More information about the Ardour-Dev mailing list