Local audio pan source documentation is very much wrong. #778
Comments
|
Another one:
This has nothing to do with having one or two input channels active. It means that you send a mono signal to the server (the balance in which may be determined with the local Pan fader) but are able to use the pan pots for placing the various sound sources in order to be able to better separate them in your hearing. It's actually a nice setting if
I actually have no idea what happens when you use that setting when somebody else uses "stereo-in": whether that stereo source will be down-mixed to mono before getting panned or not. |
|
Do you mean this page: https://jamulus.io/wiki/Software-Manual ? |
Yes, this is correct. |
|
On your first point about attenuation: is your complaint about the implementation of panning (should panning not attenuate the opposite channel?) or the effect of it (does this cause someone to make a mistake when using Jamulus)? What would be your recommendation? On your second point, yes, bandwidth might be an issue if you don't have/get enough. But that's the same for any other resource (cpu, buffers, etc.). Do you mean it should be changed? If so, how? BTW bandwidth is rarely a problem in reality unless there are a lot of clients on the server, in which case the server's network speed (but not the clients') may be a bottleneck. On your point about somebody else using "stereo-in" - @corrados can you comment on that? |
I have no beef with what the implementation does. However, the display is confusing enough that I looked in the manual for its meaning, and the manual gives a definition that could hardly be wronger, making me unable to talk to others. A first measure would be to stop the manual from being so awfully wrong. However, the best implementation is one for which consulting the manual is not necessary. To achieve that, I would place L at one end of the slider and R at the other end of the slider. Then I took a look at what Ardour displays for its pan slider: in the middle it's 'L: 50 R: 50' and to the left it displays 'L: 100 R: 0'. Now that's a mouthful, but it's only a mouse-over (also active while dragging), so it does not take space in the actual interface. Of course it also helps that the slider is horizontal: doing that in Jamulus would require more of a redesign. If one actually wants to display something, just displaying a single number -100 ... +100 (with the sign explicit and only left off at 0) would be fine: the dragging action would immediately make clear which is which and it's a single value you can tell others. If you want to show what is happening (and if off-center only attenuates the opposite channel), put a number behind each of the letters L and R, with the middle being L100 R100 and the left and right extremes, conversely, are L100 R0 and L0 R100, respectively. A change bringing manual and interface into agreement without changing the manual would display L: -5 when currently R-5 is being displayed. The colon serves to make clear that - is a numeric sign rather than a separator. However, I still think that this would be unnecessarily ambiguous/confusing.
The point was that the description is completely wrong. Mono-In/Stereo-Out treats the outgoing material exactly like Mono would. The difference is that you can then pan the various mono sources to individual locations. The bandwidth difference between upstream/downstream is likely too subtle a point to be made in the manual: I just pointed it out to make clear that the practical dropout problems caused by this setting might be less than the net increase in bandwidth would suggest.
|
gilgongo
changed the title
If you had a mic on R and a keyboard on L and you moved the slider up to R -50 (that is, take the volume of the mic down by the maximum amount) then nobody would be able to hear your mic. That would be the expected behaviour. So I'm confused as to what you mean here. I agree that it would be nice to label each end of the slider L and R so you knew which direction to move it in at first though. When you say the manual is wrong, would it be better to omit what appears to the be confusing part? For example: "Controls the relative levels of the left and right local audio channels. For a mono signal it acts as a pan between the two channels. For example, if a microphone is connected to the right input channel and an instrument is connected to the left input channel which is much louder than the microphone, move the audio fader to increase the relative volume of the mic." That way, it doesn't matter how the user interprets the numbers shown, it's the direction (L or R) that matters? In fact maybe it's better not to show any numbers at all? |
I take it you haven't actually tried it. R-50 mutes the left channel. |
|
OK (I've never noticed because all I'm doing to listening to the relative volume - can't remember which channel I have something on). How about we just remove any mention of L, R and +/- numbers? If so, that's an easy fix :-) |
|
For me the behavior is more than confusing. Again, a valid audio signal diagram would be helpful (where "valid" means doc == implementation). My HW setup:
In this setup it is not possible to have the drums mixed down to a mono signal and mix it with the microphone, so that in a session I could talk to the other musicians (muting the mic during actual playing) - what a pity. Test 1 (mic, mono): Settings/Soundcard/Device: in: Lexicon Win USB 3-4 In Only/out: Lexicon Win USB 3-4 In Only (no clue why only this works because the Omega outputs are always fed by USB 1+2, I think because Jamulus does not initialize the Omega correctly, visible by permanent blinking of the blue USB LED on the Omega which is steady on when I use Garageband); Test 2 (dr, stereo): Settings/Soundcard/Device: in: Lexicon Win USB 1-2 In Only/out: Lexicon Win USB 1-2 In Only My expectation was - regardless of the Settings/Misc/Audio Channels combination:
Questions:
|
Do you have any objections to my suggestions to address this? |
|
@gilgongo If you mean
for me the disadvantage is that I think you would kill the possibility to identify the center position of the pan fader. Above, I made "behavior" bold on purpose because this is what annoys me most, rendering the pan function completely useless. |
I think you need to explain that statement a bit more. If you have two different things on L and R and you pan between them, one gets louder on one side and the other gets softer on the other. Job done :-)
It would work as it does today: it would say "Centre" when centred. (I'm not qualified to comment on your test results I'm afraid) |
More likely than not that is a left/right confusion in |
|
My comment on the balance knob of Jamulus itself, is that the numbers displayed should not have a negative sign. Jamulus, otherwise, pans left to right as expected.
|
|
For the sake of clarity: can we agree that it's probably obvious what happens if the display is formatted as |
|
Sorry, it was absolutely not clear to me that "left and right local audio channels" refer to the output signal coming from the Jamulus server to be sent to the local audio interface. I took "local" to mean my "local" signal which I produce with my instrument. This needs to be made cristal clear in the "manual" https://jamulus.io/wiki/Software-Manual. So just to say "get rid of the documentation" is not OK. I mistook the pan and reverb faders to only affect my own signal which I send to the server. I think this has two reasons:
So my next question is: Which signal is affected by "Settings/Misc/Audio Channels"? My tests above have been done with only my own signal being sent from the iMac to my local Jamulus server on a WIN10 PC (where "local" means my Local Area Network). After another quick test (with my working "in: Lexicon Win USB 1-2 In Only/out: Lexicon Win USB 1-2 In Only" setting unchanged) just now I need to say that my "expected behavior" is fulfilled by the pan rotary knob above the channel fader. I will make another test (later, no time any more now) with a server where there are several users. "Useless" means that I did not want to produce panning for my signal sent to the mix so I leave the fader at Center" (same for Reverb - if this also affects the mixed signal coming from the Jamulus server I do not have any use for it). I already said elsewhere that I would be willing to help with the documentation (e.g. providing a proper audio signal flow diagram) but I do not have the time to reverse-engineer the code - so if it is true what Volker said that there is no technical documentation other than his http://llcon.sourceforge.net/PerformingBandRehearsalsontheInternetWithJamulus.pdf then I do not see a quick solution, sorry. Edit: Please disregard the first paragraph within this comment, I will edit this comment again as soon as things have been clarified in the course of my new Issue https://github.com/jamulussoftware/jamuluswebsite/issues/174. |
What happens is transparent, because you can hear the effect of using the slider with your own ears. What seems under contention is that if what you see in the UI is not aligned in your own mind to what you hear, then as @DavidSavinkoff says - remove that display and everyone will understand it. I guarantee that if we start changing the labelling to something else, then there will always be someone complaining that it doesn't make sense to them. It's just a slider between two channels. (@drummer1154 completely separate #778 (comment) notwithstanding) |
@drummer1154 OK this is a totally separate issue then. Please open a ticket to address this in the documentation: https://github.com/jamulussoftware/jamuluswebsite/issues |
Remove reference to the UI to avoid confusion jamulussoftware/jamulus#778 (comment)
|
Jonathan <notifications@github.com> writes:
> Once we are transparent about what happens, picking an actual
behavior becomes an independent problem.
What happens is transparent, because you can hear the effect of using
the slider with your own ears.
One reason to use the slider is to minimise noise when using only one
channel. How do I "hear the effect" happening on a dead input? How can
I respond to questions without starting experiments each time?
Particularly when the behavior actually depends on the settings of the
Mono/Stereo/half-Mono selector?
How do I reliably tell constant-sum amplitude from constant-energy
amplitude? For independent and correlated signals?
What seems under contention is that if what you see in the UI is not
aligned in your own mind to what you hear, then as @DavidSavinkoff
says - remove that display and everyone will understand it. I
guarantee that if we start changing the labelling to something else,
then there will always be someone complaining that it doesn't make
sense to them.
What is unclear about L100 R50 ?
…--
David Kastrup
|
|
I'm afraid I don't understand what your questions mean. The local pan is used to control the relative levels of the left and right local audio channels. For a mono signal it acts as a pan between the two channels. If you want an answer to "How can I respond to questions without starting experiments each time?" or "How do I reliably tell constant-sum amplitude from constant-energy amplitude? " then I don't know how changing the pan control's UI would help with that.
Nothing, other than how showing it would help any of your problems. This is - I have to say - and extremely confusing conversation. So perhaps I better drop out and let somebody who understands these points properly deal with it instead. |
In what direction? To what degree? What happens with the absolute level? That For the same situation |
|
|
|
In #778 (comment) I was requested to create a new Issue which I started editing. But the more features which have cost me unnecessary hours, would I have previously understood what they are actually doing vs. their GUI and documentation, the more I need to document them in the new Issue. So I will stop commenting here and emphasize on https://github.com/jamulussoftware/jamuluswebsite/issues/174 as soon as I have stored the new Issue and reference it here (done).
I can fully understand this comment and I am willing to sort out things as soon as I am finished creating the new Issue.
This is valid for a mono input signal being presented to both Left in and Right in, but what for a stereo signal? Edit: My tests have shown that the vertical "Pan" slider is NOT a pan but an attenuator for the (stereo) signal input from the audio interface, see my new Issue https://github.com/jamulussoftware/jamuluswebsite/issues/174. So 1) the GUI label is wrong and 2) the relationship to the Input section is broken by the vertical bar to the left of the slider in the GUI. |
|
The circuit works with: |
Not really. It looks like this inside of my analog mixer for a mono signal: In this case, I'd rather trust the manufacturer schematics than your word. And they use log/anti-log pot pairs here. Most relevantly, they don't distinguish between panning a stereo signal and panning a mono signal: you can simulate mono panning perfectly by connecting your mono signal to both channels of a stereo input and then using the stereo panner. Also signal levels for either channel change at every different angle: there is no constant level for either over a position range like it is with Jamulus. |
|
Your mixer uses log pot pairs (cw and ccw). Now you know that it can be done differently with one linear pot. And you got a plot of the transfer function also. The user documentation and board layout are the same, so there is nothing to complain about. |
Oh, I never doubted that using a linear pot in that manner would lead to different results.
The board layout is the same? News to me. The circuit isn't the same, either. If the pots were truly logarithmic and reverse logarithmic in the sense of the word, the result would be that what one channel gains in dB, the other loses. The actual aim is more that the combined output power stays constant while you pan. Which would mean that panning from center position to one side lets one channel gain 3dB when the other goes silent. |
|
Volker Fischer <notifications@github.com> writes:
> For the same situation L:0 R:100 is a completely transparent description.
I just did a quick test using your proposal:
Would you be happy with that implementation? BTW: Are the left/right
number now correct?
I find it weird to have R:100 at the top (panned fully right) and L:100
at the bottom (panned fully left). Of course, the vertical orientation
of that slider is making this sort of arbitrary, but probably due to
reading directions I would map left-right more likely to top-bottom than
the other way round.
However, I think your current labeling matches current behavior (which,
if I remember correctly, displays R-50 at the top position while panning
the audio fully to the right).
Current behavior feels upside down to me. If there were some sane way
to place that control horizontally instead of vertically, there would be
little question which way to orient it best.
…--
David Kastrup
|
|
I think the slider is better now. Including pan-right at top, and left at bottom. This is obviously a right handed slider (a right handed person rotates or moves the hand to the right to pan to the right). |
|
Apologies for the stupid question, but what problem is this UI change solving exactly? Is it that people are panning their channel one way (and hearing it panned correctly in their headphones) but then thinking the UI tells them something else has happened? Is that the issue? |
As dakhubgit correctly said:
Yes, there is a bug in the current Jamulus version. The left/right attenuations are incorrect. That should be fixed. I could simply swap "R" and "L" but since the range 0 to -50 is misleading, I wanted to improve the indicator, too. |
|
Jonathan <notifications@github.com> writes:
Apologies for the stupid question, but what problem is this UI change
solving exactly? Is it that people are panning their channel one way
(and hearing it panned correctly in their headphones) but then
thinking the UI tells them something else has happened? Is that the
issue?
Reading the docs then telling all their single-microphone comusicians to
move the slider to the wrong position for best effect?
Is there a particular reason why the display should be as confusing as
possible?
…--
David Kastrup
|
OK so in that case I take it @corrados UI change aligns with the suggested wording for the manual, yes? Controls the relative levels of the left and right local audio channels. For a mono signal it acts as a pan between the two channels. For example, if a microphone is connected to the right input channel and an instrument is connected to the left input channel which is much louder than the microphone, move the audio fader towards the indicator labelled "R" to increase the relative volume of the mic. |
|
Looking a while at my video in #778 (comment), I start to find it confusing to have two numbers there. I would prefer a solution where we have just one number. If you move the fader up, we are going towards the right channel so the label should contain an "R". And we also should have a number indicating the current location of the fader. We could define it as: percentage how far we are towards that channel. So it would range from 1 to 100 %. What do you think? So it would be: "center", "R: 1 %", "R: 2 %", ..., "R: 99 %", "R: 100 %". |
|
Percentages feel fine. They are universally understood and not ambiguous in this context as far as I know. |
|
Here is how the new proposal would look like in action: |
|
The number displayed for a balance control is not attenuation, not gain, not percent, and not decibels. Balance controls range from left to right as: 5 4 3 2 1 0 1 2 3 4 5 (eleven numbers). |
|
I fear we will have an endless discussion here about a trivial pan indicator... |
|
Furthermore, when the slider is at the top position, the display should show R:100% (or R:5) |
|
In #778 (comment):
Do you mean you would keep the current "unnatural" layout having right on top and left on bottom?
and I would confirm
|
|
Volker Fischer <notifications@github.com> writes:
Looking a while at my video in
#778 (comment),
I start to find it confusing to have two numbers there. I would prefer
a solution where we have just one number.
If you move the fader up, we are going towards the right channel so
the label should contain an "R". And we also should have a number
indicating the current location of the fader. We could define it as:
percentage how far we are towards that channel. So it would range from
1 to 100 %. What do you think? So it would be:
"center", "R: 1 %", "R: 2 %", ..., "R: 99 %", "R: 100 %".
What does R: 1% mean? That R is at 1%? And it is at 0% when in the
center? This is again completely meaningless regarding to what it tells
the user about what is happening.
…--
David Kastrup
|
Just an aside - the are no numbers on any of the scales in the Jamulus UI right now. Are we going to have a similar debate about all the others? |
|
Jonathan <notifications@github.com> writes:
> meaningless regarding to what it tells the user about what is happening.
Just an aside - the are no numbers on any of the scales in the Jamulus
UI right now. Are we going to have a similar debate about all the
others?
Good luck putting numbers on the various marks when the slider does not
even move in any sensible relation to the marks (try moving the slider's
mark to align with the top mark on the scale, for example).
…--
David Kastrup
|
To add a bit more substance to this: the point of useful marks is that you can convey them. This is particularly important with Jamulus since we are sharing only speech. If I tell my ensemble members "try playing mf and then adjust the gain on your sound interface until you reach, uh, the third tick from the top? Have four LEDs lit? Then everybody can just put the default level at 75% which is three marks below the top." --- except that Jamulus adds marks and LEDs according to the window size, and has no dependable relation of the top mark to the top position of the slider. Every person having worked with a mixer knows that one tends to have so-so controls for the gain, but very large and well-marked controls for the volume fader (and actually the LEDs are marked here as well). Being able to precisely adjust your gain given the feedback from the interface is important in connection with Jamulus remembering volume settings from one session to the next. |
Here is how stuff looks in Ardour in the master mixer strip. |
Things are getting too complicated. Maybe just remove the pan slider, that will solve the issue ;-).
So let's just fix this for now. I'll just replace the "L" and "R" in the current implementation and let everything be as is. |
|
Volker Fischer <notifications@github.com> writes:
> This is again completely meaningless regarding to what it tells the
> user about what is happening.
Things are getting too complicated. Maybe just remove the pan slider,
that will solve the issue ;-).
> That Volker himself got this wrong and nobody reported it since then
> is enough of a sign that this just is not something people will
> understand, I think.
So let's just fix this for now. I'll just replace the "L" and "R" in
the current implementation and let everything be as is.
You mean, let R-50 indicate that the right channel has been attenuated
by 100%? I repeat: that nobody has noticed for about a decade that the
display does not correspond with the documentation is not exactly an
encouraging sign regarding the obviousness of the interface.
…--
David Kastrup
|
Why are you talking about "%" here? I thought it would be meaningless to use percentage values. The intention long ago when I introduced the numbers was to just tell the user about the position of the pan slider in "ticks". The pan slider has a total of 100 ticks so you have 50 for the L and 50 for the R.
Show my mother the Ardour mixer strip and for she nothing would be obvious. Jamulus (and all real-time online jamming software) needs a learning curve. It usually takes at least three sessions until the first time users have setup all parameters (turn off Wifi devices, set Dropbox offline, do not watch Youtube in parallel, set the correct audio interface parameters, set your levels correctly, etc, etc...). Of course, you should design a GUI as easy and obvious as possible. But just look at this thread. Just a simple pan slider optimization gives us a controverse discussion. BTW, the "pan" in Jamulus is not the same as the pan in Ardour. E.g. if you use the Mono-in/Stereo-out mode, you "pan" between the two input sources (mic and instrument). So even the name "pan" in Jamulus could be misleading. So I think "keep it as simple as possible" would mean in this regard: The intention of the pan value is to give the user a number which represents the location of the slider. So if the user had set the slider to a value which works fine for him, he can simply remember the number which is shown. |
|
I refer to the initial post in this issue:
The bug is fixed now. Therefore I would like to close this issue now. Any objections? |
|
Aye! I'm in favor of closing it. |
|
No other opinions since 11 days -> closed. |
The Wiki of the software documentation states for the local pan control:
It turns out that the maximum setting, L-50 does not attenuate the left channel by 50dB or 50% but actually attenuates the right channel by 100%, leaving only the left channel (current Linux version from master, but I consider it likely that it's similar for other platforms).
That's less than helpful for those people who actually read the documentation rather than try things out.
The text was updated successfully, but these errors were encountered: