The linuxDSP Workstation Plug-ins Bundle is now available as Pay What You Want for a limited time until the end of June 2014. A unique opportunity to add professional console grade processing to your Ardour sessions for a fraction of the normal price (or whatever you think it’s worth). Min price £5.00 (to cover payment processing and charges). Get it here:
http://www.linuxdsp.co.uk/download/lv2/download_wpp
@linuxDSP: I’m running into an issue with installing the MBC2B. I’m getting Could not open Input Method (XIM). Not sure what this means.
hmm odd - does it happen with any of the other installers? Usual questions… What distro, etc etc - you can install the plugins manually, or via the .deb packages, or if none of those options are working either, email the support link on the linuxDSP website with all the information you have and I’ll advise…
No actually I installed the BlackEQ just fine using the lv2 amd64 installer but this one is not working. I’m on Arch x64.
ok, that’s even more odd, because they should all be the same basic installer code. In the folder containing the installers, you should also find an archive called plugin_binaries.tar.gz - unpack this, and you should find folders containing the various plugin formats etc and a README detailing how to install the files manually. If you still have problems, send an email to the support link on the linuxDSP website and I’ll assist… successfully deploying applications on linux is at best difficult and at worst, almost impossible, but we try to cover all the options… I’m disappointed it hasn’t worked properly for you
ok, I’ve just tested it here (although on Ubuntu 12.04) and all the MBC2B installers worked, looking at the code there isn’t an obvious reason why the problem should happen, although the limit of the installer involvment at that point is to ask X11 for a suitable Input Method based on the configured localle - so something in the deep dark recesses of XLib / X11 could be doing something weird… I’d be interested to figure out why it isn’t working in case its an issue for other users - can you send an email to the support link (support at linuxdsp.co.uk) on the linuxDSP website if possible, with the terminal output if you run the installer from a terminal - and also which installer it was (LV2, JACK or VST) which caused the problem (or all of them?)
- and your localle / language settings too
@dsreyes1014: Thanks, got it - I can’t replicate the problem here, but I have unearthed some similar issues affecting things like Steam sometimes on some distros. Language / locale settings and X11 / distro integration thereof isn’t always very good - to put it mildly (normally sufficient layers of workarounds in the various system components seem to hide this from the user…) I guess that, if for whatever reason X11 on a particular version of a particular distro is not going to return us a reliable Input Method to use there seems little that we can do - except to recommend installing the software manually - as you have done - (which is a shame… Its supposed to be a really good installer™… 
) - so much for things that “just work…” - on linux… never.
You could try running it from the terminal with
LC_ALL=C [plugin-name]-installer-LV2-amd64
for example, but even if that works it kind of defeats the point of a ‘single click installer’ - I’ll see if there’s a way to make it fail over to some basic setting without crashing, or if there’s some subtle issue I’m not aware of, but as its possible to install the software manually I doubt if this can be a high priority at the present time.
@linuxdsp: Ok cool. I completely understand the priority thing. Hopefully if someone runs into this same issue a quick google search will lead them here. Great work on the plugins by the way!!! Thanks again.
@linuxdsp This is an awesome offer. Thanks! Just a quick question: is there any real difference between the lv2 and vst versions of the plugins as far as the user is concerned? This is assuming a host program (Ardour 3 in my case) that supports both formats. I have read this interesting interview from a couple of years ago (http://libregraphicsworld.org/blog/entry/lv2-from-developers-standpoint) in which you say that your LV2 code is just the VST code “wrapped” up to communicate via LV2, if I understood correctly. Maybe this suggests that VST is the best choice if the host supports it?
@mathewjohnrussell: The DSP code is the same, so there shouldn’t be any difference to the audio - there should be no difference in terms of CPU usage, certainly on a modern system. Essentially we have to provide an X11 based UI for VST compatibility, and as the UI is by far the bulk of the plugin code, it makes sense (at the moment) to use a very thin LV2 wrapper to ‘talk’ to the UI rather than to re-write a custom LV2 UI for GTK, Qt or whatever other mix of host plugin toolkits might be being used, depending upon the application - that’s all part of a much more complex discussion about how to integrate plugin UIs with an array of different host applications based on various toolkits, a uniquely ‘linux’ problem with plugins - and something I don’t want to go into again here.
Functionally, there is some difference between preset handling / options in the VST and LV2 versions, dependent on which / why /what flavour of LV2 extensions are / were /will be / may or may not / be supported, by the host whereas VST is fairly standard. The current settings will of course be saved in the Ardour session whichever you use.
- My preference is for VST at the moment - as its a better fit with the design choices made by other commercial applications, although I appreciate the technical / philosophical reasons some have for favouring LV2 on linux
linuxdsp: regarding GUIs … this isn’t a uniquely Linux problem, and it isn’t fair to label Linux as the only platform where this is or has been an issue.
For years, AudioUnit plugins have shipped with Carbon GUIs that do not work in 64 bit AudioUnit hosts. For years, Reaper has added extensions to VST to allow VST plugins to provide a Cocoa based GUI because the VST specification is based on Carbon (which started to cease functioning with OS X 10.6.8 and has now more or less died entirely). There were even some lesser-known (though still proprietary) hosts that would only support Cocoa or Carbon GUIs but not both.
What is different about Linux is the right solution isn’t obvious.
@paul: Yes there is an issue with Carbon / Cocoa - but actually its much better defined than you make it out to be, and as far as Audio Unit is concerned, since about OS X 10.5 Cocoa can be regarded as the de facto ‘standard’ - no-one should really be coding Carbon at all, in fact its been technically deprecated since the first release of OS X I believe.
its also not correct to say that the VST specification is based on carbon, at least not since 2.3 / 2.4.
32Bit VST hosts on Mac OS X expect the plugin to provide a carbon based UI, and provide the plugin with a pointer to a host provided carbon ‘parent window / view - use whatever terminology you like’ when calling the plugin’s editor ‘open’ function.
64Bit VST hosts on Mac OS X expect the plugin to provide a Cocoa based UI, and provide the plugin with a pointer to a host provided NSView when calling the plugin’s editor ‘open’ function.
That’s it - there are no other options - there might be some trickery / hacks if you use VSTGUI, but at a plugin API level what I described is what you get (I’ve ported plugins to Mac OS X, and the GUI code to obj C, I’ve done this and it works). It resolves quite cleanly to if 32Bit Carbon , if 64Bit Cocoa. Whatever Reaper may or may not do in addition, it also obeys this rule.
In contrast, there are ‘how ever many you like, add another toolkit of your own if you feel so inclined’ number of different choices, on linux - and who knows what the host application will be using - and no revision control with which to manage / expect / predict supported available UI technologies or toolkits, just an adhoc collection of UI extensions which have (and continue) to evolve over time.
From a developer point of view, I prefer VST, because I can clearly define what I have to provide to be compatible with all host applications which support that standard on a given OS and a user can reasonably expect any VST2.x plugin to work with any VST2.x host. With LV2 I can’t be so sure.
But, as I said, I can understand the reasons why some favour LV2 on linux.
- Steinberg’s Cubase on 64Bit Mac OS X also expects VST plugins to provide a Cocoa UI, so I don’t think it can be classed as some reaper specific work-around as implied.
linuxdsp: the extension came from the Reaper folks as I understand it, and then was used by other hosts. The VST 2.4 spec by itself does not support the notion of a Cocoa UI. It could be that VST 3.x has added some way to specify this without the canDo mechanism, but I haven’t read it.