Add rudimentary compressor and LPF/HPF

[reneknuvers]

I would like to see a rudimentary compressor function, to eliminate issues by inexperienced users with their gains turned up too high. Opus doesn’t seem to handle clipping signals all that well. A very basic ‘AGC’ algorithm could help.

As an alternative a long stretch RMS calculator could drive on screen hints ‘you are loud, turn down the gain on channel 1/L’.

the most rudimentary solution would be a clipping indicator.

To give the opus encoder a good time while creating a better sound experience at the same time, a selectable -6dB/oct low pass and high pass filter (or maybe a bit steeper) at a fixed frequency (150Hz and 10kHz) would be nice. It would kill microphone rumble and eliminate hard to encode high pitched noise. Filtering could take place on the clients side as there is probably the most available computing power, plus this would not harm any other musician on the server.
By nature the filtering would add a bit of latency. The choice of FIR or IIR filters determines sound quality, processor load and added latency.

Above the input VU, switches with a control light would activate the compressor, LPF and HPF.
When a mic or similar instrument is selected in the profile, a suggestion is made to engage both LPF and HPF. Other instruments may suggest this too, either one of the two. Decision is hard coded and should be based on experience and instrument’s harmonic content.

Compressor is engaged by default and can be turned off by the user. VU is augmented with a Gain Reduction meter running top-down.

All settings are retained in the local client configuration.

[ann0see]

Hi thank you for opening this issue.

I would like to see a rudimentary compressor function, to eliminate issues by inexperienced users with their gains turned up too high.

Not sure if a compressor is the right thing here (especially if it adds complexity in the Jamulus source code and modifies audio signal)? It doesn't fix the core issue with high input gain:

I think it should be possible to tell them how to turn down their gain in Windows/macOS, since it's probably only a one time action. Also, they could move away from their mic?

The next version will have basic feedback/clipping detection: #1179

the most rudimentary solution would be a clipping indicator.

Not sure, but don't we have this already (at least in fancy mode)?

So you'd suggest adding

1. A compressor
2. High-pass and Low-Pass filters?

[ann0see]

Yes. Probably adding some features could be valuable for semi-professionals or people who get an explanation from someone who understands audio engineering. However I think it's really difficult to ensure it doesn't add more complexity for inexperienced users and developers (keep KISS and Do one thing and do it well in mind).

Also, you could just use a DAW and some plugins and route the output from the daw to Jamulus.

[insolace]

I appreciate the need to ensure a tight user experience. However having used all three major jam platforms, none of them is a simple
user experience, jamulus included.

jamming online is not a simple task, and giving the end user control of network jitter, audio driver buffers and quality settings etc, but not giving them very basic controls over things like EQ seems inconsistent. You’ve now made it very hard to do a simple thing. Most musicians understand what an EQ is and many have heard of a compressor. In either case, a simple on/off button for both, and only offering them an “advanced” skin should easily preserve the current user experience.

Your point about plugins is on the right path, why not limit the development complexity and just support standard vst plugins like Jamkazam, Sonobus, and almost every other audio software does?

Having read these discussions for a bit, it seems there is a real resistance to following some of the simpler conventions that most audio hardware and software devices use, conventions that make things more familiar and intuitive. I’m not suggesting you re-invent protools here. But I am seeing your end users having to jump through hoops and complicate their experience just to try to do simple things. Things like running two clients for two instruments, and using third party software to route audio into and out of other programs just to get a simple EQ - none of this is KISS.

If the issue is management of development resources to implement things effectively, then that is something I understand - trust me. If I can come up from air at my day job anytime soon you might see a PR from me someday.

[ann0see]

Nobody stops you from adding it yourself and opening a Pull Request ;-). However there's no guarantee that it gets merged.

[hoffie]

Nobody stops you from adding it yourself and opening a Pull Request ;-). However there's no guarantee that it gets merged.

I agree, but maybe it makes sense to check here if there is willingness to accept such a feature from @jamulussoftware/maindevelopers to avoid work in a PR without a chance of being accepted.

My personal stance: I think we should aim to make it possible and easy to do add such filters, but I'm not convinced that we should extend the built-in integrated pre-processors in either clients or servers.
Therefore, I'd be open to PRs which add interfaces to VST (there was some work already, I think?), LV2, LADSPA or similar (ideally there'd be one generic way...?), but not open for "Add an EQ", "Add a limiter" and so forth as I fear it would be hard where to draw the line.

In other words, keep Jamulus simple, but still make it possible to work with other, more targeted components such as filters.

[softins]

Having read these discussions for a bit, it seems there is a real resistance to following some of the simpler conventions that most audio hardware and software devices use, conventions that make things more familiar and intuitive. I’m not suggesting you re-invent protools here. But I am seeing your end users having to jump through hoops and complicate their experience just to try to do simple things. Things like running two clients for two instruments, and using third party software to route audio into and out of other programs just to get a simple EQ - none of this is KISS.

If the issue is management of development resources to implement things effectively, then that is something I understand - trust me. If I can come up from air at my day job anytime soon you might see a PR from me someday.

That is exactly the issue. None of the main developers works on Jamulus full time, although sometimes it can feel like it! Most have jobs or study in real life. At the moment, most of our available time is taken up evaluating and approving pull requests, and responding to issues and discussions. That doesn't leave a lot of time for longer-term architecture or major implementations. So if there is a specific feature that someone wants, we do encourage them to discuss it first and then work on their own implementation to submit as a PR.

[dcorson-ticino-com]

Not sure, but don't we have this already (at least in fancy mode)?

There is a clipping indication in all 3 skins.
I do not think that we should be doing anything that reduces the audio quality like compression.
It is a one time setting to set your input volume correctly.
Once you know how it is just a couple of seconds to check after connecting with mute myself set.

For my ears there is often already distortion before clipping sets in.
That depends on the audio hardware of computer or interface.
I tell people to set their input volume so that loudest playing/singing just doesn't set the first red led on the fancy skin.
That may be a little conservative, but I hate distortion.
Note that the "normal" skins do not change colors except for clipping so it may be more difficult to describe the best volume indication.

[gene96817]

I don't usually follow audio processing closely. There is a lossless audio compression algorithm. Would that be interesting?

[insolace]

It takes a controlled studio environment and an experienced engineer at the controls to create the “wire with gain” signal chain you describe, and a performer who has good monitoring and years of experience working with a mic.

These are great ideals to strive for but in practice, input gain is not a “set it and forget it” setting. Every jam that I am in, people are constantly asking other people to adjust their gain, because they aren’t in a controlled environment, they are most often sitting at a desk in a bedroom or study. When they perform things move around, and if they aren’t experienced they will blow out their mic in the chorus and be barely audible in the verses.

This is doubly exacerbated when a musician plays an instrument and sings, and jamulus downmixes their two signals to a single fader. With no filtering or even simple limiting, the result is a jam session where levels drift and people are constantly fumbling with faders and input knobs when they should be performing.

If you are interested I would invite you to join my next rehearsal on Monday April 5th, 7pm PST. DM me and I can provide my server IP.

[chrisrimple]

Along with the other asks, could we get a Limiter? It would add a small amount of latency (~5ms) but would prevent clients from blasting out everyone else, and likely help vocalists that don't have an in-line Limiter prior to Jamulus.

[insolace]

A limiter shouldn’t have to add any considerable latency

[atsampson]

You could reuse the Fast Lookahead Limiter code from swh-plugins relatively straightforwardly (or just use it as a LADSPA plugin). The problem is that someone "blasting out everyone else" is probably clipping their input, in which case a limiter in software isn't going to help much.

[insolace]

Wether they are overloading the input or not, the compressor/limiter helps. Performers get excited and play louder during intense sections. Ideally you’ve set the gain so that they don’t distort when this happens, but even so their level needs to be brought down, and this is why compressors and limiters exist.

[reneknuvers]

I agree that jamulus in itself should be kept simple see that it is not easy to ‘draw the line’ somewhere. The problem with an interface to any kind of plugin system that I foresee is that it is hard to use for most of the unexperienced users. Exactly those users need the basic ‘limit my bandwidth/HPF” and “limit my dynamic range/compressor” kind of functions. For the others a contraption that routes the audio in and oud of a DAW already does the trick and a plugin interface will add little function compared to the amount of work to be invested. About KISS: if this principle is kept high, then please re-evaluate the reverb-function in the client. Also consider the pan slider on the input (ref #723, #1290) That single slider is far but adhering to ‘kiss’. From a users perspective a simple implementation would be a high pass filter on 100Hz, enabled automatically when voice, mic, violin, flute, etc. instruments are selected. Manual activation/deactivation should be possible. For the compressor: a rudimentary, not even selectable ‘cut 12dB on consistent clip” would work, together with a persistent warning notification on the client. It would work for expert, novice and agnostic users alike. It would save users ears from loud signals caused by wacko’s, agnostic gain settings, misconfiguration and feedback. Note that the feedback argument is very likely to become a problem when Android and iOS versions are starting to be used: inherently a device will cause feedback when no external audio interface is found and the speaker and microphone are used.

…

Op 1 apr. 2021, om 11:09 heeft Christian Hoffmann ***@***.***> het volgende geschreven: Nobody stops you from adding it yourself and opening a Pull Request ;-). However there's no guarantee that it gets merged. I agree, but maybe it makes sense to check here if there is willingness to accept such a feature from @jamulussoftware/maindevelopers <https://github.com/orgs/jamulussoftware/teams/maindevelopers> to avoid work in a PR without a chance of being accepted. My personal stance: I think we should aim to make it possible and easy to do add such filters, but I'm not convinced that we should extend the built-in integrated pre-processors in either clients or servers. Therefore, I'd be open to PRs which add interfaces to VST (there was some work already, I think?), LV2, LADSPA or similar (ideally there'd be one generic way...?), but not open for "Add an EQ", "Add a limiter" and so forth as I fear it would be hard where to draw the line. In other words, keep Jamulus simple, but still make it possible to work with other, more targeted components such as filters. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1294 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4LARZWURA5ATB72ANLFXLTGQZ3HANCNFSM42CJZ2JQ>.