UI: Open musician profile on click on own slider?

[ann0see]

Is your feature request related to a problem? Please describe.

New users might find it difficult to find the profile button (just had someone yesterday who didn't find it).

Describe the solution you'd like

Add a button (pencil or similar) on the own slider next to the name which opens the musician profile window.

Describe alternatives you've considered

• Add a button to open the profile somewhere visible

Additional context

Related to my findings where the UI could be improved.

[pljones]

That was the one big loss with the "Mute myself" checkbox going where it did - the profile button fitted there nicely.

[gilgongo]

Having to scatter navigation and controls around the UI like this will become more of a problem as time goes on without some intervention on the structure of the interface overall. This was my point 3 here #958 (comment)

I think doing this ticket would be OK for now, but it's storing up design debt really.

[ghost]

"Open musician profile on click on own slider" may address a user proplem, but is not the solution because:

• your own slider is only there when you are connected to a server. (an easter egg)
• someone who cannot find (View > My Profile ) has no vested interest in using Jamulus.

[dcorson-ticino-com]

Having to scatter navigation and controls around the UI

These things belong under Settings with a multi-tabbed window, User, Network, Device .... or similar

[pljones]

There was a back burner topic about moving to a multi-tabbed design. The Server UI got one step in that direction. I think that's probably the best approach here. Gather up all the settings in to one place, then arrange them into logical groups in tabs, as you suggest.

[dcorson-ticino-com]

I will look into doing this in the next week or so.
And at the same time clean up the menus #994

[ann0see]

Thank you very much for this work!

[gilgongo]

Given the fact that there is now, for better or worse, a convention of having navigation in most apps on a bar on the left, it would be good to consider that for Jamulus in order to present a familiar environment and so that we can scale the UI for the future if needed.

[dcorson-ticino-com]

a convention of having navigation in most apps on a bar on the left

Is this true? I am not aware of any program like that.
And even if it is true I don't think we need to run after the latest fashion.
The simple act of moving the Connect button from the far left of the window to the middle makes Jamulus IMHO much more convivial, easier and quicker to use.
Also for a vertical menu text descriptions must be very short (or none), otherwise the menu becomes very wide.
When I think about it the only place I use vertical menus in a program is in CAD toolbars where there are many tools and toolbars and they have only icons, no text.

(I understand why people would put the menus etc at the left or right edge, as the screens are no longer sized to be a good work environment, but to show movies and as such they are way too wide. But pushing the menus to the dead portions of the screen makes them dead too. Personally I have my task bar at the right and not at the bottom as is standard, but that is because I rarely use it.)

[gilgongo]

It's mostly true. And indeed you gave an example earlier with Windows. I think we agrees that you wanted tool tips.

In general, the adage here is that, "All of your users spend most of their time with other people's applications". If you want to help orientate people, it's usually a good idea to start with a navigation scheme they are likely to be familiar with.

But let's see what you come up with.

[dcorson-ticino-com]

But let's see what you come up with.

In the immediate, nothing special, just a tabbed window with all the settings.

For the NewUI I have ideas, have to try out some stuff, will take time.

[ann0see]

I will look into doing this in the next week or so.

Assigned you to this issue (I'm doing a few tests for project management features in GitHub now. I hope it's ok for you to be assigned here)

[Hk1020]

a convention of having navigation in most apps on a bar on the left

Is this true? I am not aware of any program like that.
And even if it is true I don't think we need to run after the latest fashion.
The simple act of moving the Connect button from the far left of the window to the middle makes Jamulus IMHO much more convivial, easier and quicker to use.
Also for a vertical menu text descriptions must be very short (or none), otherwise the menu becomes very wide.
When I think about it the only place I use vertical menus in a program is in CAD toolbars where there are many tools and toolbars and they have only icons, no text.

(I understand why people would put the menus etc at the left or right edge, as the screens are no longer sized to be a good work environment, but to show movies and as such they are way too wide. But pushing the menus to the dead portions of the screen makes them dead too. Personally I have my task bar at the right and not at the bottom as is standard, but that is because I rarely use it.)

a convention of having navigation in most apps on a bar on the left

Is this true? I am not aware of any program like that.

Two that come to mind - Microsoft Teams (very popular these days), Visual Studio Code.

[pljones]

Two that come to mind - Microsoft Teams (very popular these days), Visual Studio Code.

I nearly said I couldn't think of any. Then I remembered - all the IDEs I use work like that: document in the centre, navigation and tools around the outside. Also, desktop mail applications, calendar applications, etc. And mobile apps with left hand pull-out menus....

Is the "document" for Jamulus the session? What count as tools? All my IDEs still have menus, as well as tool bars and navigation facilities, status windows, additional information, etc.

The biggest difference - it's huge - is that almost every other application I use has all it's content in a single window, often tabbed if multi-document (with the option of tabs in separate windows).

[dcorson-ticino-com]

I nearly said I couldn't think of any. Then I remembered - all the IDEs

Well, I looked again, I do use one program that has a left menu, Qt Designer.
The UI is only usable for developers I'd say.
There is a left menu, but I have never used it.

[pljones]

OK, so you're saying if you've chosen "Mute Myself", display the user's local slider. That does have some logic -- except for the fact that there's no audio process running. So they wouldn't hear themselves.

[dakhubgit]

OK, so you're saying if you've chosen "Mute Myself", display the user's local slider. That does have some logic -- except for the fact that there's no audio process running. So they wouldn't hear themselves.

No, I am saying that the operation of "Mute Myself" proves that the server is not required for letting your channel strip operate and produce output hearing yourself. So it is little more than chicanery that your channel strip only becomes visible and operative once you are connected to a server. I also rather doubt your assertion "there's no audio process running" since client's and server's timing are not synchronised and the client refuses to even start up (in the Linux version) without a sound system providing the timing.

[dcorson-ticino-com]

No, I am saying that the operation of "Mute Myself" proves that the server is not required for letting your channel strip operate and produce output hearing yourself.

David, you still haven't answered my question.
Have you put your headphones on, started Jamulus and made sounds that you hear with your headphones, and then tried the scenarios you are talking about?
If you do you will find that without connecting to a server you never hear anything, with or without "Mute Yourself"
Take the time to try it.

[dakhubgit]

No, I am saying that the operation of "Mute Myself" proves that the server is not required for letting your channel strip operate and produce output hearing yourself.

David, you still haven't answered my question.
Have you put your headphones on, started Jamulus and made sounds that you hear with your headphones, and then tried the scenarios you are talking about?
If you do you will find that without connecting to a server you never hear anything, with or without "Mute Yourself"
Take the time to try it.

The "Mute Yourself" functionality proves that there is no necessity of bouncing the sound through a server for hearing yourself and having an operative strip and that the current user interface blocks you from testing things without connection entirely gratuitously. If the user interface didn't, we would not be having this discussion in the first place.

What you can do is connect to a server, then cut your network connectivity (take out the cable, switch off the WiFi, whatever). While Jamulus hasn't yet given up on the no longer reachable server, you'll see your mixer strip and hear yourself in your headphones when and only when "Mute yourself" is active, clearly without any involvement of the remote server that has become unreachable. After about 10 seconds Jamulus decides the server is gone for good and reverts to being useless: it removes your mixer strip and does not allow you to test its effects.

[pljones]

I also rather doubt your assertion "there's no audio process running" since client's and server's timing are not synchronised and the client refuses to even start up (in the Linux version) without a sound system providing the timing.

What you can do is connect to a server, then cut your network connectivity (take out the cable, switch off the WiFi, whatever). While Jamulus hasn't yet given up on the no longer reachable server

That's two different things.

I said when the audio process is not running. You've demonstrated that the audio process keeps trying - due to using UDP, it needs to - when there's a network brown out.

[dakhubgit]

But the metering works. At least it used to until the following commit was added just now to master:

commit a7ecdf4b26f5f774a5f2e32585949b644c64bf3b
Author: ann0see <[email protected]>
Date:   Fri Feb 12 22:33:13 2021 +0100

    Disable input level meters if not connected

It would appear there is a mission to make Jamulus as useless as possible when not connected to a server. Frankly, I don't get the point. Is this trying to prove something?

[pljones]

@@ -1239,6 +1242,8 @@ void CClientDlg::Disconnect()

     // stop timer for level meter bars and reset them
     TimerSigMet.stop();
+    lbrInputLevelL->setEnabled ( false );
+    lbrInputLevelR->setEnabled ( false );
     lbrInputLevelL->SetValue ( 0 );
     lbrInputLevelR->SetValue ( 0 );

Note this:

     TimerSigMet.stop();

which was already there. That stop processing anything in the UI when Disconnect() is called. All the commit you refer to does is set the UI status to "disabled" - it doesn't change function.

[dakhubgit]

There is a philosophy at work here that I don't get. It may be related to different operating systems: on GNU/Linux, the Jack sound system needs to be up and running to even start Jamulus, and that means that in general everything is already set up. There is no way inside of Jamulus to choose different input ports, a different sound device, Midi ports for a controller or whatever. So the audio system is always engaged and ready and there is no point in not making use of it.

It's conceivable that this is not similarly the case on other platforms.

However, it is borderline annoying how inflexible Jamulus is regarding the sound system on Linux: it takes the first two physical input ports without asking questions. There is an input selector box that has only one entry: "Jack".

Personally, it would make a lot more sense if local slider(s) were present and operative independent of server and you could click on the slider(s) to connect them to particular inputs. Similarly for the output. Having everything disappear and inoperative without a server serves no useful purpose that I can see.

[gilgongo]

This ticket seems to have forked into different related discussions, so I'm renaming it and moving it there. The original feature request may still be valid to add to the issues list later once we have some agreement on how to do that.

And if anyone has any actionable, defined feature requests on the back of this conversation, please raise them as clearly specced tickets we can add to the backlog. Otherwise, please open in Discussions and we can firm them up.

[ann0see]

After the move this discussion became quite inactive ;-). But I think it has very valuable input:

1. It seems to be confusing that the UI looks almost the same if you're not connected and Jamulus is "useless" in this state. Also there's no concensus what to do in disconnected state.
   a) Either Jamulus should give back sound (local monitoring) --> Probably possible, but requires some code change or
   b) We e.g. show the server list in disconnected state.
2. Currently you can't start Jamulus if there are audio-interface issues (wrong sample rate, jack not running,...) which is "rather unhelpful" (quote from pljones) in another issue. @dakhubgit I think that's one of your (and also my) points here?

[ann0see]

The value is that you can try out the application in "dry run" mode without requiring to set up a server of your own or trespass on someone else's server for even the most basic first steps.

Yep! This would solve a lot of problems also concerning the ASIO4ALL setup. I'd even go another step further:
Proposed workflow:

1. Open Jamulus (code doesn't check if all the sound setup is ok)
2. After it has opened and it is possible to open settings, show the own slider; output audio (loop back mode) or give warnings e.g. that the sample rate is wrong (and of course how to fix it if you use ASIO4ALL),...

[gilgongo]

The value is that you can try out the application in "dry run" mode

@dakhubgit That's this, isn't it? #882

[dakhubgit]

Pretty much so, variant 2 in the issue-starting proposal.

[Hk1020]

BTW has this got anything to do with the name of this discussion? I'm not complaining - it's just a discussion - but I was curious in case there was a connection I'd missed.

The connection with the discussion was tangential: in case of another different feature, namely being able to use a single client for transmitting several channels, you'd want an obvious ability to give your own sliders separate different profiles. Being able to click on them for entering stuff would be easily discoverable (actually also when only having a single slider: took me some time till I figured out where to configure it and it did not help that under XFCE4, Qt chose not to offer the respective menus at all).

Exactly. I had to tell several people how to set their name. Why hide this in some menu in the menu bar. Double click on one’s name and you can edit it.

[pljones]

If

b) We e.g. show the server list in disconnected state.

means rather than the mixer window we show the server list, this makes some sense -- but the "settings" button needs to be available from there.

Then when started without an automatic connection, Jamulus would show the server list, encouraging the user to find somewhere to start jamming. Once connected, the mixer would show - controlling the online session. When disconnected, it goes away again. But you can still get to Settings to set up.

Then it's a matter of not having Jamulus start up with the sound card open, which would allow the driver to be selected and set up.

[dakhubgit]

Peter L Jones <[email protected]> writes:

If > b) We e.g. show the server list in disconnected state. means _rather than_ the mixer window we show the server list, this makes some sense -- but the "settings" button needs to be available from there. Then when started without an automatic connection, Jamulus would show the server list, encouraging the user to find somewhere to start jamming. Once connected, the mixer would show - controlling the online session. When disconnected, it goes away again. But you can still get to Settings to set up. Then it's a matter of not having Jamulus start up with the sound card open, which would allow the driver to be selected and set up.

Maybe it's the server list that should contain an extra button "Connect to self" then?

…

-- David Kastrup

[pljones]

The client isn't a server, though, so that wouldn't make any sense at all.

Or do you mean a button that would spawn a server running locally and connect to that?

[dakhubgit]

Peter L Jones <[email protected]> writes:

The client isn't a server, though, so that wouldn't make any sense at all.

Since when is a short-circuit not a connection?

…

-- David Kastrup

[pljones]

I'm sorry, that sentence makes no sense to me. Can you translate it, please?

[dcorson-ticino-com]

Peter, I think you read that too quickly.

Maybe it's the server list that should contain an extra button "Connect
to self" then?
I think with "server list" David is talking about the Connect window as a place to put a button to enable local loop-back.
It is, in any case, a possibility.

[pljones]

I think this would make for a very uncomfortable and confusing user experience, to be honest.

If you're on the mixer window, you need to be connected to a server. That's simple to understand.

If you're on the connect screen, you're choosing a server to connect to. That's simple to understand.

If you're trying to mix those two in different ways, that's not simple to explain or understand.

[dcorson-ticino-com]

Despite trying to think this through several times I am still not at all clear how this local loop-back should be presented and where the logical place is to enable it (and even how to name it so the neophyte understands).
I see this as a different case than the "mute myself" which is apparently loop-back while connected to a server.

This "Sound Setup" is the place to select drivers, set the input level and be sure there is no feedback, while not connected to a server. The can of worms is that the input levels should be set according to the input meters and not the sound level heard at the output. This is not intuitive especially if one has ones headphones on. Having a fader to change the sound level in the headphones could be misconstrued as setting the input level, but if there is none the output levels could be uncomfortable leading people to wrongly reduce the input level.

Still looking for a solution to this problem other than having people read and understand directions, which I know will not happen.

[pljones]

I see this as a different case than the "mute myself" which is apparently loop-back while connected to a server.

It's not "loop back". It's more like being able to play along to a recording -- when the recording is playing, fine, but if you press stop, you can't play along any more. It doesn't entirely bypass the process. It needs to be receiving the audio to have something to mix in your local sound with. If you want to play without the recording, you'd have to unplug from the recorder entirely.

[dakhubgit]

At some point of time you need to decide whether you want to view things from an implementation detail perspective or the practical meaning to the user when deciding what feature to implement and where. It seems sort of arbitrary just when you declare one to trump the other.

[pljones]

No, it's a matter of hours in the day to get things done. Completely rewriting Jamulus is going to take time that could be better spent on other improvements.

[dakhubgit]

"I could never get my choir/ensemble/orchestra to use a software as cumbersome and puzzling to use as that, so I'll better invest my programming skills and energy into a different project" does not really put the potentially available manhours in the day to best utilisation. Working on UI issues sure comes at a cost but that does not mean that there is zero return.

[pljones]

You're not talking about a UI issue here. Changing how the audio system works in Jamulus is not part of the UI.

[pljones]

This "Sound Setup" is the place to select drivers, set the input level and be sure there is no feedback, while not connected to a server.

I was thinking this myself. Split up the "Settings" window. Have a separate "Sound set up" that lets you disconnect from the audio engine to allow the driver to be changed and set up (which is needed - you can't do that whilst the engine is running), and then has the input levels shown, without any level controls - but a hint to say "use your hardware input level to ensure the level here is right". This is where the "Audio Channels" setting would go, too -- it's currently apparently unrelated as "Misc" but the input channel mapping is related.

The network settings, jitter buffer, audio quality and monitoring would go on a "Network Settings" page.

That would leave "Misc" with Audio Quality (which is arguably "Network Settings"), "New Client Level", "Skin" and "Language" -- and the current additional directory server (which I'd like moved to the connection window...).

[pljones]

"New Client Level" could move to a "Mixer" menu, along with "Load Mixer Channels Setup" and "Save Mixer Channels Setup".

"Skin" and "Language" could go to the "Profile" settings (which is a settings page).

All of that argues for either a tabbed settings page or a Settings menu to access each page. It seems to be called "View" at the moment -- but has "Chat" on, too... which isn't settings... (This is straying into the menu chaos ticket -- but such is the nature of discussing the UI...)

[dcorson-ticino-com]

Please look at my NewUI-02. There I have already implemented a tabbed settings menu, which, of course, could still be improved.

[pljones]

Sorry, could you repost a link, please - there are over a thousand issues/discussions and it's hard to track them all.

[dcorson-ticino-com]

#1150