NewUI- the second

[dcorson-ticino-com]

Here is a new UI example to play with: https://github.com/dcorson-ticino-com/jamulus/tree/NewUI-DCO
Please download, compile and try it out.
..
EDIT: for those who want to try it out installers are here under Assets:
https://github.com/dcorson-ticino-com/jamulus/releases/tag/r3_8_0newUIbeta2
..

There is now a left vertical menu and 2 sliding windows to the left with our well known mixer board on the right. I have not tried to perfect the graphics and have just bare check boxes where I don't have a graphic at hand, but you will get the idea. Stuff like retaining the state between uses is not implemented. But it works.

The window contents can be turned on and off with the left menu buttons, the sizes of the panes changed with the "splitters". Up to 4 windows can be shown (+ menu + mixer). The new "Actions" window includes all of the former Edit menu.

Settings is now a tabbed window including the User profile, sound card setup and network setup.
The menu can pull up the setup window with the My Profile tab or the Network tab shown (so my profile is easier to find for new users (debatable).

I am not convinced that leaving the Connect window open when connected to a server is really a good idea. I have also not yet found the trick to allow double-clicking to select a new server when already connected, but there must be a way.

Is this kind of display in any way useful?

The windows all open, but collapsed.

I will be using this version now for a couple of weeks to see how it works once one gets used to it.
My impressions 'til now are that it makes for a cleaner screen, without separate dialog windows, but I don't think it is easier to use.
What do you think ? Your comments please...

[ann0see]

Tagging @jamulussoftware/designers here.

I'll test the new UI soon and might give more feedback on it. In general, I think the idea is quite good and more organized than Jamulus used to be.

Just my first quick impression:

I'd say it can show a lot at once which might lead to confusion?

Can you tag the last commit with r3_8_0newUIbeta? This would allow the GitHub actions workflow to compile the new version for all operating systems.

[ann0see]

Not sure I want to put it in any workflow as it is just a quick hack that works.

... which is why you should tag it as beta. If you do this, the binaries will be created on your repo and available for others to download easily.

[dcorson-ticino-com]

I hope I did that right, GitHub is totally opaque for me.

[ann0see]

Hmm. It seems to fail. Can you rebase your branch to the latest master (or just merge master into this branch) and then re try? I think the state of this branch doesn’t include the new process yet.

[dcorson-ticino-com]

I have rebased to the master and then corrected/re-added all the deleted resources so it works again, but am getting this as application output:
OpenType support missing for "Segoe UI", script 20
OpenType support missing for "MS Shell Dlg 2", script 20
OpenType support missing for "Arial", script 20
OpenType support missing for "MS UI Gothic", script 20
OpenType support missing for "SimSun", script 20

I have no idea what could be causing that, have never seen such before.
Any ideas?

(BTW is Qt interpreted? Why should such a message be coming at run time and not compile time?)

[ann0see]

I don't think Qt is interpreted. Maybe fonts are not automatically included in the binary and must be loaded during run time.

[gene96817]

Is it possible to have two windows open? I would want to have one window that gives a maximum display of the mixer board and a second window with all the goodness of these tabbed windows.

If I am using the tabbed windows, is it possible for the mixer to be the left-most window? I would like to avoid having the mixers with moving screen positions. In this way, I could have some settings and lights memorized by position for watching for changes.

In both scenarios, it is helpful to me or the sliders and related indicators to be fixed in space.

[dcorson-ticino-com]

I oriented to Jonathan's layout proposition in one window with things pulling out from the left.
I will make a version with the mixer at the left, just to see how that effects the handling.
But maybe having two windows that could dock is not a bad idea...

[mulyaj]

Hm... I'm not sure how I feel about a multi-pane approach. Right now it kind of sits in-between a single-page application and a multi-window application (what Jamulus currently is), and isn't entirely scalable.

Another thing to add: In my opinion, a left-aligned menu seems to imply equal importance of the menu items, especially with "Connect" and "Chat" (A user could mistake Connect and Chat as two separate items, whereas Chat is actually only available after you've connected)

[ann0see]

I'd also not totally get rid of the multi window layout. Settings and the connection dialog could still be separate.

[dcorson-ticino-com]

I tried to put things that are not needed at the same time in the same horizontal window.
So it is either Connect or Chat, pull the line up or down. Same with Setup and Actions.
I am also not really convinced, but will use it, as said, for a couple of weeks to see if it grows,
I am somewhat enamored of Gene's two window idea, a mixer window and a ??Controls?? window that could maybe be docked left or right. The problem is still to be simple , show what is needed at the beginning but not limiting for those with their 100 member choirs (and 3 screens I assume).
If you have other ideas let me know, I will make another version in a couple of weeks.

[dcorson-ticino-com]

@ann0see what do I need to get that automatic compile to work? I pushed a rebased version and tried to reassign the tag, which it appeared to accept, but nothing has happened.
And where are the binaries once they are made? Are they installs or bare binaries that need all the dlls around?

[ann0see]

You will need to remove the old tag and afterwards push the new one or just push another Tag with another name. The installable binaries will be on the release page of your repo.

[pljones]

I think, as others have said, it needs the flexibility - dockable subwindows into a main window, allow the subwindows to be closed, opened or undocked. This helps people organise their work flow to suit their needs. When I'm doing sound check for World Jam, I use two instances of Jamulus, mainly just the mixer view, but I also need to see the connect window at least once, plus have chat and settings. That lot I want on a separate monitor from the mixer views. On the same monitor, I've got Zoom. Also on the other monitor I've two browser windows, each with three tabs open. It works... just about... The layout, left to right, that works, after considerable adjustment is all the Jamulus "subwindows", the browser windows, Zoom on the left half of the main monitor, then the Jamulus windows tiled top and bottom on the right half.

Oh... and I'm no fan of side-bars. I like to use keyboard accelerators to access things via (these newfangled) menus... just call me old-fashioned...

Have to say I very much like the settings view :).

[dcorson-ticino-com]

@ann0see Sorry I always have problems, but do you have any ideas why the autobuild worked for Android, MAC and Win10 but failed for Linux? I see it claiming a missing header file. The file was strangely there for the other OSes.

[ann0see]

I can have a look at it on your repo.

[ann0see]

In file included from ../src/actiondlg.cpp:25:0:
../src/actiondlg.h:27:10: fatal error: QLabel: No such file or directory
 #include <QLabel>
          ^~~~~~~~
compilation terminated.

The headless server build seems to be broken.
You seem to create/reference a Qlabel object (?) on a headless build. This can't work since the headless server doesn't include GUI headers. Before this gets merged to master, this will have to be resolved. Can you look at the mentioned file?

[pljones]

../src/actiondlg.cpp shouldn't be included in a headless build at all. There's a list of files for each build type in Jamulus.pro - check to see you've updated it right.

[dcorson-ticino-com]

Will do, but I see a different problem, why did the other builds work? or is there only a headless build of Linux?

[pljones]

The automation only does the headless for linux, as that's the common use case for that build.

[pljones]

Hi @dcorson-ticino-com,

Another thought: The "Pan" slider for the input channel mix... I'm tempted to say we should move this to Audio Settings. It should be thought about when setting the input channels for the selected device, not whilst in the middle of a jam. (Input reverb is okay, I guess.)

[dcorson-ticino-com]

Done for NewUI-03

[ann0see]

We should also maybe discuss optimizing the GUI for touchscreens: #1287 @reneknuvers

[dcorson-ticino-com]

But only if it doesn't reduce the usability on non-touchscreen computers.
I would suggest that @reneknuvers makes a fork and implements what he thinks would be good.
Then we can try out and discuss.
I note that I am on the 5th or 6th iteration of my newUI and am only now finding it is better than Volkers original UI as a whole.
Having ideas is good, but trying them out makes the difference.

[pljones]

I've had it pointed out to me that we've a lot to do currently around accessibility. One example: the Group/Mute/Solo check boxes don't indicate to screen reader software which channel (i.e. name) they belong to, so you don't know who you're (e.g.) muting. Improvements like that are pretty simple - adding the channel name (or else number if empty) to the control accessibility text (and keeping it updated as it changes).

[dakhubgit]

Here are a few suggestions partly intended to facilitate some other changes I'd like to see eventually.
First to the conceptual changes I'd like to see: I consider it rather important to have a stronger decoupling of input and output settings and sections.
a) input quality and output quality are inseparable. But input quality affects every listener including the recording, while output quality affects only myself. That means that the tolerance for dropouts and lower quality in return for shorter latency is more personal on output rather than on input.
b) it's not just the quality that is inseparable: also mono/stereo and whether something is sent/received at all are coupled: if I "mute myself", a signal continues to be sent (it's just zero) and, because of fixed coding rates, occupies the same bandwidth. The same when using mono-in/stereo-out: a stereo signal is sent with stereo bandwidth allotment, but with both channels being equal. As a special case, someone who is only listening (we have a "streaming" client icon even) will still be sending with the quality settings and bandwidth requirements that he wants to be receiving. Conversely, someone playing multiple instruments (or feeding a rhythm machine into an additional Jamulus instance) will still be receiving a mix that has no use.
c) Apart from the option of having zero sending channels (when listening only, or temporarily when muting yourself), having more than one without having to start multiple instances of Jamulus would be nice.

What does this imply for a few user interface choices? There is a point in having a per-mixerstrip control whether to send or not (basically the "record" button common in MIDI controllers and similar surfaces) in addition to have an overarching "mute all" control you can apply before even connecting to a server.

That also means that customizing name and instrument type should be done per mixerstrip rather than globally. Once you do that it becomes desirable that your mixerstrips are visible even without connecting to a server (basically "virtually" connecting to an otherwise empty server) so that you can easily customize them individually (by clicking on an appropriate field within them) without needing a connection.

With regard to separating input and output section settings more and making them more individually customizable, "server jitter buffers" belong in the input section as they concern traffic to the server, "local jitter buffers" belong in the output section as they concern traffic to the local listener. At the current point of time they are next to each other, with the one concerning the input section to the right.

I think there is some potential for sorting the user interface in a manner where it better reflects the semantics of what is actually happening and facilitates users understanding what they are doing and controlling to what effect where.

[gilgongo]

Seems like a lot of edge cases being handled there. Hard to say what the effect of that is until we see it in a proposed UI though. You might be describing an "advanced mode", perhaps. Consider that many people just want to connect their mic and/or guitar get jamming. Equally, I've got no problem making Jamulus into some kind of realtime performance DAW though, if that's possible.

[pljones]

a b and c basically define how Jamulus works. Changing them means writing a new piece of software. None is related to changing the UI and therefore probably isn't worth discussing here.

[dakhubgit]

a b and c basically define how Jamulus works. Changing them means writing a new piece of software. None is related to changing the UI and therefore probably isn't worth discussing here.

That's sort of a stock reply for any feature request. a and b involve just a version change in the protocol (essentially, the server should just pass the received packet size to the Opus decoder and will then be perfectly capable of decoding packets sent with different stereosity or quality than it produces, a change also necessary for supporting VBR decoding already discussed elsewhere), c would not even require a protocol change (whether input on two sockets originates from two or one instances of a client is indistinguishable to the server).

Now the code base is rather contorted and mushes things together in more of a C than a C++ programming style. That would make it advisable to do at least c in connection with a code refactoring that would benefit the code base anyway. I disagree with the blanket "changing them means writing a new piece of software" statement that sounds equivalent to "Jamulus is not salvageable".

[dakhubgit]

Jonathan ***@***.***> writes:

Seems like a lot of edge cases being handled there. Hard to say what the effect of that is until we see it in a proposed UI though. You might be describing an "advanced mode", perhaps. Consider that many people just want to connect their mic and/or guitar get jamming. Equally, I've got no problem making Jamulus into some kind of realtime performance DAW though, if that's possible.

Well, connect your mic _and_ guitar and nobody has a way any more to pan them anywhere if you send in stereo (then one is left and one is right, and the "pan" control controls their balance) and nobody can change your balance if you send in mono. Or, in my case, have two mics for two players on one sound interface. I'll probably fudge a server side solution where a name "Karsten & Petra" on a stereo channel splits it into two mono channels with nobody being the wiser. But I am not sure it would work well on the client of that pair itself, at least concerning what happens when pressing "mute myself". That are rather basic use cases. "Listener/Streamer" are such a basic use cases that we have symbols for them, but you still cannot stop them from sending stuff. Mono-In/Stereo-Out is basic enough that we have a setting for it, but you can still not keep it from sending in stereo with full stereo bandwidth, actually even when pressing "mute myself". So I find it reasonable to try designing user interfaces in a manner where they straightforwardly map to what happens to be straightforward use cases.

…

-- David Kastrup

[gilgongo]

I'm sure you're right. But until we see some UI for all that, I have no idea.

[pljones]

The Jamulus KISS model means that two separate inputs really should require two separate instances of Jamulus. Except on a subset of Windows platforms, that's not particularly hard to achieve. It would be better, in my view, to educate people to get them able to use Jamulus in a more powerful manner as it is now than spend effort re-engineering it unnecessarily.

[dakhubgit]

Jonathan ***@***.***> writes:

I'm sure you're right. But until we see some UI for all that, I have no idea.

It's somewhat orthogonal to this thread since the user interface redesign here is more concerned about changing a multi-window design into a multi-pane design without affecting all that much of the details. So the "topology" to access some feature is pretty much the same here as previously while I am more concerned with restructuring the tree in a way that required additional elements have a natural place. So I probably need to get this moving elsewhere. Separating input and output settings and connectivity is something that the server needs to know about as well as the clients, so it involved protocol work.

…

-- David Kastrup