LMS Suite 12.05 is now available

[jeffh]

Many thanks, FalkTX, I'll test out your patches this weekend and apply them to my master branch if all goes well. One day soon when Linux dominates studios big and small all over the world, you'll deserve at least half of the credit for it's success.

@GMaq: Every other build of LMS Suite since I first released it around February was compiled in Ubuntu 11.10, I don't understand what went so horribly wrong this time, especially considering the core code changes were unusually small this time

I'm off for a night of debauchery, I'll try to contribute something useful to the Linux audio world when I get back

[jeffh]

Many thanks to FalkTX, I just pushed his Makefiles to my master branch, as well as some other changes to my build/packaging system to make it all compatible. I also added the audioEditing category to my packaging system, per GMaq's request.

Unless anybody here needs updated .debs from my SourceForge page, I'll probably just wait until 12.06 to upload new packages, since FalkTX kindly provided some already. The only real feature I'm planning for that release is a more mature Euphoria sampler with polyphonic effects, which I'm about half-finished with now. With any luck I may have that finished by next weekend, and then I'll release 12.06, and begin focusing on my plugin designer.

[GMaq]

jeffh,

Wow thanks for all your efforts on this so quickly. I will mention some findings which you may or may not want to look into for your next release. I am now using falkTX's packages and the plugins all work as expected however the behaviour in different hosts varies, Rosegarden seems happy for the most part however Euphoria crashes my Qtractor (0.5.4+SVN) and the Renoise demo (2.8.0) chokes on loading all your plugins to the point on having to kill it.

My point is not to criticize merely to point this out in case you hadn't noticed, also since AV Linux is primarily a Live ISO with various applications both open source and commercial I can't feature any plugins that don't work with the various hosts because the idea of course is to have everything preconfigured and ready to fire up.

I'd love to have libmodsynth on the next release because these are great DSSI plugins but something like the Renoise deal is a showstopper for me currently. Anyway that's an observation and certainly not a demand, I'll look forward to what 12.06 has to offer

[linuxdsp]

@GMaq: Ah - that will be why my install of renoise has stopped working... (I installed the libmodsynth plugins a while ago - I hadn't connected the fact that renoise hasn't worked since, and I've been too busy to investigate properly).

[linuxdsp]

@falkTX: I'll try that patch - previously I got the warnings about RT_CAPABLE not being set, which just meant that those plugins benignly failed to load, but, RayV and specifically Euphoria did something very nasty, which caused renoise to hang during boot (and had to be killed remotely from another terminal).

[jeffh]

Actually, some of this is what I'd like to call "The stupidity of LADSPA flags, and the DAW makers that implement LADSPA/DSSI poorly".

Without my exact per-DAW notes handy, what I've encountered is:

1. Ardour won't load LADSPA plugins that don't have the inline capable flag
2. Muse2 won't load DSSI plugins without the "don't allow inline processing" flag
3. Various DAWs either require the HARD_RT capable flag, or behave badly if it is there

I really don't know the best solution, but I was primarily targetting the LMS Suite to work properly in Muse2, because after evaluating all Linux DAWs, I believe Muse2 is going to be the best DAW in all of Linux when they release it this month. If anybody knows a solution(like a way to specify LADSPA descriptors based on the host that's loading it), I'd love to hear it, but I had pretty much come to the conclusion that there is no set of LADSPA flags that will result in working plugins in every host...

[linuxdsp]

From personal experience, I've found just about every plugin 'standard' on any and every platform I've tried to code for ends up being implemented with subtle variations between different hosts (even though many have a recommended SDK for the host as well / and / or the plugin). Part of the plugin developers 'art' (if there is such a thing..) is to make something which works with as many hosts as possible - and its often a frustrating and thankless task.. mainly because if its done 'right' no-one notices. (It also goes some way to explain why, for my plugins at least, testing takes at least as long if not longer than actually writing a 'working' plugin - and even then, things happen on some systems, with some hosts, which occasionally slip through the process. (Particularly true on linux, where there are so many different and ever changing distributions etc..)

[jeffh]

I appreciate the insight, but apparently loading DSSI effects in Muse2 requires a flag that breaks loading the same effect as a LADSPA in Ardour3, being compatible in one appears to be mutually exclusive to being compatible with the other. The LADSPA/DSSI constructor contains no arguments, so I'm skeptical that the plugin can know which DAW is loading it.

All of my plugins technically meet the requirements of being HARD_RT_CAPABLE, but setting the flag enables some DAWs to load it at all, while others introduce bugs and crashes. I could have separate packages per DAW, but for people like GMaq and FalkTX, that does them no good because they're going to include 10 different DAWs in their distro, and they surely don't want 10 different packages of my plugins. Alternately, I could compile several different versions of my plugins to be compatible with all different DAWs, but then I'd have to put them in separate folders not within a standard DSSI folder, and users/distro-maintainers would have to know to specify in each DAW to specify a different folder...

Anyways, those are the only solutions I can think of, unless you guys have a better idea. I'm willing to write code specifically for major distros like KX Studio and AV Linux, if you guys can come to a consensus of how best to handle the LADSPA flags issue. I can easily tell the build system to compile each plugin multiple times with different LADSPA flags for different host compatibility, but that's going to require some extra work from you guys to setup each DAW to include an extra DSSI or LADSPA plugins directory. Just let me know what you want to do...

[jeffh]

I'm not sure what you are referring to in "apparently loading DSSI effects in Muse2 requires a flag that breaks loading the same effect as a LADSPA in Ardour3". Ardour3 doesn't load DSSI at all, just LADSPA.
I think the problem here is the INPLACE_BROKEN flag instead, which ardour and maybe other hosts don't like (the host might actually *not* load the plugin at all if that is set).
From what I know, it's best to do not use INPLACE_BROKEN in any way.

I've seen several plugin collections that work everywhere, caps, tap and swh being examples.
I really want to get my DISTRHO Plugin Toolkit ready real soon, so that I can at least take this plugin-API madness away from some developers.

Actually, that's all wrong

I'll break down how all of this came to be:

1. DSSI plugins are all inherently capable of being loaded as LADSPA plugins(minus DSSI features like real GUIs and MIDI), as DSSI is based on LADSPA. The plugins need only be placed in a directory being searched by the host for LADSPA plugins, like /usr/lib/ladspa. As of LMS Suite 12.05, there are symlinks in /usr/lib/ladspa that point to the effects in /usr/lib/dssi(but not Ray-V or Euphoria). Therefore, LMS Suite 12.05(effects only) could be loaded in Ardour, except for the incompatible flag I need for Muse2. The most important LADSPA-only host that I enabled them to work in by doing this is Hydrogen.
2. Muse2 can load DSSI effects, which is something I worked closely with the Muse2 devs on, you can find it on their mailing list. However, it requires the INPLACE_BROKEN flag to work as DSSI. Furthermore, Muse2 won't recognize any plugins as LADSPA if in fact they are also capable of being DSSI plugins, therefore, that's why I chose to use it, possibly to the detriment of other DAWs.

I think the general concept is that every DAW on Linux has implemented their plugin hosting in various different ways that are completely stupid. If I were to write a DAW today, I'd support every flag, and treat them differently as needed:

Plugin is HARD_RT_CAPABLE? Then feel free to try to make it super-realtime
Plugin is not HARD_RT_CAPABLE? Then don't try to run it with 0.0001ms of latency
Plugin is INPLACE_BROKEN? Then don't freaking try to process it inplace.

By not supporting every possible combination of flags, the DAW developers are bringing the incompatibility upon themselves. Literally none of them have cared enough to implement the entire LADSPA standard, honestly, as a developer it baffles me. To be completely honest, the overall DAW situation on Linux disgusts me, the only application I have any hope for is Muse2, and Hydrogen if you consider that a DAW... I spent a lot of time talking to various DAW developers and evaluating to come to that conclusion, the others just aren't there yet.

I'm strongly considered abandoning the plugin aspect altogether, and making everything a standalone JACK applications to be used with a session manager and MIDI from a DAW through JACK MIDI connections. This brings the added benfit that I can have sample-accurate MIDI, which is a huge concern for Euphoria, as samplers can't playback tight-sounding drums without it. I could even use the plugins as-is, and just remove them from /usr/lib/dssi so hosts won't pick them up. They're completely 100% stable in standalone mode for everyone(as far as I know), it may just be best to use them that way.

[StudioDave]

Hi Jeff,

All props to your work, but there are some problems with LMS on some of my systems here. The hard-coded INCLUDE paths make no sense on Arch (maybe you should use pkg-config), you're using a custom Perl script instead of standard build tools (I build dozens of apps every week, yours is the only package with a Perl build dependency), and the plugin GUI hex color codes produce Qt errors on Arch, resulting in a bland washed-out appearance. I believe you already know that Ray_V segfaults on AVLinux.

Btw, your script assumes sudo. Not every system supports it by default. Kinda sucks for the user who doesn't know that there's difference between su and sudo.

Best,

dp

[linuxdsp]

@jeffh: I can understand the frustrations involved in trying to make plugins that work with all the different host applications (my first 'plugins' were developed as standalone JACK applications, for a few of those reasons) - but that was a few years back, and I think the situation has actually improved a lot. I think in part the problems have to do with your choice of plugin API. LADSPA (and by extension DSSI) will still work, and can be workable, but LADSPA is I think considered obsolete, in favour of LV2. LV2 now has a standard host SDK toolkit which should now enable greater compatibility across different hosts. Just about all the serious host applications now support linuxVST too, including Ardour(3) so between LV2 and linuxVST you should be able to code something with much greater compatibility / flexibility. Its also true that plugin / host compatibility is not just a problem on linux - the situation on other platforms is about the same (I've ported VSTs to / from Windows, and have to test them in a lot of applications there to make sure they work)

You used some quite emotive language about the state of current linux DAWs, I'd disagree - I think with Qtractor, and the latest releases of Ardour3, and commercial applications such as renoise, energyXT, the choice of serious (professional standard) DAW application on linux has never been better.

[StudioDave]

Hi Jeff,

I forgot to add that I like your plugins, especially Ray_V. Please continue development, DSSI or otherwise.

Best,

dp

[jeffh]

Thanks all, for the kudos as well as the constructive criticism.

I believe you already know that Ray_V segfaults on AVLinux. I wasn't aware of this, is there any steps to reproducing it? Please include information about what version of AV Linux, does it include the latest updates, and what version of Ray-V. If there was any nosedive in stability in 12.05, it may be from my user definable MIDI CC maps. They gave me some compiler warnings, but I never had a crash from them...

pkg-configTo be completely honest, I don't know anything about pkg-config, I don't know what it is, what it does, or how to use it. If it is, in fact, a holy grail that will make all of your lives easier, I don't mind using it, but it would be nice if those who have an interest in it(and presumably know a lot more about it that me), could perhaps steer me in the right direction, or even provide a patch.

Perl as a build dependency It's only a dependency for compiling and building applications, not for running plugins, and even the Linux kernel source contains Perl scripts. I actually chose Perl over PHP-CLI, because people weren't likely to have PHP-CLI installed, but 95% of distros come with Perl, so I don't think Perl is unreasonable as a build dependency. With the recent Makefile patch that FalkTX provided that I've added to my GIT master branch, you don't actually need to use the Perl scripts anymore, their more for developers using LMS to be able to debug and package their applications.

Plugin Format DSSI was/is the best option available. VST may have advantages, but I'm only going to focus on libre standards. I may integrate FalkTX's work to support multiple formats, but VST will never be a main priority format for me because it's a patent-trap. It took Dave R. 7 long years to declare LV2 stable, and support for it in DAWs is still a clusterf*** because he changed practically everything when 1.0 came out(after my project was already in full swing). LV2 may become the best format, but it's not currently properly supported by any DAW.

sudo With FalkTX's patch, I can get rid of that now, since he provided proper Makefiles for both individual plugins and all plugins simultaneously...

You used some quite emotive language about the state of current linux DAWs, I'd disagree - I think with Qtractor, and the latest releases of Ardour3, and commercial applications such as renoise, energyXT, the choice of serious (professional standard) DAW application on linux has never been better.

Renoise+EnergyXT: I'm only interested in supporting a full libre stack in Linux. If I'm going to go proprietary, I might as well stick with the thousands of dollars worth of Windows software I've purchased over the years.

Ardour and Qtractor: Quite possibly OK for recording a band in Linux, but not anywhere near being good enough for MIDI-based electronic music production(Muse2 is somewhat closer than both of them in terms of being truly usable). The timing isn't tight(to the extent of being audible), they both have severe graphical slowdown with many MIDI items on the screen, and various stability issues with using plugins. If I were recording a band or something similar though, it might be OK. Hydrogen is the only app that can do tightly timed sequencing and many MIDI items, but unfortunately it's just a drum machine, and not a full-blown sampler, it wouldn't be feasible to do an entire tune in it.

[StudioDave]

I believe you already know that Ray_V segfaults on AVLinux. I wasn't aware of this, is there any steps to reproducing it? Please include information about what version of AV Linux, does it include the latest updates, and what version of Ray-V.

Easy to reproduce, I just run it with jack-dssi-host and it segfaults immediately. All other LMS plugins seem to work okay. No other error message appears with the segfault.

I'm running AVLinux 5.0.2. I'm also always running your latest code. I check with git-pull every day.

pkg-configTo be completely honest, I don't know anything about pkg-config, I don't know what it is, what it does, or how to use it.

The pkg-config system provides package configuration details that are useful when querying system resources. See 'man pkg-config' for the details.

Perl as a build dependency It's only a dependency for compiling and building applications, not for running plugins, and even the Linux kernel source contains Perl scripts ... I don't think Perl is unreasonable as a build dependency.

I didn't say it was unreasonable. It's unusual in a build scenario, and no, it's not difficult to use or anything like that. But it does pose a difficulty for me if I'm trying to figure out problems in the build process (i.e. I am not a Perl programmer - or any other kind of programmer). I'm more familiar with the autotools system and more recent systems like waf and cmake.

Anyway, as you point out, it's no longer a problem with the LMS package.

... It took Dave R. 7 long years to declare LV2 stable, and support for it in DAWs is still a clusterf*** because he changed practically everything when 1.0 came out(after my project was already in full swing). LV2 may become the best format, but it's not currently properly supported by any DAW.

Personally I'm glad drobilla took the time to get it right. Whatever the merits of DSSI it has not "caught on" with the majority of Linux plugin devs. I don't know why, but it isn't because those devs are stupid.

sudo With FalkTX's patch, I can get rid of that now, since he provided proper Makefiles for both individual plugins and all plugins simultaneously...

The top-level Makefile is borked on Arch 64, I had to go through each directory and build each plugin with the autotools mantra (configure/make/make install).

Renoise+EnergyXT: I'm only interested in supporting a full libre stack in Linux. If I'm going to go proprietary, I might as well stick with the thousands of dollars worth of Windows software I've purchased over the years.

So the users lose ? Renoise and MixBus are wonderful apps, many Linux music-makers work with them. And how will you figure Bitwig into your plans ? It's certainly what most younger users think of as a "complete DAW", i.e. more like Ableton.

Ardour and Qtractor: Quite possibly OK for recording a band in Linux...

I think they're "quite possibly" already fine for such purposes.

The rest of your comments have to do with topics I have no concern for. I don't say that they're dismissable, only that you and I don't have the same definitions in mind when terms like "electronic music" and "sequencer" are tossed around, so there's very little to be gained by an exchange on that level (been there, done that with Louigi V). When I hear "electronic music" I'm thinking about Karlheinz Stockhausen or Mario Davidovsky, and I'll wager you're thinking of something else entirely. And the software you find so distressingly awful for your notion of electronic music works quite well for mine.

Anyway, thanks for your considered replies, they are much appreciated (along wth your plugins, of course). Keep up the good work.

Best,

dp

[jeffh]

Easy to reproduce, I just run it with jack-dssi-host and it segfaults immediately. All other LMS plugins seem to work okay. No other error message appears with the segfault.

I'll check it out this weekend...

Personally I'm glad drobilla took the time to get it right. Whatever the merits of DSSI it has not "caught on" with the majority of Linux plugin devs. I don't know why, but it isn't because those devs are stupid.

I don't agree with your analysis of the situation, and I'm not convinced that Dave actually "got it right", even after 7 years. It's not difficult to write a plugin standard, you're basically defining a way that hosts send/request buffers and MIDI data, then the plugin developers do their own implementation of the rest. I'd gladly write my own plugin standard if just one or two major Linux DAWs would agree to implement it,

Furthermore, LV2 plugins haven't taken off in a major way either, I think the biggest problem is that there is a huge lack of people that know how to program DSP in C/C++, and have an interest in doing so in Linux. Most of the 10,000,000 Windows VSTs were made in SynthEdit(some pretty good, many of them absolute crap), which is where the ultimate aim of my project leads to: An easy visual plugin designer that even a non-programmer type can use. DSP programming is totally different than your average web/Qt/Gtk development, there is a ridiculous amount of college-level calculus and sampling theory involved, and it's extremely difficult to debug and troubleshoot, hence there aren't many programmers who specialize in it.

The top-level Makefile is borked on Arch 64, I had to go through each directory and build each plugin with the autotools mantra (configure/make/make install).

I tried Arch once; It experienced a fatal error during the install and I never tried it again... Being that the toplevel Makefile is so simple, I'm kind of inclined to say Arch is probably at fault here:

Code: Select all

#!/usr/bin/make -f

all: build

build:
	$(MAKE) -C euphoria
	$(MAKE) -C lms_comb
	$(MAKE) -C lms_delay
	$(MAKE) -C lms_distortion
	$(MAKE) -C lms_eq5
	$(MAKE) -C lms_filter
	$(MAKE) -C ray_v

install:
	$(MAKE) install -C euphoria
	$(MAKE) install -C lms_comb
	$(MAKE) install -C lms_delay
	$(MAKE) install -C lms_distortion
	$(MAKE) install -C lms_eq5
	$(MAKE) install -C lms_filter
	$(MAKE) install -C ray_v

clean:
	$(MAKE) clean -C euphoria
	$(MAKE) clean -C lms_comb
	$(MAKE) clean -C lms_delay
	$(MAKE) clean -C lms_distortion
	$(MAKE) clean -C lms_eq5
	$(MAKE) clean -C lms_filter
	$(MAKE) clean -C ray_v

It doesn't get much simpler than that(many thanks, FalkTX).

So the users lose ? Renoise and MixBus are wonderful apps, many Linux music-makers work with them. And how will you figure Bitwig into your plans ? It's certainly what most younger users think of as a "complete DAW", i.e. more like Ableton.

Like I said, I'm interested in providing people with truly libre software, consistent with the principles of Linux and FOSS. I think that some of the great software projects like Muse2 and Hydrogen are totally capable of catching up with the commercial software, so I don't feel that anybody is losing out on anything. At any rate, I've shared my DSP knowledge in a public manner, that will always be available on SourceForge, including the source code. Even if I abandon the project, the community will always be free to take my work and fork it into whatever suites their needs. If LMS was proprietary, you'd be at my mercy as to whether I decided to support Renoise or Bitwig(which is still vapourware, BTW), but since LMS is 100% libre, anybody is free to make it do whatever they want, as long as they abide by the GPL license.

I think they're "quite possibly" already fine for such purposes.

The rest of your comments have to do with topics I have no concern for. I don't say that they're dismissable, only that you and I don't have the same definitions in mind when terms like "electronic music" and "sequencer" are tossed around, so there's very little to be gained by an exchange on that level (been there, done that with Louigi V). When I hear "electronic music" I'm thinking about Karlheinz Stockhausen or Mario Davidovsky, and I'll wager you're thinking of something else entirely. And the software you find so distressingly awful for your notion of electronic music works quite well for mine.

Like I said, I make loopy electronic music like they played at ye olden "evil all-night dance parties"(tm). I'm not really concerned with anybody else's use-case, but Qtractor, Ardour, etc... literally weren't capable of making music the way I make it. They couldn't maintain stable audio output without timing artifacts or crashing, and they couldn't handle 100s of MIDI items in the arrangement without slowing to a crawl. Reaper, Cubase, etc... are all capable of tight MIDI timing and efficient GUI drawing with many items.

Of course, I'd encourage anybody to use Linux, and even Qtractor/Ardour if it suits their needs, but as of today, they don't suit mine.

Anyway, thanks for your considered replies, they are much appreciated (along wth your plugins, of course). Keep up the good work.

Best,

dp

Glad you enjoy them