New Zynthian lv2-plugin: AutoLeveler

[wyleu]

@hannesmenzel

I’m open for any suggestions.

Could you add documentation to the Developers FAQ..?

It’s sort of here . . .

Contributing to Zynthian Development - ZynthianWiki

And I suspect the answer to the first question is ask Jofe….

And may I suggest you add the above image to the first post of this thread ?

@tunagenes

@hannesmenzel

Maybe we should rename the plugin to AngryMixingEngeneer.lv2

By the way, I’m open for suggestions.

How about EarSaver.lv2?

Both are better than AutoLeveller.

AngryMixingEngeneer, obviously list alphabetically better than AutoLeveller and Far ahaed of EarSaver . . . .

taxi companies know this.

[hannesmenzel]

@wyleu

And may I suggest you add the above image to the first post of this thread ?

Certainly I can post a screenshot of the headless plugin.

@wyleu

Could you add documentation to the Developers FAQ..?

You mean more generally how to get a plugin compiled on zynthian or specifically how to do this one? Because regarding the first question I would kind of stumble through the process how I copied @riban’s makefiles and the DPF example code.

@wyleu

AngryMixingEngeneer, obviously list alphabetically better than AutoLeveller and Far ahaed of EarSaver

So AaronTheAngryMixingEngineer.lv2 it will be.

[wyleu]

@hannesmenzel

So AaronTheAngryMixingEngineer.lv2 it will be.

That should test the list display. . . . .

@hannesmenzel

You mean more generally how to get a plugin compiled on zynthian or specifically how to do this one? Because regarding the first question I would kind of stumble through the process how I copied @riban’s makefiles and the DPF example code.

Anything really. Ultimately we are trying to formalise a documentation style for these components. Just getting into the wiki and scratching something into the docs is of great benefit. It is, of course, another mark up language to mash in with all the others you’ve met along the way, but it will help people coming along behind.

My notch filter hasn’t moved along, but if we can start to structure the points below an LV2 object then structure will ( hopefully) emerge.

Parameter function definition seems an obvious one.

The more proscribed the outer stages of this process can become the more time people will get to concentrate on the juicy stuff in the middle.

[hannesmenzel]

@wyleu

Anything really. Ultimately we are trying to formalise a documentation style for these components

I’ll try something soon. Better I try to understand the inner logic of makefiles prior to that (took me most of the time to adapt that as well).

@wyleu

That should test the list display. . . . .

That’s a quite accurate representation of thw plugin.

[hannesmenzel]

@wyleu

The more proscribed the outer stages of this process can become the more time people will get to concentrate on the juicy stuff in the middle.

Don’t know how this saying goes at your island. “In for a makefile, in for a run()”?

[riban]

Makefile is a demon that requires sacrifices to do anything. I am surprised it had lasted so long. I use it when I have to or when it is simple but there are easier to use build systems, like cmake.

[oscaracena]

Oddly enough, I think cmake is much harder than Makefile It must be that my Makefiles are very simple, but I create then very often.

[wyleu]

make or cmake . . . .
How it will be decided.

German man fights French man with blunderbuss in a balloon

[hannesmenzel]

Hey @jofemodo ,

Say, is the below path under /zynthian/… the default path for the prebuild installed plugin? Seems I now got a duplicate, the other one being my self built plugin:

Regenerating engines DB: engines ...
lilv_world_add_plugin(): warning: Duplicate plugin <https://github.com/johannesmenzel/SRPlugins/lv2-components/AutoLeveler>
lilv_world_add_plugin(): warning: ... found in file:///usr/lib/lv2/AutoLeveler.lv2/
lilv_world_add_plugin(): warning: ... and      file:///zynthian/zynthian-plugins/lv2/AutoLeveler.lv2/ (ignored)

When we’re already talking that issue, what are zynthians (jalvs) lv2 search paths?

[HansR]

Hi @hannesmenzel,

Your AutoLeveler appears very usefull after all

I would like a small improvement.

At the moment, when a sound is far too loud (snapshot did not save all settings) the first time it is not levelled so it reaches the speaker unfiltered.

Would it be possible to add a look-ahead of a few milliseconds (preferably adjustable) so even the first peak is levelled before it sounds?

I know this adds some latency, but I’m happy to pay that price.

Kind regards,

Hans.

[hannesmenzel]

Hi @HansR, thanks a lot for the feedback, and it is cool, that someone really considered to use it.

I see the problem. Personally I’d chose the lookahead solution as the last resort for several reasons.

1. I just started out with lv2 and don’t speak it fluently, a lookahead would require some adjustable audio buffers and the knowledge when, how and how often the plugin reports latency to the host in lv2/DPF.
2. Introducing latency in a musical instrument is critical.
3. The lookahead time must be longer than the smoothing time of the gain unit. Short latency and aprupt gain changes or vice versa.
4. There are some alternatives.

The alternatives in question:

1. First, the gain smoothing time is around 200 ms, which is quite long enough to be entitled to write “smooth leveling” to the description, but also equaling the duration of the spike you’re hearing. Maybe it should be shorter. Otherwise, the long smoothing time has the opposite effect in many cases: when applied gain is reset after parameter changes, the detector is already listening on the input while smoothly upleveling.
2. Good point with the non saving states. It should save the parameter values (does it?), but not the gain value. I didn’t think about that, because it’s actually a functional “runtime variable”. But it should be stored, and maybe it should also be a parameter.
3. The detection could at least “lookahead” within the current buffer, introducing no latency.
4. A security limiter could be an option as well.

[HansR]

@hannesmenzel

I just started out with lv2 and don’t speak it fluently, a lookahead would require some adjustable audio buffers and the knowledge when, how and how often the plugin reports latency to the host in lv2/DPF.

Fair enough. I have no idea if the things I ask are feasible. So far what you have done is pretty good.

@hannesmenzel

Introducing latency in a musical instrument is critical.

Of course latency adds up, so it is logical the Zynthian basic latency is kept as low as possible. For this solution that does not apply (I believe it is agreed that AutoLeveler is not to be used in a live performance). For my case, everything below 20ms is acceptable.

Perhaps I’m asking too much, the current version works pretty well. As they say “The better is the enemy of the good”.

Kind regards,

Hans.

[hannesmenzel]

Your point is really valid. One of the problems is obviously the input gain, but I like to keep the upleveling function.

From my personal point of view 10 ms of latency are acceptable for live use, including the standard buffer size. I’ll have a look into the saving states solution and probably lowering the smoothing time.