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)

[eagles051387]

Nice work :) I dont know though if it should wait until after 1.0.0 release and be released with the 1.0.1 release. But this is toby's ultimate decision

On Sunday, February 09, 2014 12:21:46 AM JohannesLorenz wrote:

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)

---

Reply to this email directly or view it on GitHub: https://github.com/LMMS/lmms/issues/282

[diizy]

I'm not really sure what we'd be trying to accomplish with this.

Is the purpose to make this an actual standard that other projects would follow as well?

Most of the rest of Linux Audio apart from LMMS and Audacity seem to have mostly moved beyond LADSPA, for better or worse, and anyone wanting to do effects with graphical GUIs is probably going to use LV2 or LinuxVST.

So I'm not sure how easy it would be to gather support for this standard from other Linux Audio projects or LADSPA plugin developers.

If we're only looking to do this for the benefit of LMMS, then it raises the question... why not just use the LMMS native plugin framework? It allows whatever graphical widgets you want, can be extended in any way you like, and is capable of anything LADSPA is.

I'm not saying it's a bad idea necessarily, but it needs some clarification, as to what exactly are we trying to do here?

[JohannesLorenz]

I'm not saying it's a bad idea necessarily, but it needs some clarification, as to what exactly are we trying to do here?

I don't think this should be restricted to lmms. My idea was to make this completely independent of any GUI.

What would be an advantage that a plugin knows that it is connected to lmms? What could it do with an "LMMS handle" (access to LMMS' data or types)? As for the widgets, I think we could restrict to just having a small collection defined in ladspa. (Right now, I can only think of 2D plots for output widgets).

[diizy]

On 02/09/2014 11:07 AM, JohannesLorenz wrote:

I'm not saying it's a bad idea necessarily, but it needs some clarification, as to what exactly are we trying to do here?

I don't think this should be restricted to lmms. My idea was to make this completely independent of any GUI.

What would be an advantage that a plugin knows that it is connected to lmms? What could it do with an "LMMS handle" (access to LMMS' data or types)?

Completely independent of a GUI, in what way? We define a set of widgets and let the host figure out how to implement those? That's not a bad idea per se, but for any standard to be useful, there would need to be support from the rest of the Linux Audio community. And, well, seeing as most other software has moved beyond LADSPA, and LADSPA would still be limited to effect plugins only... that might prove a hard thing to accomplish.

So I really don't see this as likely to catch on in the community. Of course, I'd be glad to be proven wrong - if you could gather support from other audio software projects (Qtractor, Ardour, etc.) and plugin makers, then I could definitely see the viability of this thing.

Otherwise, it'd just be another plugin format supported by LMMS only, just like LMMS native plugins, except with less capabilities...

[Sti2nd]

I vote for LV2.

[tobydox]

I also think we should not waste time by trying to improve deprecated technologies, even though the intention is good. It would be optimal to invest that time into implementing proper LV2 support (some basics are done in the old-master branch but it was nothing usable). If support for Linux VST plugins works with our reverse engineered header, it would be an option as well (I'd not go for VST support which would depend on the proprietary VST SDK).

The best of course is to develop native LMMS plugins ;-) This allows to make use of all components and models/views in LMMS so the plugin integrates well into LMMS. A generic plugin framework which just provides information about the controls will always result in a poor UI - the current LADSPA plugins are just a bunch of knobs and LEDs which isn't very user friendly and looks ugly compared to what is possible with native or VST plugins.

[diizy]

On 02/09/2014 07:21 PM, Tobias Doerffel wrote:

I also think we should not waste time by trying to improve deprecated technologies, even though the intention is good. It would be optimal to invest that time into implementing proper LV2 support (some basics are done in the old-master branch but it was nothing usable). If support for Linux VST plugins works with our reverse engineered header, it would be an option as well (I'd not go for VST support which would depend on the proprietary VST SDK).

The best of course is to develop native LMMS plugins ;-) This allows to make use of all components and models/views in LMMS so the plugin integrates well into LMMS. A generic plugin framework which just provides information about the controls will always result in a poor UI - the current LADSPA plugins are just a bunch of knobs and LEDs which isn't very user friendly and looks ugly compared to what is possible with native or VST plugins.

— Reply to this email directly or view it on GitHub https://github.com/LMMS/lmms/issues/282#issuecomment-34579576.

For LinuxVST, maybe we should take a look at how Qtractor implements support for them? I'm pretty sure they don't use anything proprietary, in fact from a quick look at their source tree they seem to use some of the same code we use (Vestige)? If so that'd be great, that'd probably make it easier for us to implement LinuxVST support.

I think LinuxVST support would be a great idea, as we already support VST and that'd obviously be less work than full LV2 support, and many plugin makers apparently find VST easier to work with than LV2, there are some very good quality LinuxVST's available...

[eagles051387]

It would be great to get rid of any external plugins such as vst's. It woudl be amazing to have a native plugin and instrument framework. The easier to work with the framework the more instruments we can have in my honest opinion.

On Sunday, February 09, 2014 09:21:45 AM Tobias Doerffel wrote:

I also think we should not waste time by trying to improve deprecated technologies, even though the intention is good. It would be optimal to invest that time into implementing proper LV2 support (some basics are done in the old-master branch but it was nothing usable). If support for Linux VST plugins works with our reverse engineered header, it would be an option as well (I'd not go for VST support which would depend on the proprietary VST SDK).

The best of course is to develop native LMMS plugins ;-) This allows to make use of all components and models/views in LMMS so the plugin integrates well into LMMS. A generic plugin framework which just provides information about the controls will always result in a poor UI - the current LADSPA plugins are just a bunch of knobs and LEDs which isn't very user friendly and looks ugly compared to what is possible with native or VST plugins.

---

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

[diizy]

On 02/09/2014 07:31 PM, eagles051387 wrote:

It would be great to get rid of any external plugins such as vst's. It woudl be amazing to have a native plugin and instrument framework. The easier to work with the framework the more instruments we can have in my honest opinion.

Why would we need to get rid of VST's or other external plugins?

[eagles051387]

That came out wrong. Maybe windows based VST support should go. It seems like it cause lots of problems in terms of wine and windows support.

On Sunday, February 09, 2014 09:34:32 AM Vesa V wrote:

On 02/09/2014 07:31 PM, eagles051387 wrote:

It would be great to get rid of any external plugins such as vst's. It woudl be amazing to have a native plugin and instrument framework. The easier to work with the framework the more instruments we can have in my honest opinion.

Why would we need to get rid of VST's or other external plugins?

---

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

[diizy]

On 02/09/2014 07:39 PM, eagles051387 wrote:

That came out wrong. Maybe windows based VST support should go. It seems like it cause lots of problems in terms of wine and windows support.

One bug report is "lots of problems"?

Why remove functionality? It's an optional feature anyway, that can be disabled at compile time. People who run Linux are well aware that running windows software on Linux is a crapshoot at best. Some things work great, others crash your computer.

We shouldn't remove anything we already have working, especially something that many people depend on for their work. LMMS is one of the few audio softwares on Linux where you can run windows VST's somewhat reliably.

[tobydox]

I don't think we will ever discuss the removal of VST support as it got quite mature and advanced over the years. It's not our fault if the interaction between WINE/Qt gets broken due to an improper XEMBED implementation inside Qt and a change in the developer version (!) of WINE. There never has been a problem if you're using stable versions of WINE.

[eagles051387]

The current issue of vst's bug 573 on sourceforge I think we need to bump the dependency of wine to x.x.12 as it seems to fix the issues displayed by the bug.

Their ppa though doesnt have a package available, but the person compiled wine and it solved the problem he was experiencing.

On Sunday, February 09, 2014 09:45:33 AM Vesa V wrote:

On 02/09/2014 07:39 PM, eagles051387 wrote:

That came out wrong. Maybe windows based VST support should go. It seems like it cause lots of problems in terms of wine and windows support.

One bug report is "lots of problems"?

Why remove functionality? It's an optional feature anyway, that can be disabled at compile time. People who run Linux are well aware that running windows software on Linux is a crapshoot at best. Some things work great, others crash your computer.

We shouldn't remove anything we already have working, especially something that many people depend on for their work. LMMS is one of the few audio softwares on Linux where you can run windows VST's somewhat reliably.

---

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

[tobydox]

The problem will be gone soon automatically so IMHO we should not make too much noise about it. Also it'd be a bad idea to depend on version >= 1.7.2 as there's no reason to exclude stable and well-proven versions like 1.4.x and 1.6.x. Again: if people are using a development version of WINE, they have to do it on their own risk.

[diizy]

Here's Qtractor's VST code for comparison

https://sourceforge.net/p/qtractor/code/HEAD/tree/trunk/src/qtractorVstPlugin.cpp https://sourceforge.net/p/qtractor/code/HEAD/tree/trunk/src/qtractorVstPlugin.h

They also have this file, which seems to contain code lifted straight from LMMS:

https://sourceforge.net/p/qtractor/code/HEAD/tree/trunk/src/vestige/aeffectx.h

So maybe this means we could look at these files to figure out how to implement LinuxVST support on LMMS?

[JohannesLorenz]

It would be optimal to invest that time into implementing proper LV2 support

I've bee looking at LV2, but it does not really convince me:

• The most easy example - the Amplifier [1] - needs 5 files.
• 4 of them are not C syntax, but hard to read python or TTL. (hard to read for a C programmer)
• The URI design looks too complicated imo.
• Almost all plugins (also recent ones) that I know where written in LADSPA (v1).
• It is not (directly) compatible to LADSPA, nor is LADPSA to it. So you can not easily port a LADSPA plugin to LV2.
• Implementing LV2 is way more complicated than implementing LADSPA [2].

Are you guys really sure that LV2 is designed well? Have you really looked into it, or is this just an assumption?

[1] Amplifier example: http://lv2plug.in/repo/trunk/plugins/eg01-amp.lv2/ [2] "Implementing LV2": http://lv2plug.in/wiki/ImplementingLV2

[eagles051387]

Johannes you could actually work on porting it to c/c++ if you are versed with that and submit said work upstream. that way developers can then have a choice as to the language to use when it comes to implementing LV2

On Wed, Feb 12, 2014 at 1:48 PM, JohannesLorenz notifications@github.comwrote:

It would be optimal to invest that time into implementing proper LV2 support

I've bee looking at LV2, but it does not really convince me:

• The most easy example - the Amplifier [1] - needs 5 files.
• 4 of them are not C syntax, but hard to read python or TTL. (hard to read for a C programmer)
• The URI design looks too complicated imo.
• Almost all plugins (also recent ones) that I know where written in LADSPA (v1).
• It is not (directly) compatible to LADSPA, nor is LADPSA to it. So you can not easily port a LADSPA plugin to LV2.
• Implementing LV2 is way more complicated than implementing LADSPA [2].

Are you guys really sure that LV2 is designed well? Have you really looked into it, or is this just an assumption?

[1] Amplifier example: http://lv2plug.in/repo/trunk/plugins/eg01-amp.lv2/ [2] "Implementing LV2": http://lv2plug.in/wiki/ImplementingLV2

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

Jonathan Aquilina

[pgiblock]

I personally feel this is all a waste of time at this point. LV2 plugins need a real-time safe host anyway, which is half the reason I sparked the Unison effort forever ago.

I hate to see people spinning their wheels on things like this.

eagles051387 notifications@github.com wrote:

Johannes you could actually work on porting it to c/c++ if you are versed with that and submit said work upstream. that way developers can then have a choice as to the language to use when it comes to implementing LV2

On Wed, Feb 12, 2014 at 1:48 PM, JohannesLorenz notifications@github.comwrote:

It would be optimal to invest that time into implementing proper LV2 support

I've bee looking at LV2, but it does not really convince me:

• The most easy example - the Amplifier [1] - needs 5 files.
• 4 of them are not C syntax, but hard to read python or TTL. (hard to read for a C programmer)
• The URI design looks too complicated imo.
• Almost all plugins (also recent ones) that I know where written in LADSPA (v1).
• It is not (directly) compatible to LADSPA, nor is LADPSA to it. So you can not easily port a LADSPA plugin to LV2.
• Implementing LV2 is way more complicated than implementing LADSPA [2].

Are you guys really sure that LV2 is designed well? Have you really looked into it, or is this just an assumption?

[1] Amplifier example: http://lv2plug.in/repo/trunk/plugins/eg01-amp.lv2/ [2] "Implementing LV2": http://lv2plug.in/wiki/ImplementingLV2

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

Jonathan Aquilina

— Reply to this email directly or view it on GitHub.

[eagles051387]

In that case coudl this spur off the integration efforts of unison?

On Wed, Feb 12, 2014 at 3:00 PM, Paul Giblock notifications@github.comwrote:

I personally feel this is all a waste of time at this point. LV2 plugins need a real-time safe host anyway, which is half the reason I sparked the Unison effort forever ago.

I hate to see people spinning their wheels on things like this.

eagles051387 notifications@github.com wrote:

Johannes you could actually work on porting it to c/c++ if you are versed with that and submit said work upstream. that way developers can then have a choice as to the language to use when it comes to implementing LV2

On Wed, Feb 12, 2014 at 1:48 PM, JohannesLorenz <notifications@github.com wrote:

It would be optimal to invest that time into implementing proper LV2 support

I've bee looking at LV2, but it does not really convince me:

• The most easy example - the Amplifier [1] - needs 5 files.
• 4 of them are not C syntax, but hard to read python or TTL. (hard to read for a C programmer)
• The URI design looks too complicated imo.
• Almost all plugins (also recent ones) that I know where written in LADSPA (v1).
• It is not (directly) compatible to LADSPA, nor is LADPSA to it. So you can not easily port a LADSPA plugin to LV2.
• Implementing LV2 is way more complicated than implementing LADSPA [2].

Are you guys really sure that LV2 is designed well? Have you really looked into it, or is this just an assumption?

[1] Amplifier example: http://lv2plug.in/repo/trunk/plugins/eg01-amp.lv2/ [2] "Implementing LV2": http://lv2plug.in/wiki/ImplementingLV2

Reply to this email directly or view it on GitHub< https://github.com/LMMS/lmms/issues/282#issuecomment-34865372> .

Jonathan Aquilina

— Reply to this email directly or view it on GitHub.

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

Jonathan Aquilina

[diizy]

On 02/12/2014 02:48 PM, JohannesLorenz wrote:

It would be optimal to invest that time into implementing proper LV2 support

I've bee looking at LV2, but it does not really convince me:

There's always LinuxVST, which would be easy to implement support for too, seeing as we already have the VST glue code.

[eagles051387]

Unison has to get done at some point though

On Wed, Feb 12, 2014 at 3:25 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 02:48 PM, JohannesLorenz wrote:

It would be optimal to invest that time into implementing proper LV2 support

I've bee looking at LV2, but it does not really convince me:

There's always LinuxVST, which would be easy to implement support for too, seeing as we already have the VST glue code.

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

Jonathan Aquilina

[diizy]

On 02/12/2014 05:18 PM, eagles051387 wrote:

Unison has to get done at some point though

Well yes but is anyone working on it yet?

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

Meanwhile, LinuxVST support would be easier to implement, and would benefit us with some extra plugins.

[eagles051387]

From what Paul and I spoke about alot of rewriting. Integration of unison would take care of making it RT-safe. I think it would be nice to see if people could help him start getting it integrated into LMMS

On Wed, Feb 12, 2014 at 5:18 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 05:18 PM, eagles051387 wrote:

Unison has to get done at some point though

Well yes but is anyone working on it yet?

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

Meanwhile, LinuxVST support would be easier to implement, and would benefit us with some extra plugins.

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

Jonathan Aquilina

[pgiblock]

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

Meanwhile, LinuxVST support would be easier to implement, and would benefit us with some extra plugins.

Yeah, I don't think Ladspa++ would offer much at this point.

-- Paul

---

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

[eagles051387]

To help with this could you submit bugs to the tracker that people can pick and work on to help you out and if they dont then you can do them.

On Wed, Feb 12, 2014 at 5:29 PM, Paul Giblock notifications@github.comwrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

Meanwhile, LinuxVST support would be easier to implement, and would benefit us with some extra plugins.

Yeah, I don't think Ladspa++ would offer much at this point.

-- Paul

---

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

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

Jonathan Aquilina

[pgiblock]

On 2/12/14, 11:18 AM, Vesa V wrote:

On 02/12/2014 05:18 PM, eagles051387 wrote:

Unison has to get done at some point though

Well yes but is anyone working on it yet?

I realize that Unison had stalled out. I'm working on revamping it. As part of this, I would like to derive some milestones, estimate the effort, and present this to all the active LMMS developers. We can then see if people are interested in this effort (More like "Codename LMMS2".) It hurts me to see people struggling over things that I wish I could have actually fixed years ago; instead of working-around things today.

[diizy]

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

[eagles051387]

Paul Wouldnt it be best to integrate and fix as things progress?

On Wed, Feb 12, 2014 at 5:32 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

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

Jonathan Aquilina

[pgiblock]

What do you mean? I'm not sure we are using the same definition of "integration".

-- Paul

On 2/12/14, 11:34 AM, eagles051387 wrote:

Paul Wouldnt it be best to integrate and fix as things progress?

On Wed, Feb 12, 2014 at 5:32 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

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

[eagles051387]

Lets say Vesa mentioned the Fx mixer. Since that has been changed why not integrate that in with unison and then slowly start with other new fixes and then older ones which havent been changed etc.

On Wed, Feb 12, 2014 at 5:36 PM, Paul Giblock notifications@github.comwrote:

What do you mean? I'm not sure we are using the same definition of "integration".

-- Paul

On 2/12/14, 11:34 AM, eagles051387 wrote:

Paul Wouldnt it be best to integrate and fix as things progress?

On Wed, Feb 12, 2014 at 5:32 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

Reply to this email directly or view it on GitHub< https://github.com/LMMS/lmms/issues/282#issuecomment-34886624> .

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

Jonathan Aquilina

[pgiblock]

New FX Mixer? I could care less about that. The FX Mixer will be so much simpler in the Unison code since all the routing, mixing, etc is already handled by the engine. The mixer code would just have "wire" the strips together, the engine does the rest.

Or, are you referring to the Mixer graphical overhaul? Sure, I'd be happy to reuse elements from that.

Regarding instruments and stuff -- no, they are not immediately compatible. However, the way instruments work in LMMS (dynamically allocating Notes, wiring DSP procedures together with signals and slots, locking on the Song object) is one of the main things limiting us from being realtime.

-- Paul

On 2/12/14, 11:32 AM, Vesa V wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

---

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

[eagles051387]

Is that something that can be sorted as first thing and top priority at this point before everything else?

On Wed, Feb 12, 2014 at 5:40 PM, Paul Giblock notifications@github.comwrote:

New FX Mixer? I could care less about that. The FX Mixer will be so much simpler in the Unison code since all the routing, mixing, etc is already handled by the engine. The mixer code would just have "wire" the strips together, the engine does the rest.

Or, are you referring to the Mixer graphical overhaul? Sure, I'd be happy to reuse elements from that.

Regarding instruments and stuff -- no, they are not immediately compatible. However, the way instruments work in LMMS (dynamically allocating Notes, wiring DSP procedures together with signals and slots, locking on the Song object) is one of the main things limiting us from being realtime.

-- Paul

On 2/12/14, 11:32 AM, Vesa V wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

---

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

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

Jonathan Aquilina

[diizy]

On 02/12/2014 06:40 PM, Paul Giblock wrote:

New FX Mixer? I could care less about that. The FX Mixer will be so much simpler in the Unison code since all the routing, mixing, etc is already handled by the engine. The mixer code would just have "wire" the strips together, the engine does the rest.

Or, are you referring to the Mixer graphical overhaul? Sure, I'd be happy to reuse elements from that.

Regarding instruments and stuff -- no, they are not immediately compatible. However, the way instruments work in LMMS (dynamically allocating Notes, wiring DSP procedures together with signals and slots, locking on the Song object) is one of the main things limiting us from being realtime.

So this means that all the instruments and native effect plugins would all have to be rewritten almost from scratch?

Would we still retain all the functionality LMMS offers right now in native plugins, eg. per-note envelopes, filters and pitch control?

I admit I have a bit of self-interest in mind here, as I've just written a plugin for LMMS, and plan on possibly writing more of them...

[pgiblock]

Right, and I want to know: What do you think integrating the mixer into Unison means? This doesn't really make much sense to me. Are you talking about integrating the model or the view? The model doesn't make much since since Unison's internals are vastly different.

Integrating the GUI makes sense, but only to a limited degree. My view for the Mixer in Unison is something more like what is in FL-Studio or Logic. Each Instrument gets their own strip, you can add buses, and you can wire the inserts as you please. So, sure, I could use LMMS's code to draw the faders, knobs and stuff. But, to say "Just integrate LMMS's mixer", is a bit far-fetched.

Maybe I'm an outlier here, but my goal isn't to pull in all the problems that LMMS (and other DAWs) have, but to make something that is better. Something fresh. Something that is built off of our experiences with LMMS over the last 10 years. This doesn't mean to pull in a bunch of work-arounds, but to design something that considers these features from the outset.

Honestly: I don't care if I have absolutely zero support from others for my efforts or if everyone thinks I'm crazy. I only have so much time to dedicate to FOSS a day. I feel much better to contribute to something like Unison, where I can hone engineering and systems programming skills than to continue throwing duct tape on LMMS.

That being said: I really appreciate the effort everyone has put into LMMS over the last few months. This is really exciting. The users are going to love it. I'm looking forward a few years though, and can see huge maintainability problems if we keep down the same path.

-- Paul

On 2/12/14, 11:39 AM, eagles051387 wrote:

Lets say Vesa mentioned the Fx mixer. Since that has been changed why not integrate that in with unison and then slowly start with other new fixes and then older ones which havent been changed etc.

On Wed, Feb 12, 2014 at 5:36 PM, Paul Giblock notifications@github.comwrote:

What do you mean? I'm not sure we are using the same definition of "integration".

-- Paul

On 2/12/14, 11:34 AM, eagles051387 wrote:

Paul Wouldnt it be best to integrate and fix as things progress?

On Wed, Feb 12, 2014 at 5:32 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

Reply to this email directly or view it on GitHub< https://github.com/LMMS/lmms/issues/282#issuecomment-34886624> .

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

[eagles051387]

I agree that unless we make the move maintenance is going to become an issue unless we make the switch.

Vesa do you think you could help him out in terms of getting things sorted?

On Wed, Feb 12, 2014 at 5:49 PM, Paul Giblock notifications@github.comwrote:

Right, and I want to know: What do you think integrating the mixer into Unison means? This doesn't really make much sense to me. Are you talking about integrating the model or the view? The model doesn't make much since since Unison's internals are vastly different.

Integrating the GUI makes sense, but only to a limited degree. My view for the Mixer in Unison is something more like what is in FL-Studio or Logic. Each Instrument gets their own strip, you can add buses, and you can wire the inserts as you please. So, sure, I could use LMMS's code to draw the faders, knobs and stuff. But, to say "Just integrate LMMS's mixer", is a bit far-fetched.

Maybe I'm an outlier here, but my goal isn't to pull in all the problems that LMMS (and other DAWs) have, but to make something that is better. Something fresh. Something that is built off of our experiences with LMMS over the last 10 years. This doesn't mean to pull in a bunch of work-arounds, but to design something that considers these features from the outset.

Honestly: I don't care if I have absolutely zero support from others for my efforts or if everyone thinks I'm crazy. I only have so much time to dedicate to FOSS a day. I feel much better to contribute to something like Unison, where I can hone engineering and systems programming skills than to continue throwing duct tape on LMMS.

That being said: I really appreciate the effort everyone has put into LMMS over the last few months. This is really exciting. The users are going to love it. I'm looking forward a few years though, and can see huge maintainability problems if we keep down the same path.

-- Paul

On 2/12/14, 11:39 AM, eagles051387 wrote:

Lets say Vesa mentioned the Fx mixer. Since that has been changed why not integrate that in with unison and then slowly start with other new fixes and then older ones which havent been changed etc.

On Wed, Feb 12, 2014 at 5:36 PM, Paul Giblock <notifications@github.com wrote:

What do you mean? I'm not sure we are using the same definition of "integration".

-- Paul

On 2/12/14, 11:34 AM, eagles051387 wrote:

Paul Wouldnt it be best to integrate and fix as things progress?

On Wed, Feb 12, 2014 at 5:32 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 06:29 PM, Paul Giblock wrote:

On 2/12/14, 11:18 AM, Vesa V wrote:

I'm not even sure what all needs to be changed/updated to make LMMS rt-safe...

A hell of a lot, that is why I am starting with the engine, then moving features from LMMS in a cherry-picking fashion.

What about existing plugins, instruments, new fx mixer, etc.? Will these be compatible with the new engine?

Reply to this email directly or view it on GitHub< https://github.com/LMMS/lmms/issues/282#issuecomment-34886624> .

Reply to this email directly or view it on GitHub< https://github.com/LMMS/lmms/issues/282#issuecomment-34887109>

.

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

Jonathan Aquilina

[pgiblock]

"Re-written from scratch" is a bit harsh. From what I see, the juicy bit of a plugin is the DSP code (the per-instrument implementation of NotePlayHandle, or whatever that class used to be called). This code need not change at all, the big thing that changes is the API used to read control/event data and to obtain the output audio buffers.

On 2/12/14, 11:45 AM, Vesa V wrote:

On 02/12/2014 06:40 PM, Paul Giblock wrote:

New FX Mixer? I could care less about that. The FX Mixer will be so much simpler in the Unison code since all the routing, mixing, etc is already handled by the engine. The mixer code would just have "wire" the strips together, the engine does the rest.

Or, are you referring to the Mixer graphical overhaul? Sure, I'd be happy to reuse elements from that.

Regarding instruments and stuff -- no, they are not immediately compatible. However, the way instruments work in LMMS (dynamically allocating Notes, wiring DSP procedures together with signals and slots, locking on the Song object) is one of the main things limiting us from being realtime.

So this means that all the instruments and native effect plugins would all have to be rewritten almost from scratch?

Would we still retain all the functionality LMMS offers right now in native plugins, eg. per-note envelopes, filters and pitch control?

I admit I have a bit of self-interest in mind here, as I've just written a plugin for LMMS, and plan on possibly writing more of them...

---

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

[diizy]

On 02/12/2014 06:55 PM, Paul Giblock wrote:

"Re-written from scratch" is a bit harsh. From what I see, the juicy bit of a plugin is the DSP code (the per-instrument implementation of NotePlayHandle, or whatever that class used to be called). This code need not change at all, the big thing that changes is the API used to read control/event data and to obtain the output audio buffers.

Ok, I assume the same applies to effect plugins...

Just one more question then, is there anything that could be done to current/new plugins (without breaking compatibility with current engine) that would make it easier to eventually port them to the new engine? I admit I don't really know anything about rt coding...

[eagles051387]

Paul let me suggest this. I would fork the current lmms repo and then anyone that wants to work can fork your repo and file puull requests with you that you can get then merged into the new master branch, or another branch

On Wed, Feb 12, 2014 at 6:13 PM, Vesa V notifications@github.com wrote:

On 02/12/2014 06:55 PM, Paul Giblock wrote:

"Re-written from scratch" is a bit harsh. From what I see, the juicy bit of a plugin is the DSP code (the per-instrument implementation of NotePlayHandle, or whatever that class used to be called). This code need not change at all, the big thing that changes is the API used to read control/event data and to obtain the output audio buffers.

Ok, I assume the same applies to effect plugins...

Just one more question then, is there anything that could be done to current/new plugins (without breaking compatibility with current engine) that would make it easier to eventually port them to the new engine? I admit I don't really know anything about rt coding...

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

Jonathan Aquilina

[JohannesLorenz]

Am Mittwoch, 12. Februar 2014, 06:00:13 schrieb Paul Giblock:

I personally feel this is all a waste of time at this point. LV2 plugins need a real-time safe host anyway, which is half the reason I sparked the Unison effort forever ago.

Sorry - my English is very bad. What do you mean by this? That developping ladspa++ would be a waste of time, or that coding LV2 support into LMMS would be a waste of time? (or what else would be a waste of time?)

[JohannesLorenz]

There's always LinuxVST, which would be easy to implement support for too, seeing as we already have the VST glue code.

LinuxVST has been mentioned multiple times in this thread, as if it was an alternative to any LADSPA version. Is this true? I went on

http://www.linux-vst.com/

but I did not see anything that looked similar to ladspa. They just say that LinuxVST was "the place to find native VST plugins and VST software for your favorite operating system".

So what do you guys mean by LinuxVST, and how far is it an alternative to any kind LADSPA?

[diizy]

On 02/13/2014 08:50 PM, JohannesLorenz wrote:

There's always LinuxVST, which would be easy to implement support for too, seeing as we already have the VST glue code.

LinuxVST has been mentioned multiple times in this thread, as if it was an alternative to any LADSPA version. Is this true? I went on

http://www.linux-vst.com/

but I did not see anything that looked similar to ladspa. They just say that LinuxVST was "the place to find native VST plugins and VST software for your favorite operating system".

So what do you guys mean by LinuxVST, and how far is it an alternative to any kind LADSPA?

—

LinuxVST is the same as VST, except it's native for Linux. We can pretty easily add support for it since we already have support for VST. Then we could run both LinuxVST and WindowsVST on Linux.

Why would it have to be similar to LADSPA?

It supports everything regular VST's does: GUIs, instruments, tempo syncing, etc. There are some good, pro-quality LinuxVST's available from places like LinuxDSP.

[JohannesLorenz]

LinuxVST is the same as VST, except it's native for Linux. We can pretty easily add support for it since we already have support for VST. Then we could run both LinuxVST and WindowsVST on Linux.

Why would it have to be similar to LADSPA?

It supports everything regular VST's does: GUIs, instruments, tempo syncing, etc. There are some good, pro-quality LinuxVST's available from places like LinuxDSP.

It does not seem to be very free:

"Because of license restrictions you need to get your own copy of the VST SDK header files from www.steinberg.net"

Despite that I can not find the header files there I would not suggest to support something which is not free. I'd say let's better develop our own standard instead of making us dependent on a company...

[diizy]

On 02/14/2014 10:06 AM, JohannesLorenz wrote:

LinuxVST is the same as VST, except it's native for Linux. We can pretty easily add support for it since we already have support for VST. Then we could run both LinuxVST and WindowsVST on Linux.

Why would it have to be similar to LADSPA?

It supports everything regular VST's does: GUIs, instruments, tempo syncing, etc. There are some good, pro-quality LinuxVST's available from places like LinuxDSP.

It does not seem to be very free:

"Because of license restrictions you need to get your own copy of the VST SDK header files from www.steinberg.net"

Despite that I can not find the header files there I would not suggest to support something which is not free. I'd say let's better develop our own standard instead of making us dependent on a company...

Well firstly, we already support VST via wine, so adding support to LinuxVST would just enable us to use Linux-native VST's, instead of having to rely on VST's made for a proprietary OS, so the LinuxVST support would be making us more free, not less.

Also, there are reverse-engineered open source alternatives to the steinberg SDK, meaning that we don't need to use the steinberg SDK (nor are we currently using it).

As for developing our own standard, why? We already have our own standard for plugins, that is LMMS native plugins, and those have a lot more functionality and power than LADSPA. It's not that hard to write them either, actually easier than LADSPA since you can use all of the functions and classes in both Qt and LMMS. Why would we need another?

[JohannesLorenz]

As for developing our own standard, why? We already have our own standard for plugins, that is LMMS native plugins, and those have a lot more functionality and power than LADSPA. It's not that hard to write them either, actually easier than LADSPA since you can use all of the functions and classes in both Qt and LMMS. Why would we need another?

The main reason for me is the code size of native plugins. You need 6 files (in order to follow our code conventions, which seam sane to me). So you need to write a lot of code, and the LMMS source ball bloats.

Right now I have ~ 100 effects in my plugin browser, almost all LADSPA. We'd have 600 files more in our src tree if they were all native.

Of course, we'd have graphics for all of them, then. But I really do not need a fancy background image for an LP2, a distortion effect, or a chorus.

[diizy]

On 02/14/2014 10:34 AM, JohannesLorenz wrote:

As for developing our own standard, why? We already have our own standard for plugins, that is LMMS native plugins, and those have a lot more functionality and power than LADSPA. It's not that hard to write them either, actually easier than LADSPA since you can use all of the functions and classes in both Qt and LMMS. Why would we need another?

The main reason for me is the code size of native plugins. You need 6 files (in order to follow our code conventions, which seam sane to me). So you need to write a lot of code, and the LMMS source ball bloats.

Right now I have ~ 100 effects in my plugin browser, almost all LADSPA. We'd have 600 files more in our src tree if they were all native.

Of course, we'd have graphics for all of them, then. But I really do not need a fancy background image for an LP2, a distortion effect, or a chorus.

You don't actually need 6 files, you can just put everything in one if you want.

And regardless of the amount of code - it's not that much work. What I did with the Waveshaper was: I started out by cloning the Bassbooster (I could have chosen any plugin but I chose that because it's relatively simple) and refactoring everything with "bassbooster" in the name. Then I just went through all of the files, modified everything I needed, and that was it. Using an existing plugin helps a lot because you'll see everything you need and how things are structured. The actual DSP code was easy to implement - actually very similar to LADSPA: there's one function/method which takes a sample buffer as an argument, and writes to that buffer. Plus, you get to use some of the niceties of C++ and Qt.

Source bloat? Why do you even worry about that? Text files don't take that much space, and each plugin is in its own directory anyways so it's not like they're hard to find or anything. I seriously don't see why this would even be a concern.

There's no need to convert existing LADSPA plugins to native LMMS plugins. We can support both LADSPA and native plugins - as we already do. It's not like we need all the plugins to be in the same format or anything. If you need a simple effect plugin with no GUI, just use LADSPA. If you need something more complex, use native LMMS. Where's the problem?

[tobydox]

I can only back diizy. As the native plugins are more powerful and provide a UI, they are of course a little bit more complex. Instead of putting and mixing all things together, we have a strict separation of model, view and actual DSP processing. This is state of the art

[tobydox]

I can only back diizy. As the native plugins are more powerful and provide a UI, they are of course a little bit more complex. Instead of putting and mixing all things together, we have a strict separation of model, view and actual DSP processing. This is state of the art

[tobydox]

In software engineering. If you only want to wire together data models and DSP code, LADSPA should be für.

[tobydox]

Fine. Wah, mobile devices can suck... ;-)

[JohannesLorenz]

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? ;)

Am Sonntag, 9. Februar 2014, 09:21:46 schrieb Tobias Doerffel:

I also think we should not waste time by trying to improve deprecated technologies, even though the intention is good. It would be optimal to invest that time into implementing proper LV2 support (some basics are done in the old-master branch but it was nothing usable). If support for Linux VST plugins works with our reverse engineered header, it would be an option as well (I'd not go for VST support which would depend on the proprietary VST SDK).