[HOWTO] Ardour + ardour/vst cohexistence: binary (non vst) packages + easy instructions published

Installation & Configuration Linux
#1

Hi, i would like to share with community part of a work i’m doing on multimedia linuxes.

The main goal is “people playing with multimedia should not spend time fix system”, so i began to maintain a little “overlay” to plain Debian and Ubuntu systems, that will only contain stuff that matters: a realtime kernel (debian lacks it), useful information for getting most from hardware, well (re)packaged software.

For ardour, i made available non-vst binary packages that can cohexists with vst enable ones: for those that are interested, please visit at https://www.scimmia.net/code/wiki/DebianPackages/ArdourVst .

Note that although supported platform are debian lenny and ubuntu intrepid, this stuff should be ok for every derivative distro. Let me know in case.

Please also feel free to give feedback here or there, and open bugs if something goes wrong.

Cheers,

ale

#2

ale,

Perhaps due to the language barrier, we are not understanding each other,

I DO NOT want you to fix my system…or build some special repo for my personal benefit, quite the opposite actually, my system works perfectly with Ubuntu Gutsy. Because it works so well with a particular version of (Wine 0.9.49) I thought you might find that of interest for your proposed repo to benefit everyone interested in ArdourVST

I was trying to share the knowledge I have learned from building ArdourVST for over a year now to help you with your project under Debian Lenny.

There are several versions of Wine and Wine-dev (for compiling) for Debian Etch 4.0 all the way up to version 1.1.1 at the bottom of this page:
http://wine.budgetdedicated.com/archive/index.html

If you mean Lenny instead of Etch as “Stable” then perhaps that is a source of our misunderstanding.

I was assuming the Etch Wine versions would install on Lenny since there are no official Lenny builds of Wine.

Curiously, you seem to be out of patience with me, so if by “Ciao” you mean “Get Lost” I am happy to do it.

Best of Luck with your project,

#3

So, i tried recompiling the whole against stable’s wine, the result is:

  • vst window is one, instead of two, if i configure wine for not having window manager to manage windows ... but unfortunately inside the ardour's vst win appears, neste, a windows "style" one, and it's very unstable (it disappear if i click on inner title, and never reopens)
  • the general feeling is that pre-1.0 wine is really non-deterministic in regard to standards hints and windows management stuff, so it's very YMMV depending on configurations, and also badly interact with ardour's vst related piece

For example, using a tiling window manager like xmonad tend to give very bad behaviours, and in general every wm i tried tends to have problems.

So i’ll not maintain such a monster :), but i’ll investigate on ardour’s vst code, as i suspect the “no nest” problem reside here.

I’ll publish info ASAP, but not so soon as i’m not so proficient with C …

cheers,

ale

#4

glen, excuse my indeed rude tone, i’m not really out of patience with no one nor i underestimate your feedback.

The problem using a version of wine not currently in debian is a long term shoot in the foot for me and everyone else: doing that would require to recompile everything against that version, and it’s not possible for me to maintain an entire distro, nor is what i want to do.

If the project is about providing a lightweight overlay to debian, with the few packages this distro miss, i really have to use the most that already stay here.

So, if i say “the wine currently in etch (0.9.25-2.1)” i mean this:

oggei@rtfm:~$ LANG=C apt-cache policy wine
wine:
Installed: 0.9.25-2.1
Candidate: 1.0.0-1
Version table:
1.1.5-1 0
1 http://ftp.it.debian.org experimental/main Packages
1.0.0-1 0
500 http://ftp.it.debian.org testing/main Packages
500 http://ftp.it.debian.org unstable/main Packages
*** 0.9.25-2.1 0
500 http://ftp.it.debian.org stable/main Packages
100 /var/lib/dpkg/status

any other way is a no-no, it’s already plenty of version mixes and other trashware around, i don’t want to enrich this sad panorama :slight_smile:

so the way will be enhancing either ardour or wine for having the two cohoperate nicely on window composing.

Ciao,

ale

#5

Ooops,

What I meant was, if you built Ardour with a newer version of Wine…then found the Window problem…then uninstalled both wine-dev and wine and replaced them with an older but aligned version of Wine and Wine-dev it doesn’t matter that you built ArdourVST in the first place with a more recent version.

I hope that makes more sense, I didn’t ever mean to say the wine-dev and wine versions were not aligned. sorry about the misunderstanding…my fault.

One more thing I might mention…MEPIS Linux is soon to release a Lenny based MEPIS 8.0, MEPIS is traditionally a very stable Distro, however in the past hasn’t had access to an RT kernel. I’m sure MEPIS users would be very interested in your repo as well.

#6

Glen, that isn’t matter of good order’s sake or wiseness: you have to keep binary and -dev packages aligned, unless you know very well what you are doing, trust me, this things breaks distros.

So, i’m rebuilding the whole using the wine currently in etch (0.9.25-2.1), just for checking if this bug still shows up (to me).

A problem will eventually arise: if i decide to put a backported wine package in my package tree, either i build it for using separate locations, or i maintain every single package someone would want, it’s a big fat PITA for me :stuck_out_tongue:

so i’ll probably try to track this problem and produce a fix, maybe the problem is in ardour’s vst part uh, don’t know :slight_smile:

i’ll post news ASAP, cheers

ale

#7

GMaq,

thanks for your useful feedback, i’ll begin telling you that i’m translating every page i already published, i hope my english isn’t too “maccarone” but eventually i will fix searching some better speaking volunteer :stuck_out_tongue:

For wine problem: i’m able to easily reproduce it, so i’ll try to compile ardour against wine currently in etch (0.9.25-2.1) … obviously this is a temporary workaround as i can’t for sure afford to maintain a whole wine distro under my repository, and in general with wine “newer is better” so i really hope someone skilled on it can find a correct way to do this with 1.0 (maybe contributing patches to upstream, or finding obscure registry/config combos).
I’ll try to maintain updated infos about that on my site.

For realtime kernels, i’m working on it, setting up a decent image factory isn’t trivial for lot of reasons, anyway stay tuned because this will be my next move.

Cheers,

ale

#8

ale,

Thanks for your investigations,

I agree figuring out the complexities of a functioning ArdourVST is truly a “monster”

If you don’t mind me suggesting I think Wine 0.9.49 and Wine-dev 0.9.49 from Debian Stable should work. Wine 0.9.25 is quite old that is probably part of the reason that you’re seeing such instability.

I know from experience what works with Ubuntu Gutsy, It would be nice to find out what works on Debian Lenny and then possibly other distros.

I think your idea is still worth attention, unfortunately people who are interested in ArdourVST right now are not going to be able to use a WINE of their choice, that’s just part of the rules of the game just like they aren’t going to be able to use every VST plugin they want.

Here is a screenshot from my website with Ardour 2.5/VST using Ubuntu Gutsy and Wine 0.9.49, as you can see the Windows are working properly with Gnome, and this setup worked so well I downgraded from Hardy back to Gutsy. I plan on trying it with LXDE as well.

http://www.bandshed.net/images/Ardour2.5VSTFULL.png

As you probably know, ArdourVST uses “fst” to run the VST plugins, Paul Davis, the lead developer of Ardour co-wrote fst and has not continued with it’s development for quite some time, I believe he moved on to a 64bit platform for development. The stopped development in fst is probably at least part of why ArdourVST isn’t able to use recent builds of Wine.

However with the appearance of “Vestige” header from LMMS, I’m truly surprised their hasn’t been a renewed interest in VST support but there isn’t so far.

#9

ale,

I thought I should clarify this,

While I agree with you that newer Wine versions are better, ArdourVST is a small and isolated case where this is not so. I would be surprised if the Wine developers would even pay attention to such a “small” issue.

You can build ArdourVST with pretty much any version of wine-dev, the build version is not as important as the “runtime” version. Of course it is probably wise to use the same version for both.

I personally have tested Wine 0.9.49 and 0.9.50, (0.9.49 works perfectly however if people also wish to compile DSSI-VST 0.7 they will require Wine 0.9.50 or greater) they work fine even on ArdourVST built with Wine 1.0. As soon as Ardour 2.6 is released I am going to try it with Wine 0.9.52. In past testing I discovered that Wine 0.9.55 and up don’t work.

The archives at www.winehq.org have archived binaries for Ubuntu and Debian Etch here:
http://wine.budgetdedicated.com/archive/index.html

You have to scroll down the page for the Debian Etch Binaries.

Thanks for the translations in progress, No matter what your English will be far better than my “Maccarone”

Regards -GLEN

#10

Glen, there is one debian stable version of wine: the one contained in debian stable. I already tried to explain you how and why other versions aren’t a possible choice.

This is not an effort directed towards your personal system, but a general contribution to community, so basicly i will not fix for your personal setup :slight_smile:

ciao,
ale

#11

oggei,

What a great idea, especially for Lenny, Sid is pretty volatile for audio stuff unless you are a hardcore Debian user and know what you’re doing.

One issue that is really a problem for ArdourVST now is current WINE versions, It used to be that if WINE caused double windows (ie the plugin wrapper window with “bypass/active” and the actual plugin GUI were displayed separately) that changing the “allow window manager to control windows” in Wine config would fix it, however since about WINE 0.9.52 this cannot be fixed by any method I know.

I have set up ArdourVST in two separate Ubuntu Hardy installations with WINE 1.0 and haven’t been able to fix this problem. I’ve tried building older versions of Wine from source but they seem unstable and don’t integrate into the system as nicely as the binaries do. Also Ubuntu Gutsy Wine binaries which work properly are not installable in Hardy and I’m sure Intrepid will be no better.

If during a session you close either the separate plugin GUI Window or the “wrapper” it will not re-appear unless you quit and re-open the session. This is an extra PITA and ArdourVST doesn’t need any more inconveniences than it already has!

About a week ago I tried Sidux, they have a Community RT Kernel that is not even functional with JACK right now. I wanted to try Lenny but didn’t know that an RT kernel was available until I read your post.

Would you be willing or interested in building a custom version of Wine for your repo? Or perhaps Wine 0.9.49 - 0.9.52 for Debian Etch would work. I would be willing to test this, and also contribute a list of VST plugins known to work well within ArdourVST if that would be helpful.

For now I have gone back to Ubuntu Gutsy because I can build a really stable ArdourVST in it with my eyes closed. However Ubuntu will be dropping support for it very soon, and I haven’t liked what I see with Hardy as an audio distro so far. I am really interested in trying your Lenny setup out though… thanks for all your efforts in this and sharing it on the forum.

I will tell you that the Ardour devs for all their hard work and patience with “we the users”, generally regard ArdourVST as a bastard stepchild that lives in an attic!

#ardour on IRC gets pretty quiet when you bring up ArdourVST (LOL)

EDIT
I checked out your repos, great work, I was wondering if the Debian Realtime page could have an English version like the Ardour page as well.

Thanks again!