ladspa++

[JohannesLorenz]

I have been developing this the last weeks, and it is almost finished. It is a C++ wrapper for LADSPA which will make

• your LADPSA code much shorter
• your LADPSA code much safer
• your plugin even easier to optimize

For an example: I have appended links to an old style amplifier [1] and a ladspa++ version of the same plugin [2]. You'll see that the new code is 6 times shorter.

But this is not all. LADSPA misses some things imo:

• descriptions for the buttons (which would show up as tooltips). For example, open the LADPSA Calf filter and look at the Mode wheel. It lets you chose a filter type, but only by selecting numbers... :)
• graphical widgets (e.g. you might want to show the curve of an EQ in lmms)

How to implement this without changing anything about ladspa?

• descriptions could easily go into the implementationData field that LADSPA descriptors offer
• widgets are just in- and output of numbers, like audio ports. E.g: If you want to display a plot from your plugin, you make an out-port (like an audio-out-port). You flag it specially and the UI will read this data right into its widget. Of course, this is not trivial: audio port buffers offer a sample size. We'd need to send the UI widgets' data in packets (with each of sample size). But for a spectrum analyzer with only 10 bulks, this would suffice imo.

What do you think? Should we do the extensions?

[1] http://pastebin.com/RKmbS3xB (old style LADSPA plugin) [2] https://github.com/JohannesLorenz/ladspa--/blob/master/test_effect.cpp (new ladspa++ plugin)

[diizy]

On 04/05/2014 09:35 PM, JohannesLorenz wrote:

There has been a long discussion and most people disagreed. However, if I'll still write ladspa++ and develop some useful effects with it, would you disagree to take it over?

ladspa++.h is right now a one-header-project. It is a C++ wrapper for ladspa, so right now, you could just call it a common header for multiple ladspa effects. Later, however, I plan to be able to have a ladspa++ backend (in lmms, like the ladspa backend) while still being ladspa compatible. The new backend would allow extensions like:

• a general effect description with a few sentences
• tooltips for UI elements
• functions graphs, e.g. to draw a filter curve
• a simple markup language (for links)
• presets (like in ZASF, very useful imo)
• ...
• even instruments, though this is the only point where we "might" break compatibility to ladspa

I know it sounds to you like a waste of time, but if it's so much fun for me, how can this time be wasted? ;)

Doesn't DSSI basically already do all of this which you wish to achieve with LADSPA++... and more? Why not just work towards getting DSSI support for LMMS? DSSI basically is that improved version of LADSPA, that overcomes all the shortcomings of LADSPA...

Writing a host for DSSI for LMMS might actually get DSSI some more usage, as LMMS is a pretty major platform, and DSSI - although a bit unpopular at the moment - is still an already established format with plugins already written for it (Hexter, Zyn, DSSI-VST..). DSSI can also be used to wrap GUIs over LADSPA plugins.

Take a look at the spec here, is there anything DSSI lacks that LADSPA++ would provide? http://dssi.sourceforge.net/

Apart from that... Problem with your LADSPA++ is, it's not as simple as "this is fun to write". Yes, this may be fun for you to write... but if we merge it in LMMS, then we also take in the responsibility to maintain it. This may be a fun project for you now, but what if you get bored of it in the future? Or some other RL circumstance comes up (sickness in family, new job, changing life situations etc. ) and you're unable to keep maintaining it? Then we're left with basically a one-man project embedded in LMMS, with the one man who understands and knows it, gone. And even worse, we may have some of our provided plugins depending on it, people's projects depending on those plugins...

I'm not trying to rain on your parade, but it's just that if no one else supports this LADSPA++ protocol, then I really think there are better things you could be using your time for.

I've said it before, but IMHO, the only way this LADSPA++ thing makes sense is if you could gather support from other audio softwares, like eg. Qtractor, Ardour, MUSE, and maybe collaboration on the specification... If other softwares agree to support the format, if other people agree to upgrade their old LADSPA plugins to LADSPA++, then it would at least guarantee that it wouldn't be just a one-man show. But implementing it just for our use just doesn't make sense, because we already have a much better native plugin format for that.

[JohannesLorenz]

Doesn't DSSI basically already do all of this which you wish to achieve with LADSPA++... and more? Why not just work towards getting DSSI support for LMMS? DSSI basically is that improved version of LADSPA, that overcomes all the shortcomings of LADSPA...

Enough of a reason: DSSI is written in C.

Despite from that, what do I need MIDI or OSC for if I just want to write a small effect? My ladspa++ amplifier has ~ 50 lines now. It's so simple.

[diizy]

On 04/06/2014 12:54 AM, JohannesLorenz wrote:

Doesn't DSSI basically already do all of this which you wish to achieve with LADSPA++... and more? Why not just work towards getting DSSI support for LMMS? DSSI basically is that improved version of LADSPA, that overcomes all the shortcomings of LADSPA...

Enough of a reason: DSSI is written in C.

So is LADSPA. Nothing says that you can't write DSSI plugins in C++, or even write a C++ wrapper for DSSI, the same way you're now planning on doing for LADSPA. No matter if you deal with straight LADSPA or DSSI, you'll still have to deal with C code on some level.

Plus it's an already established plugin format, so there's plenty of references to look at for how to do things, and this also means we get the benefits of some already existing plugins that aren't currently available for LMMS.

Despite from that, what do I need MIDI or OSC for if I just want to write a small effect? My ladspa++ amplifier has ~ 50 lines now. It's so simple.

Counter-question: what do you need LADSPA++ for if you just want to write a small effect? If you just want a small effect, plain LADSPA is more than sufficient.

If you need something more sophisticated than LADSPA, you can write native LMMS plugins.

My native LMMS amplifier's DSP portion is around 40-50 lines (could be less if there weren't panning and such there). The rest is basically just boilerplate code that can be pretty much c/p'd from other plugins, plus the UI specification. And the UI part should soon be able to be done with GUI tools.

[JohannesLorenz]

Everyone has his/her arguments, and there are enough reasons to justify either option. I could provide you 100 pro arguments and you could reply with 200 contra arguments.

I do not mean it bad, but this discussion leeds to nothing (else than flame war).

[diizy]

On 04/06/2014 01:32 AM, JohannesLorenz wrote:

Everyone has his/her arguments, and there are enough reasons to justify either option. I could provide you 100 pro arguments and you could reply with 200 contra arguments.

I do not mean it bad, but this discussion leeds to nothing (else than flame war).

Why not try writing a native LMMS plugin? I think you'd be pleasantly surprised how intuitive the framework is. It's no more complex than LADSPA, despite being far more powerful...

[eagles051387]

I think the point that Vesa is making with ldasp++ you are kind of reinventing the wheel so to speak. Something already exists.

I think a very valid question here is this. Dose DSSI that was discussed previously already do what you are planning with ldasp++ or does it do that plus more.

On Sun, Apr 6, 2014 at 12:40 AM, Vesa V notifications@github.com wrote:

On 04/06/2014 01:32 AM, JohannesLorenz wrote:

Everyone has his/her arguments, and there are enough reasons to justify either option. I could provide you 100 pro arguments and you could reply with 200 contra arguments.

I do not mean it bad, but this discussion leeds to nothing (else than flame war).

Why not try writing a native LMMS plugin? I think you'd be pleasantly surprised how intuitive the framework is. It's no more complex than LADSPA, despite being far more powerful...

Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/282#issuecomment-39653117 .

Jonathan Aquilina

[tobydox]

I fully support Vesa here. I won't stop anybody to develop something but I'm sure, we'll not include it as long as it's not a widely supported standard with many available plugins which would make it worth to support it. Otherwise it's just another kind of LMMS-specific plugin standard which is something, we absolutely don't need. The current plugin infrastructure is fine and allows providing LMMS' functionality to plugins (like (sample-exact) controllers, automation etc.) without any additional effort - look at LadspaControl & co to see what kind of inconvenient wrappers need to be built around every LADSPA(++) control in order to support it - completely unneccessary overhead (RAM, CPU, code complexity) if one could have all that native instead.

If you have fun, go ahead but please don't expect any support from our side. I think your work on Qt-ZASF is a lot more appreciated by everybody out there! ;-)

[diizy]

On 04/06/2014 10:41 PM, Tobias Doerffel wrote:

If you have fun, go ahead but please don't expect any support from our side. I think your work on Qt-ZASF is a lot more appreciated by everybody out there! ;-)

I second this. I didn't even know about it, but Qt-ZASF sounds like a great idea and would be very useful for LMMS - one less dependency for us, plus better integration (and themeability!) of Zyn... that'd be great.