SDK for custom instrument creation

[eagles051387]

This is an idea. I am not sure if there is already something of the sort available, but I think it would be awesome to have the ability to create custom instruments from scratch. This would greatly benefit lmms in the sense that the community can also contribute not only songs but new instruments as well.

[softrabbit]

What should this SDK contain? I might have some notes from a first-timer point of view on putting together a plugin.

[zonkmachine]

Well. If we could add lmms as an architecture to faust I would be a happy, happy soundhacker. :o)
https://sourceforge.net/projects/faudiostream/
http://faust.grame.fr/

There is also Cabbage which use Csound to create cross platform soundapps. It could perhaps be tweaked to generate lmms plugins?
https://github.com/cabbageaudio/cabbage

[tobydox]

Basically the SDK would contain most of the files of the "include" directory and maybe the BuildPlugin cmake file - nothing special. In the end this would be up to the distribution package maintainer to provide a separate "liblmms-dev" package or similiar.

[eagles051387]

You know what else im thinking and it woudl involve a fair bit of work. I
think we shoudl have a gui front end as well to work with for those that
might not be as programming savvy as some of us here.

On Wed, Jan 15, 2014 at 10:58 PM, tobydox [email protected] wrote:

Basically the SDK would contain most of the files of the "include"
directory and maybe the BuildPlugin cmake file - nothing special. In the
end this would be up to the distribution package maintainer to provide a
separate "liblmms-dev" package or similiar.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-32419814
.

Jonathan Aquilina

[raindog469]

I posted about this on lmms-devel, forgetting that there was a bug report. I think that using something that already exists, like csound or Pd, would suit LMMS' swiss army knife nature better than writing yet another SDK that's incompatible with everything out there. The advantages include a user base that already exists and knows how to make patches in each of these tools, a huge number of sound options that already exist (csound has 1700 opcodes and supports plugins on its own, Pd isn't quite as extensive but is easier to wrap your head around and was made with a GUI in mind) and not contributing to the fractious nature of Linux/Free audio software.

Here are some possibilities, and of course there are others:

1. Wrap Pd in the way that LMMS already wraps Zyn, including its own copy of the whole codebase.
2. Wrap Pd, but make an LMMS-specific GUI for it, since its own GUI is Tcl/Tk based and looks like it.
3. Wrap csound, in such a way that we just use existing .orc/.csd files and leave the editing to the users (this is closest to the suggestion at the top of this bug report, to my mind).
4. Wrap csound and write a GUI for generating orchestras, only able to open and edit orchestras that it built.
5. Wrap csound and one of its existing GUIs.

As I understand it, Pd can use csound as an instrument, and for all I know the opposite may be true too. So either of these options would accomplish a lot of what the OP is asking for, without having to reinvent the wheel, introduce yet another competing plugin "standard", nor make would-be instrument creators learn to write code or edit XML files by hand (except for option #3).

[unfa]

I have very limited knowlege on Pd or Csound, but I think I'd finally learn
them.

Is integrating AMS or Ingen an option? Anybody knows what I'm talking about?

On 17 Jan 2014 20:03, "raindog469" [email protected] wrote:

I posted about this on lmms-devel, forgetting that there was a bug
report. I think that using something that already exists, like csound or
Pd, would suit LMMS' swiss army knife nature better than writing yet
another SDK that's incompatible with everything out there. The advantages
include a user base that already exists and knows how to make patches in
each of these tools, a huge number of sound options that already exist
(csound has 1700 opcodes and supports plugins on its own, Pd isn't quite as
extensive but is easier to wrap your head around and was made with a GUI in
mind) and not contributing to the fractious nature of Linux/Free audio
software.

Here are some possibilities, and of course there are others:

Wrap Pd in the way that LMMS already wraps Zyn, including its own copy of
the whole codebase.
Wrap Pd, but make an LMMS-specific GUI for it, since its own GUI is
Tcl/Tk based and looks like it.
Wrap csound, in such a way that we just use existing .orc/.csd files and
leave the editing to the users (this is closest to the suggestion at the
top of this bug report, to my mind).
Wrap csound and write a GUI for generating orchestras, only able to open
and edit orchestras that it built.
Wrap csound and one of its existing GUIs.

As I understand it, Pd can use csound as an instrument, and for all I
know the opposite may be true too. So either of these options would
accomplish a lot of what the OP is asking for, without having to reinvent
the wheel, introduce yet another competing plugin "standard", nor make
would-be instrument creators learn to write code or edit XML files by hand
(except for option #3).

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

[Sti2nd]

"If we could get other
audio software developers interested in the project" and help out, then others could still focus on improving LMMS by removing bugs.
"I think a GUI for this is essential" in the long run, but in first instance anything is enough. XML, another standard

As artist I don't yet feel the need, but then I am not that kind of artist who uses a week on making an instrument, not yet at least ;-)

[zonkmachine]

I think we shoudl have a gui front end as well

I think you mean something like this. (not the media player part...)
http://gdam.ffem.org/ladspa.html

Edit: Removed not-so-pretty image... :)

[eagles051387]

Never really gave it much thought about the look but i think that would
scare people off lol Obviously this would need to be a bit prettier.

Toby could we get a branch for this based of stable? or do you think this
should be put on hold for now?

On Tue, Jan 28, 2014 at 2:59 PM, Oskar Wallgren [email protected]:

I think we shoudl have a gui front end as well

I think you mean something like this. (not the media player part...)
http://gdam.ffem.org/ladspa.html
[image: mininet]https://f.cloud.github.com/assets/6368949/2019466/9c38a8ba-8823-11e3-9cf9-5e82c337977e.jpg

Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-33479946
.

Jonathan Aquilina

[zonkmachine]

Bitwig studio is being launched in a few months and they have announced a future built in modular synth to be able to generate instruments. So maybe dust off alsamodular? :-P

[eagles051387]

My goal is to turn this into more then a music production platform. I want
it to be an easy to use instrument creation platform as well. regardless of
you being a producer only.

On Mon, Jan 27, 2014 at 7:08 PM, Stian Jørgensrud
[email protected]:

"If we could get other
audio software developers interested in the project" and help out, then
others could still focus on improving LMMS by removing bugs.
"I think a GUI for this is essential" in the long run, but in first
instance anything is enough. XML, another standard

As artist I don't yet feel the need, but then I am not that kind of artist
who uses a week on making an instrument, not yet at least ;-)

Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-33402704
.

Jonathan Aquilina

[ghost]

I'd love to be able to create custom plugins.

[eagles051387]

I think what we need for this is a documented api
On 27 May 2014 12:14, "Cubiicle" [email protected] wrote:

I'd love to be able to create custom plugins.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-44257371
.

[PaulBatchelor]

What is the status of this issue?

For what it's worth, I do have experience working with the Csound API, and I have mucked around with the internals of both PD and ChucK. I also have a pretty good embedded synthesis language of my own called Sporth that is quite easy to drop into larger projects.

[zonkmachine]

What is the status of this issue?

No one is working on this. I also don't know if we have a consensus on what SDK means.

For what it's worth, I do have experience working with the Csound API

If we can get a language like Csound into LMMS, I assume it would be just the .orc files in our case, that'd be really cool. With more than one language capability I think opening them from one single instrument plugin would be the way to go.

I also have a pretty good embedded synthesis language of my own called Sporth

Someone's been busy... 🐳

[PaulBatchelor]

Definitely an LMMS noob, but I do have experience working with various music language APIs and plugin formats.

Getting languages like Csound/Sporth into LMMS is straight forward enough. Glancing at the LMMS source code, it already looks like there's a defined third-party plugin format in C++ (have not tested this, but here I am assuming it works). It is mostly a matter of putting the API functions in the right places within the plugin, and linking the libraries up.

The difficulty in my mind is setting up UI and binding it to parameters within the respective language. If you are not baking the UI into the plugin at compile-time, you'd want a way of defining a layout and adding widgets (some sort of XML/JSON markup perhaps?), which can then be loaded and parsed when the plugin itself is parsed. This is something I wouldn't know how to do.

In a single instrument plugin setting, there would probably be a "load" button, where a file browser would pop up and you'd select the file you'd want to load, which would be "remembered" the next time you open up the project. This sort of functionally I would have to figure out as well.

PS: @zonkmachine you mentioned Faust, which is also not a bad option. I've made Faust architecture files in the past, and they aren't too difficult to make.

[interstar]

Seems to me that Faust is shaping up to be really good "cross-platform" (in the sense that it compiles to PD, Supercollider, web-audio, VST and C++), high-level language for defining synths and effects units. Co-operating with the Faust development people to make it into a first-class citizen of the LMMS ecosystem would pay huge dividends. (For both communities).

[PaulBatchelor]

A little bit of progress here.

About a month ago, I made a proof of concept LMMS plugin that doesn't need to be compiled with LMMS:

https://github.com/paulbatchelor/lmms-reverbsc

It uses cmake, and includes the headers from LMMS. It's overkill, but not unheard of. The VST SDK
is essentially a ton of header files as well.

The great thing about this is that it allows you to rapidly prototype outside of the LMMS codebase.

The next step is doing some tests to get FAUST-generated C++ hooked up, and to figure out a way to get LMMS UI elements to fit into the mold of the FAUST UI elements. From there, you can build a FAUST architecture file for LMMS, which more or less just a text template. At that point, you can build a faust2lmms script which automatically generates LMMS plugins from FAUST code!

[tresf]

Duplicate of a few separate bugs: #2616, #3412, #562, #416 are the best topics of discussion with the general consensus to be to dedicated time to LV2 (Which stands for Linux Audio Developer's Simple Plugin API "LADSPA" version 2) with some mentions of LinuxVST as well -- Both of which offer instrument plugin capabilities.

Furthermore, @PaulBatchelor's stop-gap proof of concept plugin can do exactly what the OP requests, so closing this one out.