Jamulus
Multi Channel Fader on one Jamulus #1063
Replies: 27 comments 3 replies
-
|
You can hook up a DAW to Jamulus - but it depends on having routing that both ends understand. JACK on Linux is fine. I can't comment on MacOS. On Windows, I run it using Reaper with about 60 or 70 different local channels running through the mixing desk before being routed out to Jamulus and the return audio fed back again. |
Beta Was this translation helpful? Give feedback.
-
|
Ok but all the channel are local, only for you... The other member see only one channel. I was asking for a way to send multiple channel like I was using multiple Jamulus, so every member can adjust their own audio. |
Beta Was this translation helpful? Give feedback.
-
|
You can run multiple instances of Jamulus, too, if you do it right - that gives that level of control, too. |
Beta Was this translation helpful? Give feedback.
-
|
But running multiple Jamulus add up also all the output from the server, but they are not needed... So I was thinking at a solution to send multiple separate channel in a Jamulus Server, but to have only one feed to ear from the server. |
Beta Was this translation helpful? Give feedback.
-
|
Two input channels on one client of software adds to the server just as much as two input channels on two clients. It makes no difference - it's just as much network load and CPU load. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, if I send two signal it's the same as two client, but if I use two client I receive two mix down audio from the server... but I only need to ear one. So in this case the server is creating a mix track that i never listen and so utilizing cpu and internet. Also in the current state i have Mono/Mono, Mono in/Stereo out but can't send a stereo signal but earing a mono mixdown (Stereo in/Mono out) |
Beta Was this translation helpful? Give feedback.
-
|
Actually, yes, you're right about the amount of data from server to two clients being more... (By the one downward stream, plus, if you use them the couple of bytes for the levels.) -edit- Oh dear, must have been a bad day: yes, everything to the second client would be extra... |
Beta Was this translation helpful? Give feedback.
-
|
If you're under Windows, Voicemeeter might be a good solution for you. You can mix up signals from different audio sources and it lets you control each signal's output, so you can adjust volumes as you'd like. I'm using it so I can have my guitar and my computer's microphone going into Jamulus at the same time, so only one Jamulus client needs to be running. The same can be accomplished under Linux by using Jack and alsa_in to mix multiple audio interfaces together. In MacOS, from a fast google search, it appears this is also possible by creating an "Aggregate Device". |
Beta Was this translation helpful? Give feedback.
-
Yes. But as saied already, in this way every other member in Jamulus get only ONE fader in their mixer! And because I use this in a live streaming situation some friends have a "sing mic" (mono), and instrument (stereo or mono) and a "non live mic" (mono).
Only you are able to set the mix about mic and instrument volume... so if another person in jamulus don't want your voice so loud they can't do anything... in our setup with multiple Jamulus client we can have fader for every things! So everyone can have their right mix in their ears! All of this create pointless use of server cpu and bandwith! I don't know if it's simple or not to implement. But a first step is to divide the "send" from the "receive" so later it's just more socket that has to be open to send multiple channel... and we can receive what we need only one time! Also in this situation we could send a stereo signal (so if someone use stereo as return can listen the instrument in stereo) but recive a mono mixdown! |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps an easier way to implement this functionality is for the Jamulus client to start as a secondary/slave mode in second/third/... instances on the same machine, where it only contributes with an upload stream and doesn't request a download mix from the server. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a happy camper who would be even happier with the multiple fader feature. |
Beta Was this translation helpful? Give feedback.
-
|
@kilcup you can use --clientname to rename each instance |
Beta Was this translation helpful? Give feedback.
-
Thanks for the tip @Snayler ! I was experimenting with multiple clients yesterday and found out that using |
Beta Was this translation helpful? Give feedback.
-
|
If the option to split somebody's stereo (or dual mono) feed to two faders would also include the pan control (plus level meter, mute and solo) - we would be able to do true panning of stereo/dual mono feeds, both signals independently. No more forcing everybody else to hear my guitar in one ear only and my singing in the other :) As implemented now, for stereo feeds, the pan control actually acts as a balance control (not pan). Only if the source is mono it acts as a pan control. Of course - the performance hitting work-around is to run multiple Jamulus clients - as mentioned. |
Beta Was this translation helpful? Give feedback.
-
|
A compromise I have tested is to change the server's implementation of how to pan a stereo signal. Assuming I send in stereo (but really dual mono A and B): The compromise is others still cannot set A and B:s levels individually (or mute or solo them). |
Beta Was this translation helpful? Give feedback.
-
|
I really love this! Would be a fourth option in the settings: should we try to do it and create a pull request? Does not hurt... In a second step one could implement displaying two faders in the client in this case... |
Beta Was this translation helpful? Give feedback.
-
|
I would greatly appreciate the ability to control the volume level of each of the two channels individually. The solution to use multiple Jamulus clients for the individual channels will work with sophisticated user in a band that rehearses regularly, but is not practical for casual jam sessions with folks you meet on Jamulus. Most users have voice in one channel and instrument in another and set the relative balance to suit themselves. The balance a user sets, takes into account acoustic energy from their instrument or voice in addition to what they hear back from Jamulus in their headphones. The relative balance the musician sets for themselves may be very different than what other musician on the session require. |
Beta Was this translation helpful? Give feedback.
-
|
Being able to have a client show up as two channels (left and right - mono) would be an excellent feature. slimvince stereo spread control as an option on a Stereo channel would be an acceptable first step - perhaps sharing the Pan control (toggle from Pan to Spread - or set from a client setting). |
Beta Was this translation helpful? Give feedback.
-
|
I'm another voice in the crowd that would love to see an implementation of this. I'm also a professional software developer, so I'm going to take a crack at the code and see if I can find a path that isn't too intrusive. The idea of a send-only client is a good one, and would theoretically mean minimum changes server-side (just knowledge to not send a mix back to the client). On the client side, a first pass could be a separate instance with a very reduced UI (only really need the level meter, as the "master" instance gives all the network health and mixing interface needed). Anyway, I'm going to fork and play with the idea a while. I'm primarily a Windows and Linux developer (although, ironically, I'm running Jamulus on a Mac Mini), so I might not be able to do good UI work for the Mac version. |
Beta Was this translation helpful? Give feedback.
-
|
@Lotharyx Would your idea of a send-only client look like an output device to the client computer? Then it could play an mp3 on one channel? |
Beta Was this translation helpful? Give feedback.
-
|
@gene96817 That's not my current intent, no. However, that would certainly be a useful feature. I also think it would be useful to have Jamulus be able to serve as a VST plugin for better DAW integration, but that's definitely not what I'm looking at right now. |
Beta Was this translation helpful? Give feedback.
-
|
Better audio routing is a very important feature. Almost everyone jamming has a mic in addition to their instrument, usually for talkback and often for singing. Having separate controls for these two signals is key for musicians to be able to set up a clean mix for themselves. For anyone looking to use jamulus for a live broadcast, the remote audio engineer needs control over vocals/instruments. Being able to assign each instrument to a discrete USB audio interface output would be huge for professional applications. Using multiple clients might be a temporary workaround, but these features should be high priorities on the roadmap as they affect adoption. |
Beta Was this translation helpful? Give feedback.
-
|
Hi all - so that we can keep Issues to actionable backlog items, I'm moving this to a discussion if that's OK. Once we have some agreement on how best to implement this we can add the relevant issue(s). |
Beta Was this translation helpful? Give feedback.
-
|
Please continue working on this - I am another voice in the chorus crying for a possibility to transmit all soundcard inputs as separate, fully controllable channels to all other users, without having to tinker with several Jamulus instances. |
Beta Was this translation helpful? Give feedback.
-
|
I think #1840 might be interesting for you. |
Beta Was this translation helpful? Give feedback.
-
|
And thank you for your great work so far ! |
Beta Was this translation helpful? Give feedback.
-
|
Keep in mind that we all should think about the amount of necessary bandwidth on both client and server side and necessary CPU on server side. "Less is More" ! |
Beta Was this translation helpful? Give feedback.
-
|
The bandwidth and resource demands on the server would be no different from the demands of another musician joining the session. Whether the client side has the upstream bandwidth available for the additional channel isn’t really the software’s concern. This feature wouldn’t prevent a user from using only one channel if bandwidth were the limiting factor. “It uses more bandwidth/CPU time” isn’t a compelling reason not to offer the feature as an option.
Less is certainly not more when it comes to controlling a mix where every source is, in effect, direct.
… On Jun 29, 2021, at 7:07 PM, Julien Taverna ***@***.***> wrote:
Keep in mind that we all should think about the amount of necessary bandwidth on both client and server side and necessary CPU on server side. "Less is More" !
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
The bandwidth is important. Running multiple instances to allow a fader per
input is taking up server bandwidth by having to send the mix to multiple
client instances. Right now, every instance is a full client when that is
not necessary for multiple tracks from the same computer.
A: Add a setting (cmd option) and code to make an instance "secondary". The
server would get that flag and not send a mix back to secondary
instances... only to primary instances. That alone would cut way back on
the bandwidth when peeps are running multiple clients to allow multiple
channels. A Secondary instance would also not try and share the local
outputs which cause problems now.
B: Add a Dual Mono setting that takes its input from the same Stereo pairs
allowed now. But, it sets up two mono channel strips. This should not be
that hard. A Stereo setting takes two inputs and sets up one Stereo strip..
How can simply setting up two mono strips instead of one stereo strip use
up more bandwidth or be that difficult? Maybe I am missing something? This
would get rid of the need for two instances when people want two mono
inputs. A single instance could be Mono, Dual Mono, Stereo or Stereo
to Mono. I am sorry.. there may have been other options?
C: Add a multiple instance configuration GUI to assist people in
configuring settings for primary and secondary instances. Sending as many
inputs as they want. The settings would be saved to a file and when
starting up the primary instance, the file would be loaded and the
secondary instances would be launched as child processes with hidden
windows. I do not think a UI is needed for the secondary instances in this
case. Closing the primary closes all the secondaries.
With these changes, Jamulus would be able to send as many inputs as anyone
desires and set up the channel strips as desired. Only one UI would be
active and setting the one mix stream to send back to it. It is not a
bandwidth hog, It saves bandwidth. After all, if you have multiple players
using a single computer for Jamulus, that is less bandwidth than having
them each use a different computer... or using an instance for each of
them.
Of course, if a single instance could be changed to allow as many channel
strips out as you want, that would be better. But, using multiple non-ui
instances will make no difference to the users. It will basically look the
same to them.
The ability to assign multiple signals to their own channel strips will
make Jamulus much more friendly to the users. So, Jamulus will get used
more over time.
…On Tue, Jun 29, 2021, 7:07 PM Julien Taverna ***@***.***> wrote:
Keep in mind that we all should think about the amount of necessary
bandwidth on both client and server side and necessary CPU on server side.
"Less is More" !
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1063 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASIHVV4673GUQF6YHPXNQWDTVJGZRANCNFSM42BJZAEQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
I want to add a +1 for the idea of a multi-input function in the GUI, and keeping the streams separate so they are mixable on other clients. This would provide a key functionality- the ability for each participant to create custom mixes with control over each signal. I am a multi-instrumentalist, maybe someone wants to balance my vocals and my instrument differently than I sum them. Or maybe a drummer feeds in separate kick/snare/OH and I need to have louder kick when I am playing bass. It would be amazing to send multiple inputs and mix other feeds in a single pane of glass, at the risk of some increased bandwidth consumption requiring lower sample rates. |
Beta Was this translation helpful? Give feedback.
-
I play with some friends... All of them have a simple request...
A way to send to the Jamulus Server multiple audio over different fader in the mixer, all of this can be Mono or Stereo.
Example:
I have a microphone, it's mono, so in the first channel I set it in mono, then i can select what device, and the input channel of that device.
After that I have a Keyboard, so in the second channel i can set it in stereo (stereo->stereo, for send two channel, or a stereo->mono to mix down a mono track), then i can select what device, and then i can select the two channel.
After the input I can select if i want a mono or stereo return from the server to hear in the headphone.
We ask this because we all have to open more Jamulus each time, and this leads us to throw away server bandwidth.
We need everyone to do their own mix on headphones, some musicians have two or more keyboards and a microphone, so they start jamulus many times.
If you put together all the open Jamulus as a second or more channel (99% in stereo) we find ourselves having a lot of bandwidth thrown away by the server because the server sends the mix to all the jamulus.
It would be nice to have a setting for unlimited channels. every channel could be mono or true stereo or a strereo mix down mono, every channel could select a different audio device and different channels, also a different name.
In this way you can eliminate the complexity of running multiple Jamulus client and the extra bandwith trown away.
Beta Was this translation helpful? Give feedback.
All reactions