<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:602569818;
        mso-list-type:hybrid;
        mso-list-template-ids:-602098706 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>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:<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>      
</span></span><![endif]> 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.<o:p></o:p></p>

<p class=MsoListParagraph><o:p> </o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>      
</span></span><![endif]>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.<o:p></o:p></p>

<p class=MsoListParagraph><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>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. <o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>      
</span></span><![endif]>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.<o:p></o:p></p>

<p class=MsoListParagraph><o:p> </o:p></p>

<p class=MsoListParagraph>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.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>-Mike Mazarick<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'><a
href="mailto:mazarick@bellsouth.net">mazarick@bellsouth.net</a><o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

</body>

</html>