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:
#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
#282 (comment).

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:
#282 (comment)

[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:
#282 (comment)

[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:
#282 (comment)

[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//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//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//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//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//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:
#282 (comment)

[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:
#282 (comment)

Reply to this email directly or view it on GitHubhttps://github.com//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//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//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//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:
#282 (comment)

[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:
#282 (comment)

Reply to this email directly or view it on GitHubhttps://github.com//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//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//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:
#282 (comment)

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

[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//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.