MIDI overhaul - the user interface

[monocasual]

This issue wants to address the UI side of #375 and how to configure the whole new MIDI architecture.

[...] a config window. Instead of Choice widget, we'll need something else to pick more than one input and output port.

The following is a possible layout for the MIDI tab in the configuration window:

Besides the general settings area on top, the panel shows three scrollable viewports containing:

1) list of input ports 2) list of output ports 3) list of midimaps

The three scrollable viewports can be implemented in FLTK with the Fl_Scroll class. Each Fl_Scroll contains a list of custom widgets. The whole thing has been already implemented for the list of existing plug-ins in a channel, so it's technically feasible :sunglasses: :

The edit button will open another sub-window that allows the user to configure the port or the midimap. The port <-> midimap binding can take place in the edit window of each input/output port.

Also, midimaps should be detected on startup from the default user's directory, so there's no need for the "add midimap" button.

@tomek-szczesny thoughts?

[tomek-szczesny]

Excellent! Thank you a dozen for that. :)

Of course I'll spit out a long list of thoughts here, midi-overhaul is my second favourite pet after all. ;)

1. I'm worried that this approach will make the whole config window much taller, and leave other tabs pretty much empty. Unless we're okay with that, there's no problem. One thing for sure, though, I'd avoid at all cost having a scrollable object within another scrollable object - this is always hard to navigate (piano roll, for example). That's why I think that the layout you presented should always be visible as a whole (window can't get so small that you'd have to scroll around MIDI config tab itself).

2. Ports - It is perfect in its simplicity and visibility, I like it. Well, just to make it a bit more clear, I'd substitute checkboxes for a bistable buttons labeled "Enable", or a square "O/I" picture that is often found on power switches. As a side note, it is also a good idea to show ports that are currently in the configuration file, but not available in the system, so a user won't wreck their configuration just because they didn't have all their controllers plugged in at a time. Anyway, the point is to let us set a different label font color for these, either darker grey or maybe even dimmed red. I had some problems with this when playing with Fl_Menu_Button.

3. Midimaps - I hate to disagree about them in general. First of all, looking forward, I hope that community would support us in making new midimaps and we'll end up with 20-100 of them, all of which should be bundled with Giada at 1.0.0 release. It will be very inconvenient to scroll through a list of all midimaps that are present in the system. That is why I'd rather let user add the maps they want to use, and see only those they are interested in. Typically there won't be more than 2 or 3 in use, I think.

Secondly, I feel that setting midimap input and output ports should be in midimap settings - makes more sense to me and as an end user, if something's wrong with a midimap, I'd try and fix midimap configuration first.

So, GUI-wise, I'd insist on "Add" button for midimaps.

Alright! Thank you again for all that. Are you willing to give me a hand with that nasty GUI business? I've spent a few evenings wrestling with that bloody menu button and honestly I'd rather get back to midi bindings and such. ;)

[monocasual]

Thank you for the detailed reply :+1:

1. I'm worried that this approach will make the whole config window much taller, and leave other tabs pretty much empty.

Yes this is kind of expected. As I wrote in the other thread, I'd love to have a resizable configuration window. And yes, some tabs will be left pretty much empty. We might also consider to organize them in a different way - e.g. the "misc" and "behavior" tab can be merged together. This is something to keep in mind when implementing #86 .

2. Ports - [...]

100% agree on everything you said.

3. Midimaps - [...]

Interesting. Well yeah, scrolling through 20-100 items would definitely be a pain. So +1 for the "add midimap" button.

Are you willing to give me a hand with that nasty GUI business?

Sure! If we both agree on the design above I can start working on "port" and "midimap" elements and their scrollable containers.

[tomek-szczesny]

If you liked all my suggestions so far, then I think we have already agreed on a MIDI tab design and you're free to implement it. :) Aside from the scrollable containers that we discussed, the only general setting for now would be the MIDI system. More might come in the future, such as "default MIDI channel input", once I figure out the details of the MIDI workflow. Anyway, just please put the general settings into the box that might expand in the future.

I was thinking that maybe it would be easier to simply apply user changes to MIDI system rather than blocking everything and asking the user to restart Giada, but then, an Apply button would be necessary - an then, to keep all config tabs consistent, the same behaviour would be expected everywhere. So, no, let's stick to "Please restart Giada" approach for now.

Input port settings window should have the following entries:

• Clock Input (None, Midi Clock, MMC, Any)

Output ports should have:

• Clock output (None, Midi Clock, MMC, All)

MIDI maps should come with these settings:

• Input Port
• Output Port
• Reinitialize - a button that resends the midimap init
• Send setup stream - a button, disabled if such stream is not defined in midimap.

This should be enough for me to work on. If the concept changes I might easily fit it to my needs.

Thanks a dozen! :)

[monocasual]

Cool. I'll start working on this as soon as 0.17.0 is out - hopefully by the end of the week!

[tomek-szczesny]

Just a quick question - where will you work on that? Will it be a branch on monocasual, or a pull request on tomek-szczesny/giada/midi-overhaul? :thinking: I've got a bit of a maintenance break from coding, hardware upgrade on my side.. Switching to ARM architecture for everyday use.

[monocasual]

Just a quick question - where will you work on that? Will it be a branch on monocasual, or a pull request on tomek-szczesny/giada/midi-overhaul?

Good question! What if we move the whole MIDI overhaul development from your fork to this repo? It would become a new branch like giada/midi-overhaul or similar. If you agree of course. You would then open a new PR when you want to merge it or ask for reviews. Makes sense?

[tomek-szczesny]

Sure, that'd be awesome! :) Just to be sure please tell me how do I do that, I don't want to screw up this repository! Shall I provide my SSH key or something? I really like that old fashioned Git access.

[monocasual]

You are already a collaborator, so you should be able to create and push to new branches right away. I assume you have to clone this repo first, I don't think you can push directly from a fork (without opening a PR, I mean).

[tomek-szczesny]

Okay, so I'll try to create a new branch here, clone it to my desktop, merge changes from my repo into it (er.. somehow), and finally pushing. Perhaps this could be done in a single local repository, by tinkering with its upstreams and whatnot. I got a book about Git recently, I'll look it up.

[tomek-szczesny]

[in Ace Ventura voice] Alrighty then! I decided to do a branch here and first see if vanilla Giada even works on my machine. I filed an issue with some dependency problems, but otherwise it compiled with the familiar waterfall of warnings. ;)

Anyway, back to the business. I decided I'll merge my work by hand, file after file. There are some things that should be abandoned, like my pitiful GUI experiments. It's gonna have a much cleaner commit history and I'll take some time to revise what I've done so far - it grew pretty big.

So, the branch is here, feel free to tinker with GUI stuff. :)

[monocasual]

Excellent, thanks! I'll start working on the UI components in the next few days. P.S.: compile warnings: please report! :)

[tomek-szczesny]

I looked around my Armbian install today and found some exotic tools preinstalled on it. One of them is Meld, which is basically a manual merging tool. Wow! All my work cleaned up and stacked on top of the most recent Giada master HEAD. It compiles, it runs, it was actually easier than I thought. It's not fully functional at this point, mind you.

So, there you go, a playground for GUI tinkering is ready. This includes a multi-port backend, with respective conf elements storing selected ports as vectors of strings (Port names). Nothing has been done with multiple midimaps yet.

One more thing: We will need a way to represent MIDI bindings as something more than 0x11223344. MIDI bindings will contain a port name as well, and a tricky way to display it will be necessary in many places in Giada. OR we might as well give up on showing a full raw MIDI message for a binding, as it's hardly ever useful outside of debugging. We could go with (Assigned), (Not assigned) and (Invalid) instead.

[tomek-szczesny]

Hey there! I appreciate your involvement. Thanks! It prevented me from building, so I pushed a little fix for that. Don't forget to pull it! ;) Could we agree on not pushing stuff that does not compile on this branch? Both of us need building to test stuff. :)

[gvnnz]

I started working on some UI elements, but suddenly I realized that this is the wrong approach. The user interface should follow the model, once it's been correctly designed and tested. For this reason I think we should first focus on providing a form of persistence to the MIDI overhaul mechanism, namely: 1) the ability to store the changes in a project (json files) and 2) the ability to load those changes back into Giada.

This will allow us to quickly test the model, change it's properties - it's just a matter of altering a json file - and see how it behaves with different configurations. The json approach also gives us the ability to script stuff and generate configurations programmatically, in case we need it. Once we have a solid MIDI engine, we can start to display it in the user interface. That said, it's good that we have formalized the UI with this issue, it will help in the final step.

[tomek-szczesny]

Okay, sounds very reasonable. Currently I got rid off some fringes I wanted to implement along the way but cost too much time. I'll make another discussion about the model, because this is something that surely will benefit from your insight.