Lock fader/channel positions

[sthenos]

As a sound engineer for the world jam shows, where we are mixing bands with sometimes 20 channels, the current process when people join a server can cause faders to "move around". On a traditional mixing desk, the faders are always in the same position unless you wire them up differently. This means that when you are mixing and "riding" a fader say of a guitarist during the lead solo, if someone joins the server at the time, this fader could move position, your hold is unlocked and the mix can be detrimentally affected.

I know we have the sort features now built, which make it great for initially sorting by name of instrument. But Ideally I would like to be able to lock these positions so they don't move and any new people joining the server, are added to the far right of the channels instead of potentially squeezing in between some existing channels.

Is this at all possible?

[houbsta]

I would agree that making new connections' fader position predictable, and being able to fix current fader order, is essential for any live mixing scenario. Jamulus is a fantastic tool to do this, even remotely, in order to provide a monitor mix for listeners whether that be WorldJam or other online streaming initiatives.

[storeilly]

I'm interested in this as the same concept could be used with choirs. I think that anything that can be used from the user's profile to 'seed' the call to GetFreeChan(); in server.cpp should theoretically give us a start with this. I tried to do something with this using the client's source port on #666 but I don't think Volker understood.

Stephen

[corrados]

This means that when you are mixing and "riding" a fader say of a guitarist during the lead solo, if someone joins the server at the time, this fader could move position, your hold is unlocked and the mix can be detrimentally affected.

I see your point.

If you lock fader positions, what should happen if one of these clients disconnect during a song because he has technical issues and just want's quickly disconnect and re-connect? In that case the other faders have to move. And when he comes back, should he appear at his old place of at the right of the existing fader like he was not locket at all?

[corrados]

I just checked in the code. Your feature should already be implemented in the current Jamulus version.

At the Worldjam, as soon as all musicians which are playing the current song have entered the Jamulus server, just press, e.g., Ctrl+i to sort by the instrument. If after applying this shortcut new clients enter this Jamulus server, their faders should show up at the right of the existing faders (as was your request if I understood correctly).

Of course, a critical thing is still if "old" players are still on the server when the new song starts. If they disconnect during the next song, the faders will move to the left. But I think this will also happen if you would introduce a new "lock faders". So you have to make sure that no musicians which are not playing the next song are connected to the Jamulus server.

[maallyn]

I think the objection is the 'shift left' issue. I notice it when I am on an ordinary jam session and people come and go. I will hover over a fader only to find it shifted while hovering over it, deciding whether or not to move it.

[houbsta]

This is quite a hard problem because musicians may not all change between songs as one band replaces another but perhaps the rhythm section stays for the next song. So there are often "old" players on the server at the start of a new song, but perhaps sorting and seeing them move is not too bad.

I can certainly live more easily with a musician disconnect/reconnect moving their fader to the rightmost column - if this were to happen mid-song it would be noticed and cause the audio engineer's attention to be on the right place anyway as they would know the person would reappear to the right hand side. Also, this doesn't often happen unless someone has a big technical issue their end.

[houbsta]

In any case, my expected "default" behaviour would be a simple rule where most recently connected users appear on the RH side (i.e. always end of list), irrespective of whether they were on the server before. Having previously seen clients appear elsewhere would be a user-set preference "remember fader positions of previously connected clients" rather than default behaviour.

Any other rule means that faders to the right of a connected user who gets their "slot" back somewhere else in the queue will shift n faders to the right of them one place, and thus your memory of where musicians are on the console is broken.

[maallyn]

Am I correct that once the Control i is pressed; if a musician breaks connection, there would be a gap on the panel that would stay a gap and that any new connections would go on the right hand end. As the jamulus event goes on, musicians come and go as we progress from set to set, the jamulus panel would be full of gaps, but keeps being built to the right. I would think this would create a very long panel with lots of gaps. I would think that it would be appropriate for a mechanism to 'shrink' the gaps periodically; perhaps at stage jump times; to keep the overall length of the panel reasonable.

[corrados]

In any case, my expected "default" behaviour would be a simple rule where most recently connected users appear on the RH side (i.e. always end of list), irrespective of whether they were on the server before.

I totally agree with you. That should not be a big deal to implement this. I'll look into this soon. @sthenos Would that solve your issue?

[houbsta]

Am I correct that once the Control i is pressed; if a musician breaks connection, there would be a gap on the panel that would stay a gap and that any new connections would go on the right hand end. As the jamulus event goes on, musicians come and go as we progress from set to set, the jamulus panel would be full of gaps, but keeps being built to the right. I would think this would create a very long panel with lots of gaps. I would think that it would be appropriate for a mechanism to 'shrink' the gaps periodically; perhaps at stage jump times; to keep the overall length of the panel reasonable.

Gaps are never visible in the UI as in my (limited) understanding of the code flow the list is rebuilt on each sort/connection event.

[maallyn]

I think that the difficulty on the part of the sound engineers is that the rebuilding is causing the faders to jump from under the sound entineer's cursor when someone leaves the set.

As suggestion I would have is that when press the control i, all positions would be frozen. If someone leave, a gap would remain in that person's slot on the panel so that other faders would not shift around. Then, between sets or at least at stage jump, the sound engineer can press control i again; that would unfreeze their panel; gaps would dissapear; musicians come and go; then the sound engineer would press control i again; once again freezing everyone's position on the panel.

[sthenos]

In any case, my expected "default" behaviour would be a simple rule where most recently connected users appear on the RH side (i.e. always end of list), irrespective of whether they were on the server before.

I totally agree with you. That should not be a big deal to implement this. I'll look into this soon. @sthenos Would that solve your issue?

Yup thanks @corrados . This would solve the issue.

[corrados]

If someone leave, a gap would remain in that person's slot on the panel so that other faders would not shift around.

That is not supported in Jamulus. The fader GUI control can be either visible or hided. There is no "empty fader" control. And actually I think the Jamulus users would think this is a bug in the Jamulus software.

Yup thanks @corrados . This would solve the issue.

Thanks for the feedback. The new implementation is available on the Git master now. I'll close this Issue now.