[Ardour-Dev] Need a 32 bit Ardour (with VSTs) on an x86_64 linux system

[Paul Davis]

On Sun, 2008-11-30 at 23:19 -0500, Mike Mazarick wrote:

> As I mentioned, I am by no means 'married' to a VST solution, but even a
> casual glance at what is available with VSTs shows that it should be pretty
> easy to implement a different 'sample delay' per virtual source and add
> several of virtual sources back into Ardour, particularly if you could use
> Ardour as the VST host.

You can! The issue is whether you really want to deal with what is
involved.

> My comments on VSTs and Paul's resulting reply on VSTs viability inside of
> Ardour was pretty clear on the utility of this direction (along with the
> lack of "I've tried it and it works great" testimonials). 

Many people who use ardour use VST plugins. I don't know precisely what
you read in my words that described the "viability" of VSTs inside
Ardour. My comments were about how much of a pain it is to set up, and
how from time it will break as things change in wine or other parts of
your system. I don't consider that an experience of Ardour that is
really worth advertising. Others would say differently - I know quite a
few people who very much enjoy various VST plugins in combination with
Ardour.

>   I've already
> spent enough time in 'dependency hell' to take Paul's words of caution
> seriously (but, we all know compiling two target objects from the same
> source is difficult but not impossible, particularly on Fedora).

Ardour and JACK are not your average applications. They both contain
hand-written assembler, and the selection and building of this code is
(at least in part) based on identifying the CPU capabilities of the
build host. This can't be done with the compiler, so gcc flags like -m32
won't work - the build system wants a *lot* more information about the
processor than whether its 32 or 64 bit. As I mentioned, with Ardour,
the ARCH scons option is there to completely override any build-system
generated compiler flags, but its been a while since I or anyone I know
used it, so it may be slightly borked at this point.

>   Here are
> the particular VSTs I was looking at implementing on a Ardour VST host:
> http://acousmodules.free.fr/acousmodules4_en.htm
> http://www.kvraudio.com/news/8247.html
> http://www.audioease.com/Pages/RocketScience/OrbitMain.html
> 
> Outside of these particular VSTs (or ones that work in a very similar
> fashion), I don't have a lot of interest in VSTs.  However, since it would
> do this community a lot of good to embrace them (IMHO),

I don't want to get caught up in an attitude war but ... its one thing
(and very appropriate IMHO) to note that the linux audio community
hasn't been able to produce a lot of very high quality and sophisticated
audio plugins that compare to proprietary offerings. There are lots of
reasons why this is the case (some might even disagree with it).

But its something else when the suggested solution to this problem is
that we make plugins *WRITTEN FOR ANOTHER OPERATING SYSTEM* work without
modification. On the other hand, we actually *did* do this! Its just
that I want to be open and forthwright about how well it actually works,
and not give people false ideas regarding its ability to provide a
seamless transition from a win32 DAW.

I'd *love* to embrace VST *authors* and their *code* and their *ideas*.
Embracing their win32 API-filled binary blobs is quite different, and
puts a burden on us (specifically, on Ardour as a host) that is way, way
beyond what is generally meant by "hosting VSTs". 

For a comparable example in the windows world, ask Cakewalk why they
don't support AudioUnits. After all, most of them are written for Intel
now, so the processor is the same. I mean, come on, how hard could it
be?

--p