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

[Mike Mazarick]

I've been searching for a clean way to compile the source and install a 32
bit binary/libraries for 2.7 Ardour on my 64 bit Fedora CCRMA system, and
also to be able to use some native VSTs packaged for Windows (which implies
why the Ardour app needs to be 32 bits to host 32 bit VSTs).    What I am
seeing is:

 

1.        I've seen lots of warnings to always use rpm's (or apt-get or
emerge) and NEVER build from source using downloaded tarballs.   Tough luck
- I'm already doing it.   I can see the wisdom of having some way of
packaging what you are installing back into an rpm (or similar package), but
when you are installing off of the 'bleeding edge' to get new functionality,
packaging it all back into an rpm isn't always practical during the
'discovery' process (until after you've discovered something).   Maybe when
I'm done figuring out what I really need, there will be time for this.   I'm
bringing this up so that someone else doesn't have to figure it out the hard
way that once you've gone down the 'rpm'  path (or 'apt-get' or 'emerge'),
there is a downside to compiling from source tarballs because you lose
control over your system.   You probably shouldn't diverge from this path
without deciding to, and you will always be a certain distance away from the
'bleeding edge'.   I've decided to diverge from the path of 'safety' and
head towards the 'bleeding edge' so that I can get some important functions
to work for me.

 

2.       I haven't seen a clear description anywhere on how to reliably
build a source package with the "./configure, make, make install" stanza and
have it build a 32 bit version with all the binaries and libraries put in
the right place.   Being able to do it as mindlessly as possible is the best
method for me.  Right now, I'm only concerned with Ardour, but next week I
may want to look at another 32 bit app and will want to apply the same basic
'rules' without investigating the code at all.   I would imagine that I'll
need to use a "DIST_TARGET=i386" or similar during the scons or configure
stage to get 32 bit binaries and libraries, but I'm not sure of the best way
to tell the linker/loader to put the 32 bit libraries in the 32 bit library
directories (which is appropriate for Fedora), or whether it is better to go
thru some compatibility library or chroot system (which may be more
appropriate for Ubantu or Debian).   Remember, 'mindless' is good,
'thinking/investigating' is bad.

 

Any words of advice on what gory details that are required to accomplish
what I am setting out to do would be really appreciated.   As a side note, I
will in general be more interested in the x86_64 bit versions of Ardour
and/or Jack (for my more general needs as a musician), but I'll need to get
the VSTs working somehow for the more elaborate 'experiment'/demo that I am
doing. 

 

3.       Why are VSTs suddenly so important to me?   I'll leave aside
comments about their general usefulness and pervasiveness for the time
being.   I'm building a 'home version' of a Wave Field Synthesis system with
32 channels.   I've found some VSTs (32 bit Windows VSTs to be exact) could
do the job of helping me mix/master a regular ProTools/Cubase/Ardour
recording into something suitable for WFS as a small 'software component' in
the toolchain.   It will save me the time/trouble of inventing a different
solution or investigating a lot of different options for the 'demo' system.
If you want to see where SOAP is headed, (or any other Object Oriented
methodology), investigating the strengths and shortcomings of VSTs is a
pretty good model.

 

Getting a WFS mix works by applying a separate delay (and maybe a separate
volume) for each sound source to each speaker/channel according to each
source's 'virtual position'.   Applying the different delays to a lot of
different speakers is actually what establishes the 'virtual position'.
I'm planning on using regular linux audio tools to do the mixing/mastering,
but I'll eventually need to 'recompute' everything back into a customized 32
channel (or 64 channel) 'mix'.    The speaker placement will become a
subject of experiment before it becomes 'fixed', so I'll need to vary this
delay per channel by a different value according to where the speaker is
placed.   I'll also need to have the ability to add many different sources
(each with a different delay) to each speaker and produce a new 'remix' with
a new speaker placement.

 

I find it very interesting that you guys are on the same wavelength with the
Wiimote, because eventually I'd like to have the ability to move 'virtual'
sources around with a Wiimote to new locations, but this is for later.   The
WiiMote is the 3D equivalent to a mouse.   It's probably a slightly
different use than using it as a midi generator with Bluetooth (control
surface), but the hooks needed into Ardour are basically the same.  The 'low
rent' way to accomplish using the WiiMote is compute a lot of different
sound mixes, but leave one sound source out of the mix (which can then be
selected and moved) and add it in separately when a particular source is
selected (each mix of 32 channels would need to be computed separately,
leaving out the one source 'free to move').   The only issue would be
playing back all the mixes at the same time and being able to 'select' a mix
according to which particular source was selected.   It would need to be
able to 'switch over' to a different set of mixes inaudibly.

 

If someone else is interested in working with me, learning more about it, or
otherwise discussing it, please feel free to drop me a note.   I will try
not to tie up the Ardour message board with things that only pertain to WFS.
There is absolutely no funding or money in this right now, but it is now a
feasibility for the first time and it is interesting to 'play' where others
can't go or haven't gone.   You won't get many bux from this, but you might
have a lot of fun.

 

-Mike Mazarick

mazarick at bellsouth.net

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20081130/04a0e403/attachment-0002.htm>