Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to adjust the balance between the two channels of other musicians #723

Closed
alanz1357 opened this issue Nov 14, 2020 · 19 comments
Closed
Labels
feature request Feature request

Comments

@alanz1357
Copy link

An issue I frequently encounter is Jamulus sessions is the balance between the two channels supplied by other musician on a session are less than optimal.

For example sometimes a user's guitar drowns out their vocals, or their voice is too loud and masks their keyboard playing. The only way to fix it now is to either have them go stereo (using the pan control as a balance) and have the two channels hard panned hard left and right (which I find disturbing), or ask then to control the relative balance at the source (what works for the person originating the sound my not work for other users).

A possible solutions might be to have a mode where the pan knob act instead as a balance between channels. In that mode the panning ability would be lost (to me a worthy tradeoff). If another knob could be added we could have both balance and pan. When using the knob as a balance the sound would be a balance of two channels but mono, but it would be nice if it was possible to designate individual musician as stereo if their instrument were stereo (such as a vdrum kit or stereo keyboard instrument).

Thanks for considering this feature request.

-Alan

@corrados corrados added the feature request Feature request label Nov 14, 2020
@corrados
Copy link
Contributor

Actually, I was also thinking about adding such a feature. Unfortunately, quite some work is to do to support this since the server audio processing must be modified and the protocol must be adapted for the new mode.

@guixers
Copy link

guixers commented Nov 23, 2020

This could be a great addition. In order to emulate a real mixer the personal mix really should have 1 Volume/pan per channel sent... Meaning if someone is sending stereo there would be 2 Volume/Pan. This would be much easier to understand than having 2 different pan modes. In the end the background processing would be the same. It also would help to name each channel so receivers could see which channel is which without having the sender have to play to test .

Maybe there could be an advanced option to have the volume/pan occur in the client so less server side work is needed, just send the channels as they come unless they are muted in the client ( meaning the client doesn't need them at all!) .
I know this is against the current idea of the server (doing the mixes in the servers to save streaming capacity) but again for low number of people/people that live close to each other, this actually could work better.

I would call this option "Local Mix At The server " as it happens at the moment and set by default. if unticked sever would send all tracks to client without mixing at all

@kwindrem
Copy link

You'd really not want a true stereo client to appear as two separate channels in the mixer. It's ONLY if the client was sending "dual mono" signals. That would be an additional selection added to "Mono/Mono In/Stereo Out/Stereo. I'd recommend splitting the input and output selections: Input: Mono/Dual Mono/Stereo; Output: Mono/Stereo.

@guixers
Copy link

guixers commented Nov 23, 2020

Well that depends.
If the client is sending stereo but they are sending 2 instruments.. I want to see 2
if the client is sending 1 instrument in stereo obviously .

@kwindrem
Copy link

I make the distinction between "Stereo" and "Dual Mono". Stereo is a single source with a left and right signals pair. Dual Mono is two distinct sources each with a single signal.

I agree that Dual Mono configuration should result in two channels with independent fader, pan, Mute, Solo and Group buttons. For stereo pan is really balance, that is, it adjusts relative level of the left and right signals.

@iainhallam
Copy link

#96 also seems relevant.

@iainhallam
Copy link

I'd recommend splitting the input and output selections: Input: Mono/Dual Mono/Stereo; Output: Mono/Stereo.

Generalising this would work as Mono/Stereo/Multichannel, which is then ready for sending multiple streams later, not just two.

@corrados
Copy link
Contributor

Generalising this would work as Mono/Stereo/Multichannel

That's why we have two separate Issues. This Issue is just about a solution which could be implemented with relatively little changes in the code. The other Issue #96 is a solution which would required significant changes in the Jamulus code.

@iamthechrisb
Copy link

I'd really like to see a fader for each input. I also think.. it could greatly help recording as well. I've been doing some recording and get complaints when we change input/output routing to separate the tracks. It forces having to record with different monitoring than they are used to performing with.

@kwindrem
Copy link

Add my desire for separate mixer channel levels when a client is in "dual mono" mode.

While the sending client can adjust input levels to their audio interface, each musician may need a different relative level for the two sources. For example, someone singing vocal harmonies may not be at all interested in the rhythm guitar while the keyboard player may need lots of rhythm guitar and little or no vocal. It's why each musician has separate faders for each client.

A dual mono system goes a long way. For those that need more than two separate sources, a second, third or fourth client can be used.

@guixers
Copy link

guixers commented Jan 21, 2021

Such an easy fix! 1 Fader per remote input.! :- )

@andreaskagedal
Copy link

andreaskagedal commented Feb 13, 2021

+1 for this request/solution.

I have several friends who where two people share the same jamulus client/sound card. This proposal would make it much easier for the rest of the band to handle them as separate instruments/vocalists.

@gilgongo
Copy link
Member

gilgongo commented Feb 19, 2021

Just as an aside: we can make the documentation clearer that it's preferable to have separate client instances per voice / instrument (since each client can be given its own ini file) and that you cause others problems by using the built in mono pair to stereo mixer. So I'll open that for discussion on the docs repo. https://github.com/jamulussoftware/jamuluswebsite/discussions/320

@insolace
Copy link

Rehearsing for worldjam last night, our guitarist/singer was struggling for an hour trying to balance their guitar and vocal. They aren’t very technical. We got them to run a second client as a workaround, one client for guitar, one for vocal. For everyone else this was an incredible improvement, we get separate faders.

But see the attached screenshot to get an idea of what this not-technical musician has to juggle while trying to perform. Keep in mind, worldjam has separate servers for soundcheck, waiting room, and performance, so they have to simultaneously change servers in two clients and juggle two clients to adjust their own guitar/vocal levels.

This should really be built into the client. If we can run two instances and transmit to the server that way, please let us run a single instance that transmits two mono streams. OR - create a dual client that runs two instances but merges the faders and syncs the server settings.

D41E5D9F-862D-44F8-8E99-52BB2F2ACAFE

@gilgongo
Copy link
Member

Moving to a discussion as there's some debate pending any action on this it seems.

@gilgongo gilgongo reopened this Mar 26, 2021
@insolace
Copy link

Was this meant to be moved to a discussion or kept here as an issue?

@gilgongo
Copy link
Member

@insolace We're trying to keep the Issues to a list of actionable specs for work (leading to PRs mostly) which have previously been discussed and agreed here.

Of you think it has been sufficiently agreed as to how this feature would be done, then feel free to write that up in an issue, or open a PR - and either case reference this discussion.

(We intend to publish this process soon BTW)

@insolace
Copy link

Ok, I will keep an eye out for the published process.

@gilgongo
Copy link
Member

In a nutshell: Discussions to be started for all things that aren't fairly clear bugs, and once something gets to a resolution, somebody can open an Issue or create a PR for it, and reference the Discussion.

The problem previously was that the Issues have filled up with things that look like feature requests etc, but are in fact unresolved discussions. So it gets too hard to work out what needs doing.

@gilgongo gilgongo closed this as completed Apr 2, 2021
@jamulussoftware jamulussoftware locked and limited conversation to collaborators Apr 2, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
feature request Feature request
Projects
None yet
Development

No branches or pull requests

9 participants