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.

[gilgongo]

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).

[ann0see]

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.

[ann0see]

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?

[pljones]

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.

[hoffie]

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.

jamulus/src/server.cpp

Lines 1771 to 1779 in 7d7b337

	bool CServer::CreateLevelsForAllConChannels ( const int iNumClients,
	const CVector<int>& vecNumAudioChannels,
	const CVector<CVector<int16_t>> vecvecsData,
	CVector<uint16_t>& vecLevelsOut )
	{
	bool bLevelsWereUpdated = false;
	// low frequency updates
	if ( iFrameCount > CHANNEL_LEVEL_UPDATE_INTERVAL )

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.

[pljones]

Uh... there isn't one calculation per LED, there's one calculation per client.

[hoffie]

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.

[pljones]

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