Add GUI support for MIDI settings

[ignotus666]

Hi,

I find it very cumbersome to have to set the MIDI parameters via command line arguments (I have to go back to the documentation every time to get the syntax right), so had a crack at exposing the MIDI settings in the GUI, adding a tab to the Settings menu:

These MIDI settings get written to the .ini file so persist across restarts. Starting Jamulus from the command line with MIDI arguments overwrites any settings set in the GUI previously.

I haven't added any translatable strings or documentation and the code would need some cleaning up, but I wanted to ask first if anyone would consider this a worthwhile addition.

[jujudusud]

Good UI enhancement.

[ignotus666]

Most applications I use paired with MIDI controllers have a "MIDI learn" function that is quite handy. I created a separate build that implements this function. Click on "Learn", operate your MIDI controller knob/fader and it will pick up and store the corresponding CC number.

[ignotus666]

@rdica yes, me too - I find it frustrating when they don't offer this function since it's not always immediately obvious what your controller is sending.

Here's the branch if anyone wants to give it a go: Here

[rdica]

Thanks, I'll test it this week and update with my findings.
@pcar75 You may find this interesting as well.

[rdica]

@ignotus666 The link you provided 404s.

[ignotus666]

@rdica it should work now.

[rdica]

Thanks for updating the link, I'd already found your repo and built in the midi-learn branch and am testing.

[ignotus666]

Reading the documentation I just realised "Mute Myself" can also be controlled via MIDI... Ah well, I'll add that too in due course.

[rdica]

@dcorson-ticino-com Not an issue for me since I use Linux :)

@ignotus666 I have tested a 3 track Pure Data program and things are working as expected. I set arbitrary values in the program and let Jamulus learn the midi offsets for each of volume, pan, mute, and solo.
I'm assuming the learn function should be performed against the first track given I set my count values to 12. My Pure Data program will eventually have 12 working tracks. I will try a learn on track 2 or 3 and see how that works out.

[dcorson-ticino-com]

@dcorson-ticino-com Not an issue for me since I use Linux :)

This looks like an enhancement that would be good for everyone, not just the little Linux world.
Be sure to program in such a way that it is not limited to only one OS and could then be added to the next release (after check by the powers at be).

[ignotus666]

@dcorson-ticino-com In theory it should work on all platforms (the JACK version for Windows would be necessary I guess), but I've only tested on Linux. If I make a PR I think this will generate builds for all platforms, so I'll go ahead and do that.

[ann0see]

the JACK version for Windows would be necessary I guess

I thought we support Windows midi with the upcoming version...

[ignotus666]

Don't mind me... It should work without JACK, it's just that i have no idea what the current status of Jamulus on windows is and need to test properly.

[ignotus666]

Tested on Windows in a virtual machine and it works. No idea how the MIDI routing works in Windows - I just enabled the USB-MIDI receiver for the virtual machine and Jamulus was picking up the data.

[rdica]

@ignotus666 I've found the midi channel setting isn't saved.
Also, I tried editing the ini file I specified and explicitly set the midi channel I'm testing with, that value (16 in my testing) is ignored when starting the client using the specified ini file, instead showing the midi channel as 0.

Is this intentional?

[ignotus666]

@rdica that's weird... it is saved for me, on both Linux and Windows. Are you sure you're not starting Jamulus with --ctrlmidich "0"?

[ignotus666]

Also, I made a PR so you can test a pre-built version without having to compile from my branch: artifacts here

[rdica]

I'm starting with ./jamulus -i ~/.config/Jamulus/midi-learn.ini -6 -j.
All the other midi params I've set are retained across app restarts. I incorrectly assumed the midi channel would be saved once configured in Settings just as the other params are saved.

I tried different invocations of the above adding --ctrlmidich "16" and other numerical values between 0-16 and that indeed sets the midi channel.

Personally I'd like to see the midi channel saved so it doesn't have to be explicitly set at runtime.

[ignotus666]

@rdica I found the problem - a typo. The range in the GetNumericIniSet function for "channel" went from 0 - 15, so if you set it to 16 it wrapped around to 0. You can compile an updated version from my midi-gui-learn branch or get it pre-built from here.

[rdica]

Great catch! I rebuilt and now the channel value is saved and persistent across restarts, thanks!

[QJKX]

It's a great improvement.

Changing some of the labels would make it even easier to figure out without documentation:

• Clarify Channel as MIDI In Channel
• Change Channel 0 to All
• Change Offset to First MIDI CC

[ignotus666]

@QJKX

• I agree that "Channel" may be a bit ambiguous, though I'd assume someone looking to use a MIDI controller would know. What about "MIDI Channel"?
• The problem I see with "All" is that it adds complexity and would need to be translated. It fits nicely in English, but won't in most other languages. In any event, the "What's this" (right-click on any widget within the tab) explains what Channel 0 does.
• I definitely agree with this and had thought about proposing such a change in terminology. I think "offset" is from the days when the "first CC" was hard-coded to cater to a specific Behringer device. For others, you either had to change it in the code and recompile, or edit the CC numbers in your controller to start from CC 70. Then the term just hung around but in the current context it no longer makes any sense.

[QJKX]

• I agree that "Channel" may be a bit ambiguous, though I'd assume someone looking to use a MIDI controller would know.
  What about "MIDI Channel"?

Sure.

• The problem I see with "All" is that it adds complexity

Fair enough, and a good enough reason to leave it out.

• I definitely agree with this and had thought about proposing such a change in terminology. I think "offset" is from the days when the "first CC" was hard-coded to cater to a specific Behringer device. For others, you either had to change it in the code and recompile, or edit the CC numbers in your controller to start from CC 70. Then the term just hung around but in the current context it no longer makes any sense.

A big contrast to how accessible it will be having this right in the GUI.

Lastly I wonder if the whole screen can get across that it will not work for playing music from a MIDI keyboard (and to be fair someone might think that, as typically the only configuration required for that would be a channel number, which the screen has).
I really do think there are many more people who would potentially try to use the screen with a keyboard than who actually own a control surface, meaning the screen actually wastes more time than it saves.

Calling the whole tab "MIDI Control Surface" would get that across instantly to a technical user, and can be googled ("What's a MIDI Control Surface?"). Not using the word MIDI, just "Control Surface" might be even better.

[ignotus666]

Calling the whole tab "MIDI Control Surface" would get that across instantly to a technical user, and can be googled ("What's a MIDI Control Surface?"). Not using the word MIDI, just "Control Surface" might be even better.

What about "MIDI Control"? It keeps the tab name shorter, clarifies that it's for "controlling" rather than "playing" or similar, and also makes it clear that it's for MIDI and not some other protocol.

[QJKX]

What about "MIDI Control"? It keeps the tab name shorter, clarifies that it's for "controlling" rather than "playing" or similar, and also makes it clear that it's for MIDI and not some other protocol.

Sounds good.

[ignotus666]

One last MIDI-related feature I miss in Jamulus is "pickup mode", where the software fader waits for your controller to match its MIDI value in order to begin moving. For example, your physical controller may be at the 100% position (from previous use with something else), and you want to use it to nudge a software fader from 30 to 40%, but also want to avoid it blasting out at 100% as soon as you move the controller. Currently, the fader in Jamulus will immediately jump to 100% (or thereabout).

I've managed to implement pickup mode, though I don't think it'll be included in #3502, which is big enough and I think should be approved first before adding this feature. If @rdica or anyone else wants to test it though, you can find it here.

[ignotus666]

@rdica sorry about that, I forgot to update a couple of files. It should compile now.

[rdica]

Thanks, build completes, pickup behaves consistently between known and unknown clients, totally cool!

For grins and giggles I'm attaching my Pure Data test GUI controller, its hardcoded for midi channel 14, and can manage 12 clients.

JamulusClientMidi.pd.gz

[ignotus666]

Cool! I was aware or Pure Data but had never messed around with it, so I installed it to check out your controller - nice.
I couldn't get pickup mode to glitch with PD, but with a physical controller if you do a fast movement after leaving it at rest for more than a second, the fader can be "lost" and needs to be picked up again. It depends on whether the controller is capable of sending a stream of all (or most) MIDI values with quick movements. My controller may be at 100, but if you turn it suddenly with force, by the time it reacts to send MIDI it may be at 105, which is beyond the pickup tolerance range. Anyway, the pickup code is a convoluted mess right now, so it might get an overhaul if I can think of a better way to do it.

[ignotus666]

Well, I fixed the pickup loss issue by programming my controller to use interpolation to send at least every 2nd MIDI value missed. So if a quick movement causes it to skip from 100 to 110, it will send every 2nd value between them before sending 110. It now works great and never "loses" a fader, but I don't know how commercial controllers perform in this respect. It would need to be tested.

[rdica]

I have an M-Audio Oxygen49 I can test with, but I won't have that opportunity until the weekend, I'll let you know my test results.