jamulussoftware
Please add a no Meter style selection option also
Describe the bug Several nice Meter styles were added to Jamulus without an option for No Meter. See #1688
Meter Style:
- LEDs
- Bar
- Narrow Bar
- Round LEDs
- Small LEDs
please also:
- No Meter
No Meter option: No initialisation, CPU load or Graphics (note that 150 channels multiplied by 9 LEDs = 1350 LEDs)
I'm hoping that the No Meter option will be implemented before next Jamulus version by someone who can do it easily (maybe the feature was overlooked).
To Reproduce
Expected behavior
Screenshots
Operating system All
Version of Jamulus Jamulus, Version 3.8.1dev-nogit
Additional context The mixer board meters should have a "keep it simple" option for Jamulus. See #1688 This large 19 file change would best be done by the people familiar with this code.
Only just noticed this issue.
So if you chose "No meter" you would have no visual indication of a channel (including yours) making a sound? Would that not also make Jamulus rather harder to use if you didn't know which channel level to adjust? Or have I misunderstood?
Q) So if you chose "No meter" you would have no visual indication of a channel...
A) Jamulus worked perfectly fine before meters were added. Having 'No Meters' as an option does not impact those that want meters. The meters have added a huge cpu load and code that defies the KISS principle. The load will, in the least, run batteries down quicker and possibly impact sound quality in some circumstances (even with powerful multicore cpus).
Is the slowdown a fact? If you want to go really "bare", you can use the headless client.
Is the slowdown a fact? If you want to go really "bare", you can use the headless client.
I was about to say that there is an option to disable the reverb, feedback, and a gain boost in the interest of the KISS principle. Why shouldn't this apply to computationally intensive LED flashing? When it hit me that the Client doesn't have the information to flash its LEDs. The Goddam server has to calculate every LED level for every client attached. . . .WTF?!! Jamulus has O(n^2) BLOAT that nobody knows about ! This feature will turn your gaming computer into a heater.
Removing LED’s client side will not help the server stopping to calculate the fader levels – unless we introduce a protocol message.
I think corrados removed the option to switch off the LED‘s some time ago? Probably this can be reverted.
Jamulus has O(n^2) BLOAT that nobody knows about !
Mixing already runs in O(n^2) on the Server but I assume you mean the client?
Mixing already runs in O(n^2) on the Server but I assume you mean the client?
The server supplies the channel LED level. If you connect to an old server, you won't get LEDs.
For reference, this is where the levels are calculated. They are not calculated on every frame, but rather every 200 frames. They are also calculated once for each client, so that sounds like O(n) and not O(n^2) to me. https://github.com/jamulussoftware/jamulus/blob/7d7b337355dce06c7a3b4df5f04ec1084980f695/src/server.cpp#L1771-L1779
A Jamulus server has 10 clients. How many LEDs need updating? Answer: Each of 10 clients will have 10 mixer channels with 9 LEDs per channel = 900 LEDs
A Jamulus server has 100 clients. How many LEDs need updating? Answer: Each of 100 clients will have 100 mixer channels with 9 LEDs per channel = 90,000 LEDs
When you go from 10 clients to 100 clients you have 100/10=10 times as many clients and 90,000/900=100 times as many LEDs, not 10 times as many LEDs as O(n) would be.
I think a server administrator (and some clients also) might want an option to disable the LEDs.
Uh... there isn't one calculation per LED, there's one calculation per client.
When you go from 10 clients to 100 clients you have 100/10=10 times as many clients and 90,000/900=100 times as many LEDs, not 10 times as many LEDs as O(n) would be.
The server's work is O(n) and each client's work is O(n). In combination that could be interpreted as O(n^2), but it's not running on the same machines. The number of LEDs doesn't matter as it's a constant factor and is a client-side implementation detail (the server only knows about levels, not about LEDs). Overall performance depends on server performance and performance of each individual client, not performance of all clients taken together.
Therefore, I think we'd need to rephrase the question:
- A Jamulus server has 10 clients. How many meters need updating for an individual client? Answer: Server: 10 level calculations, Client: 10 meters to display (90 LEDs if you want)
- A Jamulus server has 100 clients. How many LEDs need updating for an individual client? Answer: Server: 100 level calculations, Client: 100 meters to display (900 LEDs if you want) (The Server part is not repeated for each client.)
I think a server administrator (and some clients also) might want an option to disable the LEDs.
I don't disagree. My gut feeling is that the potential performance improvement is neglegible. Gut feelings are not a solid working base though, so I'm currently trying to get some numbers about what parts really do matter performance-wise.
There's no point disabling at the server - the calculation is less than trivial.
The only question is one of styling in the client UI.
The server sees O(n^2) operations on the meters even if zero mathematical calculations are involved because the server must send the data for n clients meters to each of n clients (cpu and network load). The only argument that can diminish O(n^2) for meters is that the audio mixer is O(n^2) also. But what proportion of O(n^2) does the meters use? If it is 1 percent, then a server that is maxxed out at 100 clients without meters will be maxxed out at 99 clients with meters (if it is 10 percent, you are down to 9 clients <-- correction 90 clients). I was thinking of a server that maxxes out at 10 clients would be limited to 9 with meters
I mean you could just comment the code/send fake data and this should tell you if there’s a chance in performance. I‘d believe that the led calculation runs in O(n^2) since the function is called for every client (I assume that) and there’s a for loop for each client calculating the fader levels (but I haven’t studied the code in detail)…
If it is 1 percent
Given that it's only calculated once every 200 cycles, it's less than 0.5%. It would be 0.5% if it took up all the time in that cycle when it runs. It doesn't. It takes a tiny number of CPU instructions compared with the whole cycle (possible under 10 CPU instructions compared with many thousand, though I've not looked at the generated opcodes). So we're talking less than 1% of less than 1%... Which I'd call completely insignificant.
And it's even less significant when spread over each client.
The only issue is UI styling.
Just to add some concrete data, here's a graph of mixing/encoding/sending time, level calculation time (both in ms) and number of clients. The results are not really surprising based on the above discussion:
(This is based on f8913a03)
So...
The only issue is UI styling.
This.
Thank you for all of the information and profiling. The only issue being UI styling in the client is reasonable. As long as the LEDs optionally don't flash and the GUI doesn't load down a single core 32 bit cpu, this would be wonderful.
Any news here? @henkdegroot @DavidSavinkoff would you provide a PR for this probably UI only related feature? I think in the past there was an option to disable LEDs already, but it was removed by corrados since he thought nobody is using it - I wouldn't certainly.
Also, I don't stand behind it since it adds little to no benefit. But if there is a strong request, feel free to implement it. If not, please close this PR.
Jamulus did not have a zillion indicators for each fader until this was added. In my opinion these indicators are a regression. I hate flashing lights and a real sound engineer doesn't need this many idiot lights. If you can tell me what needs to be changed, I may try to help in fixing this regression. The job looks daunting because it is not my code.
Related issue: https://github.com/jamulussoftware/jamulus/issues/638 and the related commit - hopefully: https://github.com/jamulussoftware/jamulus/commit/079f97511efa29026ccb724e5f341770f3a0cf85
I notice a few issues related to meter style, so perhaps include all in one PR?
I am thinking about adding a "second" meter style option so that the "own" level and the "mixer board" can be set indepent from each other and only do the "no meters" for the mixer board. This question came up in a reply when the meter style was introduced, to allow different styles to be used for the own meter vs the mixer board.
Eh... Please keep it simple. I don't know how much benefit that would have. It's a hack to "solve" the issue that one can't find their own fader quickly IMHO. But we have the own fader first option now.
Ah. Sorry now I understand: own signal = local signal. Still not sure if that makes much sense/gives benefit
Well currently there is logic that your own/local signal meter style looks different when you select the "small/narrow" options as these are intended for the mixer board "compact" mode. For instance, when you select small, you still get the "big" round LEDs. Allow a independent selection of style for your "own/local" signal, this can keep being shown while the rest of the mixer board may be without level meters.
Would "input meter style" be a better wording?
Would "input meter style" be a better wording?
Yes, I think so.
In general, I'm unsure how much demand for more styling/customization there is. To me it sounds rather niche and I'd like to keep it as simple as possible.
To me it sounds rather niche and I'd like to keep it as simple as possible.
So no meter style option would also remove the input meter? Or would that still show, and if so which type should it show?
The input meter was not part of the change so it should remain the same as before. Thanks.
The input meter was not part of the change
But the input meter style is part of the change. As the appearance changes depending on the selected style. So the "no meter style" option cannot be implemented without having effect on that. At the very least we need to define the style to be used.
The input meter was not part of the change
But the input meter style is part of the change. As the appearance changes depending on the selected style. So the "no meter style" option cannot be implemented without having effect on that. At the very least we need to define the style to be used.
I am not insistent on small details, that is why I mentioned this. I also don't want endless suggestions to be a blocking issue. The indicators are a good feature, especially when they can be turned off after you are satisfied with the setting. I am hoping the no meter option is easy to do with minimal code changes. :-)
Thing is that the no meter option will have to introduce new code/logic to cover the Input Meter.
Imagine to look of Jamulus when the high lighted red area is not showing anything.....this would mean the "no meter" option has to remove the additional text strings etc. and therefore adds more to the existing code.
If the "no meter" option is only applied to the mixer board, we are still left with what to set the input meter to. Hence the suggestion of adding a separate setting for the mixer board and one for the input meter. It is correct that this adds more code as well, but no much difference compared to the existing code and obvious it adds one extra setting to store.
Imagine to look of Jamulus when the high lighted red area is not showing anything...
_Maybe apply the "no meter" option to the mixer board first, then to the input meter later if necessary. _Maybe overwrite the input meter area with the "red muted banner" when mute myself is activated. And right-click to toggle (meters // unmuted banner) left-click toggle (mute on // mute off) _Maybe leave a realistic hole showing the inside of Jamulus! :-))