Update MIDI docs for GUI tab #1121
Conversation
|
It seems that uploading images to an open issue to generate a url that can then be used is not working. Apparently GH is cracking down on using it as free image hosting and will only allow images to be used in its own system (issues, PR's, etc). Following the link directly will take you to the image (so should work in theory), but it's not rendered in the generated Jekyll website. If that's the case we're going to have to bundle all the images ourselves or find an alternative. Edit: digging further, it appears that GH is generating temporary signed URLs that expire after 5 minutes when accessed from outside GH. So ideally this should be sorted before releasing the updated website. Great. |
| ``` | ||
|
|
||
| * `MIDI channel` is required or else the parameter argument is ignored and the feature is not active. `0` means "any channel", `1`-`16` listen only to MIDI messages on the specified MIDI channel. | ||
| * `MIDI channel` |
There was a problem hiding this comment.
Why is the description removed?
--ctrlmidich ";1"
should fail to parse and be ignored.
There was a problem hiding this comment.
I removed it because it's a verbatim repetition of the same explanation a bit further up. But I see your point - it could be assumed that the requirement doesn't apply in this case.
| ### Using `--ctrlmidich` for MIDI controllers | ||
|
|
||
| The volume fader, pan control and mute and solo buttons in the Client's mixer window strips can be controlled using a connected MIDI controller. This feature is available from version 3.7.0 on macOS, Linux, and the JACK version of Jamulus for Windows. From Jamulus 3.12.0 onwards, it is also available for the non-JACK (ASIO) Windows version. To enable this feature, Jamulus must be launched with the `--ctrlmidich` command-line option. | ||
| MIDI controller parameters can be set using the `--ctrlmidich` command-line option. Bear in mind that when used it will overwrite any values set previously via the GUI. Any values not set in the command line will be reverted to defaults (0 for offset/first MIDI CC and 1 for count). |
There was a problem hiding this comment.
I think the style guide prefers "using" to "via" -- give it a quick read.
Also, it's probably useful to link to the MIDI section in the Software Manual page from here, as you've centralised it nicely.
OK - so this one is still here.... but you reckon it'll go? |
Hm, I just noticed (as this is the first time I've properly looked, sorry!!) the layout of "MIDI Channel" abd "Mute Myself" look odd compared with the other rows. Can you make the whole thing a table, so the layout is more consistent?
You could "learn" the channel, too -- any incoming MIDI message would do. |
Yes, you can see it here, but try pasting the link into the address bar and see what happens. It turns into an amazonaws-hosted link with a 5-minute expiry time. Keep the link with the image open for 5 mins and then force-refresh the page. |
Back when I started this I did try laying it all out as a table with each "learnable" item on a single row. The thing is, you either end up with a really wide settings window, or if you try making it narrower, the text gets bunched up together and doesn't really look good. MIDI Channel and Mute Myself (and MIDI-in) are kind of "different" as regards the editable options they have so that's why I have a different layout, with both on the same row as they're shorter. Another reason is that I totally suck at using Qt Designer and had a hard time coming up with what you see. I can have another go at it though I suppose... I hadn't really considered making MIDI channel learnable because the applications I use don't do it either - MIDI notes, CCs, CNs are learnable but not the channel. I guess because you just have 16 to choose from and it's easier to do it in a couple of clicks than click on "Learn" and move your controller. Which leads me to think - instead of a spinbox, what about a dropdown with 0 (all) to 15? |
|
I don't think we generally use Qt Designer for anything -- just raw QT Creator and a lot of dynamically created stuff! I find the Qt design support (Designer and Creator) is really painful to use. But then, I use Why not try feeding that table to Github CoPilot and say "Turn this into a Qt form that fits into the current bounds of the Settings dialog" or something? |
I tried that in VSCode with Copilot and it produced an unholy mess... I find that with code for visual stuff it's rubbish. It's great at more abstract things though - it's helped me immensely to put together the MIDI tab code. |
|
This pulls the Count and spinner under the Channel and spinner, making it less wide:
I'm still (and this is the wrong PR) wondering whether the code could have platform-specific "give me a list of available MIDI devices" and provide a drop-down (that works like the |
2 participants
Short description of changes
Updated docs to cover the UI MIDI tab. I moved a number of paragraphs from the
Using --ctrlmidich for MIDI controllerssection to the Software Manual and just left the command line instructions there. It's a feature whose usage initially can be tricky to understand both in the UI and when using the command line, so it's hard to know what to include/trim from each section.I'm also not sure about assuming usage of Jack/QjackCtl in Linux or even hand-holding users to make MIDI connections at all for that matter (except perhaps to explain the
doption for Windows). I'm inclined to think that by providing a standard MIDI-in port that works the same way as any other MIDI-aware application, it's not up to us to explain how to connect to it. Ok, it helps, but from the point of view of doc maintenance it might make sense to just limit ourselves to things that are specific to Jamulus. Case in point: Jack/QjackCtl is gradually becoming obsolete, being replaced by PipeWire, though people will probably continue to use one or the other for some time still. Do we expand the docs to also explain PipeWire, pipewire-jack, etc? It can get messy, fast, and might become outdated at any moment.I did away with the default offset of 70 (it's gone in the app PR). It's an arbitrary value that was initially hard-coded to cater to a single device and hasn't made sense for a long time.
Context: Fixes an issue? Related issues
Related to #3502
@softins: #1119 may need updating if/when this gets in.
Status of this Pull Request
Preliminary version subject to comments.
What is missing until this pull request can be merged?
Does this need translation?
YES.
Checklist