MIDI input device and event is lost after first closing the InputConfigWizard MF 9.7.1.1

[Gamma36]

I think I may have found a config bug in MF 9.7.1.1

My nanoKontrol2 is detected, and button events and rotary event can be logged. Auto-input Scan worked for channel 1 Solo button, assigned to letter A. MobiFlight responds and issues the letter press. All good stuff, with great potential. I have 8 channels of [1 rotary axis, 1 slider axis, 3 buttons each with an LED] which can do a lot of useful functions.

First scan it is like this:

However, the device input is lost immediately after closing the form and then opening it:

The input config continues to run ok, but it cannot be viewed or edited.

On a positive note I'm quite excited how the nanoKontrol2 can perform in a cockpit.

[Koseng]

hi, this is not how it is supposed to be. That is the default behavior if no configuration for the specific midi board is loaded. If the correct configuration is loaded you should get all possible devices in the device combo box. And there is a specific configuration for nanoKontrol2.

Maybe your nanoKontrol2 identifies differently then expected. Please add a log file to the issue.

To create the log file:

• In Mobiflight: Extras->Settings->Logging enabled
• Restart mobiflight
• Get the log.txt from the mobiflight directory and add the file to the issue.

Thanks!

[Gamma36]

Koseng,

I didn't know I had to load a nanoKontrol2 configuration. Nor do I know what a MIDI configuration is or where it should be.

I had spotted 5 .json files for MIDI devices in the install; I thought that indicated that MIDI support was included.

Please advise.

Regards Paul

[Koseng]

Hi Paul,

you do not need to load a nanoKontrol2 configuration. This should happen automatically. For some reason it does not happen and we do need to find out why.

Therefore I need the log-File. Please activate logging in mobiflight and attach the log.txt file to the github issue. Then I can diagnose. Also set log level to debug.

• In Mobiflight: Extras->Settings->Logging enabled. Log Level to debug
• Restart mobiflight
• Get the log.txt from the mobiflight directory and add the file to the issue.

Thanks.

[Gamma36]

Koseng,

Attached is my log file set to debug.

I'm a retired C++ developer - back in 1993 I created MusicSoft and wrote and sold a guitar music program called "Band-it". It could read MIDI files and convert them to guitar tab and standard notation, which could be played or printed. Users could also enter notes to build up songs. Half my customers were guitar teachers - there was nothing else affordable on the market for printing guitar music, which they found invaluable for their business.

Back on Mobiflight I can see the nanoKontrol2 has been loaded. The good news is that MIDI events are getting though - over to you now!

I started MB, I created an input event, pressed "Scan for input", on the nanoKontrol2 I pressed one button then moved a slider. Then shutdown.

Looks like you might need one or two extra debug messages.

Cheers

log_nanoKontrol2.txt

Paul

[Gamma36]

It looks like the critical problem is here:

06/02/2023 15:56:46(508): InputConfigWizard.ModuleSerialComboBox_SelectedIndexChanged(): Problem setting input type ComboBox. CC 1_34 06/02/2023 15:56:46(509): InputConfigWizard._syncConfigToForm(): Exception on selecting item in input type ComboBox. CC 1_34

This time I did select nanoKontrol2 as device type. There are multiple InputConfigWizard exceptions - I do hope its not the dreaded C++ string reference copying nonsense.

My experience is use a good C++ string object, like the MFC CString(), with a good selection of operators for all the insane string forms OR struggle forever with a hopeless mess.

The great thing about CString is that internally it is UNICODE, which is essential for certain languages. Also its data is static until destructed. Taking CStrings as parameters forces a copy, which is reliable.

Best of luck Paul log.txt

[Koseng]

As I suspected your nanoKontrol2 Board identifies differently as the board we had before. Please extract the additional config file from the attached zip and copy it to the Mobiflight/MidiBoards folder. Then restart Mobiflight and you should see all devices in the combobox.

Also please read https://github.com/MobiFlight/MobiFlight-Connector/wiki/Midi-Boards.

nanokontrol22.midiboard.json.zip

The error message you mention can be ignored.

[Gamma36]

Mobiflight now shows the device correctly, and all the controls are visible:

Scanning for inputs captures potentiometers, buttons and sliders.

However:

1. Scanning sometimes requires two button clicks. I suspect there is a timing issue.
2. Channel 1 slider is scanned as "CC 1_12".
3. With log file and Run mode, half of all button events are lost.

Press: nothing logged Release: Release is logged Press : nothing logged Release: Press is logged Press: nothing logged Release: Release is logged Press nothing is logged Release: Press is logged ...this repeats forever

Log file will not help, it looks ok but the missing events are not listed. You have to trust me and verify yourself.

[Koseng]

hi, since the device identifies differently, maybe the default configuration is also different. Please post a screenshot of your midi board configuration with the KORG KONTROL Editor. Link you can find here: https://github.com/MobiFlight/MobiFlight-Connector/wiki/Midi-Boards

Thank you.

[Gamma36]

Koseng,

Here it is:

I don't know why slider 1 is CC number 12. Perhaps they were avoiding CC#0 which is bank select.

I checked the Korg website, there is a picture that shows Slider 1 as CC#0, so I set Slider 1 to #0 with the editor and Mobiflight recognises Slider 1 correctly.. I know that 2 nanoKontrols can run together for 16 channel control. If you look at the MIDI values, the first potentiometer is 16 which allows space for a second nano to use 8 to 15 for 8 extra sliders. Also every group has a gap of 8.

So CC#12 for Slider 1 was a corruption, somehow.

The bug of losing half the Korg button messages is still there. However the 5 transport control buttons and 3 marker buttons show as two events in Mobiflight, press and release.

-Paul

[Koseng]

Hi Paul,

sorry now I had time to come back to this. I cannot fully test by myself, because I don't own a nanoKONTROL2.

I looked at the possible Korg Kontrol Editor configurations and I suppose the buttons are configured to "Toggle-Mode" and not to "Momentary-Mode".

Please check that all your buttons are configured as shown in the screenshot. Behavior must be "Momentary" and Off value must be 0. Does it work then?

If it still does not work, please write down which buttons you pressed exactly and attach the log file.

Thanks a lot!

[Gamma36]

Koseng,

I discussed MF OnPress/OnRelease on Discord. As you know MF can be programmed for toggle events, states and actions. Hardware wise a push button can be toggle e.g. toggle Gear up or down, but it can also be "action" so that each push does the same thing e.g. push to talk.

For Korg Kontrol 2, the ideal button behaviour depends on the intended design; there is no right or wrong. Until now I never knew each of the 34 Korg buttons can be momentary or toggle.

The confusing behaviour is "Scan for Input" only responds to an OnPress event, it will not respond to an OnRelease event.

So that sort of wraps things up. What should be done about commiting the .json files? The file starting with

"$schema": "./mfmidiboard.schema.json", "InstanceName": "nanoKONTROL2",

is the one that works and it looks suitably generic. The ID in the default file does not make sense to me.

Many thanks.

[Koseng]

Hi Paul,

Mobiflight expects one specific configuration of the midi board so that everything will work as intended. And this configuration must be set with the Control Editor. Probably we should provide ready to load files for the midi editors.

Could you please answer:

1) In the korg kontrol editor, have button behaviors been set to "Toggle"? 2) If you put the "Button Behavior" to "Momentary", does it work then in Mobiflight?

And I will submit the additional .json file.

Thanks.

[Gamma36]

The Korg default is:

Transport like Pause, Play, Record, Forward, Backward are Momentary. OnPress then OnRelease.

Channel buttons like Solo, Mute, Record are Toggle

That makes sense to me. LEDs show each channel's Solo, Mute and Record states, which persist in time. Transport controls are immediate, timing could be synced to OnPress or OnRelease as per application or a timing track, aka click track.

Horses for courses. For a cockpit, one would set buttons as momentary or toggle depending on the sim function. For Squawk, the 8 R buttons could be each digit 0 to 7, press 4 buttons in squawk sequence. Momentary. For MCP/AP Speed, LNav, VNav, Loc, Alt Hold buttons at top would be Toggle, the sim may cancel certain LEDs

So 24 channel buttons, 11 control buttons, most have LEDs, 8 pots 0 to 1023, 8 sliders 0 to 1023. I reckon the pots could do Baro, Mins or ND zoom. S button on left could arm spoiler, the slider 0 to full spoiler. Cessna flaps using 3 buttons or right.

Quite a neat package.

Paul

[DocMoebiuz]

Device now shows and original issue was solved. PR was merged.