Re: [LMMS-devel] api for creating plugins

[Vesa <di...@nb...>]

On 05/30/2014 06:34 PM, Tres Finocchiaro wrote:
> > ... could we create a gui within lmms that taps into those features
> and wont require coding
>
> Are you trying to describe a plugin builder?
>
> It would be quite cool to take a QML-like approach and have IDE-style
> drag-and-drop plugin building using existing components but as a rule
> of thumb, whenever end-user software tries to code itself, it is
> usually a bad idea.  The reason the dev team would spend the next 6
> months creating an interface for creation and unless users are
> screaming at us to make their own 1-off instruments or plugins (which
> they aren't, they're still learning the ones we have) I don't think
> there's a demand for such feature.

Well, I've actually thought about this before.

The way I see it, if we wanted to implement our own modular synth, it
could be done. It'd be entirely possible with the building blocks we
already have. Qt provides us with XML for saving the information about
the modules and connections, we could have a set max amount of
user-definable controls ( kind of like Vestige has a number of controls
that get defined by the plugin )...

>
> Worse, each component would have to be rewritten for modularization.
>  What you are describing is a mess, IMO.

Actually, this isn't necessarily true.

Most of the internal DSP code that we have is already very much modular.
It's just the higher level user-facing features of LMMS that are more
linear, the UI and the instrument -> fx chain -> mixer paradigm ( and
even our mixer is now modular, at least internally )... the actual
lower-level DSP components - filters, effects, generators, etc. - are
already modular and can be used very flexibly.

The entire modular synth could be written as a native LMMS instrument
plugin. This is entirely possible with the components we have now, it
would certainly be a lot of work, but it is possible to do.

I've played with the idea of a true modular synth that uses native LMMS
components to implement the modules. It would be very simple in design,
containing three types of user-definable elements: controls, modules and
wires.

Controls would work as such: each can be either a knob, a toggle-led or
a combo-box with defined options. Writing the XML and other structures
for this shouldn't be too hard, we have something very similar in the
Ladspa hosting code already, and we could just adapt that for this purpose.

Modules could be basically just functions inside the instrument plugin,
which get called per period. For example, the XML of the
modular-synth-preset could state that there are 3 oscillator modules,
and then each period, the modular synth would call the
oscillator-function three times, and tell them to write their output to
the wires they're connected to.

Wires would basically be buffers that connect modules to each other.
When the modular-synth-instrument-plugin calls each module's associated
function, the function writes its output to the wire buffer, and then
the module at the other end of the wire can read its input from the wire
and output to another wire...


Writing the actual synth would probably almost be the easiest part of
this. The most difficult part IMO would probably be in implementing the
editor for the modular synth. It'd require lots of UI coding, new custom
widgets, etc. We'd have to decide whether the editor would be a part of
the instrument plugin and thus work inside LMMS only, or if it should be
an external program, either option has its pros and cons, both have
different challenges...


In conclusion, I think a native modular synth for LMMS would be entirely
doable with our current assets, but it would be a very huge amount of
work to do, and since we have plenty of stuff to do already, I'm not
sure if we should put our limited resources towards it... at least not
at this point in time.


Another option to consider is to use an existing, mature,
maintained-by-someone-else solution, such as AMS or Ingen, and integrate
it with LMMS. That'd probably be a lot less work for us, although it
would allow us much less control and less features - it'd probably have
to be a midi-based single-stream instrument, and thus would have less
functionality than a native solution in some aspects (no per-note pitch,
no env/lfo...).