Linux Audio Programmers: LMMS needs your help

[diizy]

Hi, I'm a LMMS developer.

So, like many of you have probably seen, LMMS has went through some huge steps forward this year. When comparing the difference between 0.4.15 and our latest stable release 1.0.2, it's pretty huge. And our next release, 1.1, is going to be even more amazing.

But now, LMMS faces again challenges... we have a dire need of new developers and contributors. There's just so much potential in LMMS - I might be biased in saying this, but I feel it fills a niche in Linux Audio that no other open source DAW even attempts to fill. I think other Linux Audio softwares such as Ardour, Qtractor, Carla, Zyn, LinuxSampler etc. are great, and they have a very unique modular ecosystem around them, which is also great. But I feel that LMMS provides an easy gateway to Linux Audio for many, and even more, it provides a gateway to open source audio for people on Windows/Mac, possibly even getting some to migrate to Linux as a result.

So, I'd like to ask anyone who has any knowledge of programming, or of Linux audio, to consider if they would be willing to contribute some time to LMMS development. It doesn't have to be much, even small things help, like fixing some bugs in our audio backends or such. And if you don't have time to dive into our codebase, then maybe there are other ways you can contribute - like, for instance, consulting and helping with implementations of new features, like LV2 support, LinuxVST support, etc. - if you have experience of those formats, you could help us just by making your knowledge available to us.

Non-developers can also help of course, by testing, writing documentation etc. But at this point, we need developers (or consultants, or people experienced with Linux audio technologies) most. All help and contributions are appreciated.

You can join the discussion and development on:
- the LMMS-devel mailing list https://lists.sourceforge.net/lists/listinfo/lmms-devel
- LMMS on github https://github.com/LMMS/lmms/issues
- #lmms on FreeNode

[diizy]

How is the LV2 support going?
This is something I'd love to see happening on LMMS, I might be able to help if there's no one else currently working on it.

grejppi has a branch with a partial implementation for LV2 support, I'm not sure how current the code is or how much progress has been done... Any help with the implementation would surely be welcomed. I agree it would be great to get LV2 support working for the 1.2 release.

Last I checked, plugin GUIs didn't work yet, there was only basic implementation of instruments playing notes... and effect plugins haven't been implemented yet I think.

https://github.com/grejppi/lmms/tree/master-lv2

https://github.com/grejppi/lmms/compare ... master-lv2 (here you can see the lv2-specific commits only)

[sysrqer]

I wish I had some knowledge to contribute but unfortunately I can't write code and don't know lmms enough (or at all) to help with documentation. I would be very interested in it if there was lv2 and linuxVST support though, it's the one thing that made me give up with it when I tried it. It would be amazing to get those working.

[diizy]

hm, there seems to be quite some work on it already.

perhaps I can do another thing...
http://i.imgur.com/1t5cK38.png

falkTX, that is awesome. Is that actually working code?

This would be a huge improvement for LMMS, so I fully support this endeavour. Can you rebase this for the master branch? Both 1.0 and 1.1 are already under feature freezes, so all new stuff should go to master (which is to be 1.2)... also, the master branch has some new features which might be helpful here: support for sample-exact models, and sample-exact timing support for MIDI-events...


edit. Actually, now that I think of it: if it's implemented as a plugin only and doesn't require any changes to the API's or core, then it could also be possible to include it for 1.1 if you can get it stable and in sufficiently working order before, say, the first RC... otherwise master would be the better choice.

[diizy]

Yes, this is (initial) working code.

That's great! Do you have the code in a repository somewhere, so I could test the code?

Also, if you want, it'd be nice to post about this on the lmms-devel mailing list... many people there would surely be excited to hear about this.

The lmms-plugin side can be made stable quickly.
I just need to complete the LMMS API implementation and draw a little UI like zyn (something with a "show-gui" button).

Ok. I have to give a heads up though, there's some minor API differences between the branches... but whether it affects this plugin depends on how it's implemented (ie. is the plugin using the native NotePlayHandles, or does it use MidiEvents).

For now, it'd probably be best to base your branch on the stable-1.1 branch (which will become the 1.1 release), we can then port it up to master afterwards...

Carla though is not stable. This needs the latest git to get the plugin version, which is new code.
The plugin will have to be marked experimental.

btw, this doesn't need to include any carla code except the actual lmms-plugin.
carla installs some headers files and pkg-config file for which the plugin links to.

Well then, in that case, we can just add the plugin as an optional dependency, which can be switched on/off at compile time - it can be done the same way as the VST support, in cmake. It's also good that we don't have to add the entire Carla code in LMMS, since we're trying to limit the amount of 3rd-party code in our source tree...

We probably shouldn't yet include it in the windows build, at least for 1.1... Has anyone tried compiling Carla on Mac?

[DoosC]

This thread is so awesome and so exciting ! It's not even april's fool time, I'm shocked
This is happening for real
Ah ah, silly user you must think
This is just me being over enthusiastic about the best linux audio devs working together and creating wonders !
You are the best guys. Keep up !

[diizy]

Not yet, I haven't done most of the code anyway.
I'll do a github pull request some time later.

Ok, sounds good.

I haven't decided on this. for now only audio is working, no MIDI.

Oh... Are you coding it as both an effect plugin and an instrument plugin? Since LMMS makes a difference between instruments and effects, then there needs to actually be two plugins to support both behaviours. The same way we have vst_effect and vestige as separate plugins.

How do you have audio working currently? Do you already have it working so that you can get audio from Carla sent back into LMMS?

Also, how do you plan on implementing this when it comes to multiple plugin instances... say, if I open 3 Carla-LMMS-plugins inside LMMS, will they each start their own Carla-instance (like what Zyn does currently) or will they all use the same one?

The difference between using NPH's and MidiEvents is just that LMMS provides two different APIs for instrument plugins. NPH-using instruments use the playNote() function, whereas MidiEvent-using instruments use the handleMidiEvent() function. Both Zyn and Vestige in LMMS use the handleMidiEvent API, whereas the SF2-player uses NPH's and the playNote API and converts them to MIDI-events internally for fluidsynth. The only thing to note is, that NPH's are more designed for multistreamed native instruments (ie. instruments where each note is rendered separately in its own stream), so single-streamed instruments that use NPH's will have to also use an InstrumentPlayHandle, which is what the MidiEvent-based instruments also use, and the play() function, which uses the InstrumentPlayHandle to output sound to the FX chain.

You can probably see how the different APIs work from looking at the respective existing instrument plugins... sadly our code is a bit lacking in documentation at places, but feel free to ask if you have any questions about any of the APIs.

btw, does LMMS support plugin MIDI-out?
It didn't seem like from my tests.

Well, it could be implemented. We don't have any explicit support for MIDI-outputing plugins, none of our existing plugins have such functionality, but actually it should be relatively easy to do: say you have an LMMS instrument plugin, eg. the bridge to Carla, you'd just have to make it so that Carla first tells the LMMS-side plugin about the MIDI-events it wants to produce, and you'd then explicitly generate the MIDIevents in the plugin's rendering loop and send them over to the InstrumentTrack.

The good thing about LMMS-plugins is that they're very tightly integrated to LMMS, you're not limited to any kind of dedicated external-plugin-API, but can use all the functions inside LMMS, so generating new MIDI-events is just a matter of constructing a MidiEvent, then using the InstrumentTrack::processInEvent() function to process said event. Then those MidiEvents can be routed in LMMS to any other instruments or out from LMMS with LMMS' own MIDI-routing capabilities...

I did, and will later release binaries for the 2.0-beta2.
screenshot: http://robin.linuxaudio.org/tmp/carla_osx_meters.png

That's nice, since we're also working on a Mac-version of LMMS (which is still unstable though)...

[Drumfix]

I may sound harsh, but there cannot be a shortage of LMMS developers, if you can waste your time on an OSX port.
Get the app rock stable and fully featured on one platform, before you start porting to another.

[diizy]

I may sound harsh, but there cannot be a shortage of LMMS developers, if you can waste your time on an OSX port.
Get the app rock stable and fully featured on one platform, before you start porting to another.

Well, we all have our opinions

[diizy]

I don't think OSX or Windows is a waste of time.
For an app built on Qt, cross-platform support is almost a given. It only needs to handle a few cases to ensure a perfect integration.

Not having OSX or Windows builds is dismissing a *lot* of users.
If it's not too much work to support it and it doesn't get in the way of Linux releases, why not?

Agreed, and also: if someone comes along and says "we want to port LMMS to platform X" then what... we can't just say "no you can't do that, you need to migrate to Linux and help us with Linux development"... that would be absurd, and also impossible to enforce on a GPL licensed software. And also counter-productive, because it would just drive away developers who might have otherwise helped with problems that also affect the Linux version.

OS X support for LMMS is at the moment basically maintained by two people on their spare time... there's also been talk about an Android port before, although nothing has really come of it yet.

[Drumfix]

There is no problem with porting to other platforms if you have the resources. But diizy claims LMMS hasn't.

Not having OSX or Windows builds is dismissing a *lot* of users.

If your app is a must have for them, they will move to Linux. If not, why bother?
All they will do is, install it, run it, think "well, i can do the same with garage band", delete it.
Thats the bitter truth.

As for VST: There is a linuxvst plugin now that wraps windows VSTs. So when you simply change the (Win) VST support that you have in LMMS already to linuxvst support, you get them both.
And don't forget to add the exteral ui extension http://www.linuxmusicians.com/viewtopic ... 8&start=15

[diizy]

Drumfix: I'd kindly ask you to stay on topic here... I wrote here with the intention of letting people know of the lack of manpower and need of help in LMMS development, and while it's fine for you to have your own opinion about LMMS, you've made your point, so further rehashing of the subject would be pointless.

I respect that you have a different opinion. Please return the courtesy and do not derail the thread any further... ok?

[Drumfix]

My post could't be more on topic!

letting people know of the lack of manpower

That lack of manpower is comming from your intention to shift your own resource (manpower) to the OSX port.
And nothing else is what i'm saying.

Now suppose you were writing an OSX app and were asking in an OSX developer forum:
We have a lack of manpower, because we want to do a Linux port of our app. Can some of you OSX developers help us out ?

You could hear the laughs on the moon...

PS: What i wrote about VST above is a recommendation that saves you a lot of work and support.
You'd better follow it, if you're short on manpower

[diizy]

That lack of manpower is comming from your intention to shift your own resource (manpower) to the OSX port.
And nothing else is what i'm saying.

Well I'm sorry but what you're saying is simply incorrect.

Firstly you're making some very uninformed assumptions about how cross-platform development works and basing your opinions on those assumptions. Like I already mentioned, the OSX port of LMMS is maintained mostly by two people, who do it on their own time. Telling those people to "stop working on the OSX port" would not accomplish anything other than alienate and/or antagonize them, and we can't afford to lose good and dedicated people just because they work on what they want to work on.

Secondly, maintaining a port is not the same thing as developing new code. Just because some people are capable of porting LMMS to other platforms and maintaining that port, does not necessarily mean they would be capable of writing new functionality for LMMS. It doesn't mean that we could just take someone who maintains a port and tell them to implement LV2 support. Everyone has different skillsets, and open source development is not a zero-sum game. Also, there have actually already been cases where the OSX port has actually helped us to figure out and fix some issues in the Linux version.

LMMS is not a company nor a business of any kind. We don't have paid developers, we have a group of enthusiasts who all believe in the open-source development model and more or less believe in the ideal that it's an inherently valuable thing to provide an open and free cross-platform audio workstation software.

If you don't agree with that ideal, that's fine, no one is forcing you to, but for the third time, I'm respectfully and politely asking you to please respect our views the same way we respect yours. You've made your point, there's no need to hash this issue any further, and in any case this is not the right place to do it - if you want to discuss the merits or cross-platform development, please start a new thread to do so because that debate is not the subject or purpose of this thread, and all you're doing right now is derailing the actual topic of the thread.

Thank you in advance for your understanding and co-operation.

edit:

please use this thread for continuing the discussion on merits of cross-platform development

[diizy]

Getting back on topic here:

One other thing where I think people who are experienced with Linux Audio could help LMMS would be Jack support. LMMS has a Jack backend, but I think there are some problems with the implementation... I've been trying to look at it myself but so far I can't find any obvious fault in it, and I don't know much about Jack anyway...

If anyone wants to take a look at our Jack backend code, maybe submit some patches or just point out if we're doing something seriously wrong with it, that would be very much appreciated and would help with getting LMMS a bit closer to working well together with other Linux audio applications.