| If after your changes I can still build and run CsoundVST with its Python
interface to Loris, and you can build and use the Loris opcodes without
CsoundVST but with an externally built version of Loris, that sounds good
-- more people should be able to use Loris then.
Original Message:
-----------------
From: steven yi stevenyi@csounds.com
Date: Thu, 23 Sep 2004 11:43:29 -0700
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:5353] RE: Loris Opcodes
gogins@pipeline.com wrote:
> On Windows, the Loris dll is prebuilt or can be built with scons from
> sources; on Linux, you build Loris with its standard ./configure etc. and
> it links with the Csound opcode.
Yes, this is exactly my point. I have the library built and installed
already. I have the loris.h header installed in either /usr/include or
/usr/local/include (I'm not at my home computer to check). I still do
not understand why the configure check is:
configure.CheckHeader("Opcodes/Loris/src/loris.h")
and not:
configure.CheckHeader("loris.h")
which would then pass on my computer at home and is the way it seems it
should be set to me.
Ah... Okay, I finally found out why you require the files to be there
(it wasn't in the Opcodes/Loris/README, but was in the SConstruct file,
which I should have consulted first). It seems that this is a somewhat
forced way to do static compiling of the library. I have something to
propose in the area below...
> My attitude about standalone analysis programs is different from yours.
> This is just a matter of taste and working style.
>
> To me, it makes sense to do all Csound work in Python now, this enables
the
> analysis steps to be in the same one Python file as the rest of a
> composition, including the Csound orchestra itself. Then when I come back
> to a piece in 5 years because it needs to be at 192 KHz or in 5.l or
> something, I don't find its parts scattered to the winds.
>
> Keeping the Python interface to Loris does not impede using the standalone
> programs, but removing it would definitely affect the way I and perhaps
> some others work.
>
Okay, after taking a look through the SConstruct file, I think I can
understand where I got confused in how this is all working. However,
I'd like to propose making the following changes:
-be able to build the Loris Opcodes on their own without Python and
without depending on CsoundVST (so, will be built as part of main csound
compile if loris and fftw libs exist)
-build a second python library that will wrap the utilities and have all
of the functionality as you have it currently accessible within how you
have it, to be packaged with CsoundVST
-have neither require loris sources be put into the Opcodes/Loris/src
directory, and rather rely on that the user has the Loris library built
and headers installed in standard locations (i.e. /usr/local/include,
/usr/local/lib on *nix system; Windows users would have to put wherever
they put their other libraries)
-have these libraries built dynamically-linked and require end user to
have loris library installed if they want to use it (in the same way
portaudio.dll and libsndfile.dll are required for use). If the end user
doesn't install the loris library, then they simply won't be able to use
the loris opcodes.
This seems to answer both our issues. I'd like to be able to compile
and build the loris opcodes without depending on CsoundVST, which I do
not currently use or compile(I have no need for VST and the things I do
with python don't usually cross into the compositional space which you
are exploring). I think it wouldn't take me too long to make this
change, though I could be wrong and may be more complicated than I
imagine. If I can achieve the above, would that satisfy your
requirements, or am I missing something else as well?
Thanks,
steven
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ . |