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.

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.

Original Message:
-----------------
From: steven yi stevenyi@csounds.com
Date: Thu, 23 Sep 2004 09:44:34 -0700
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:5351] RE: Loris Opcodes


Hi Michael,

gogins@pipeline.com wrote:

>Yes to both. loris.h is for the Loris opcodes, not loris as such, which I
>have customized for Csound 5 (the original source is for 4.23). 
>  
>

I have no Opcodes/Loris/src folder so I'm assuming you have it set up 
such that you need to copy the whole Loris src folder into the 
Opcodes/Loris directory, yes?   I've built the loris opcodes before for 
4.23 and at that time I simply linked with the compiled library and it 
had worked fine for me then.  I guess I don't understand what you're 
saying here.

>We need the Python stuff if we want to actually use Loris, since the Csound
>opcodes are only for resynthesis, not for analysis. The Python stuff
>provides a quite usable interface to the analysis features of Loris.
>  
>
Loris (1.2.0 at least) comes with a stand-alone executable, 
loris_analyze.  It gets built in the loris/utils directory.  Any reason 
we can't assume the end user has access to that?  If loris is to be used 
in the same way as the other analysis/resynthesis tools in csound, it 
makes sense to me to use the commandline tool rather than to require to 
write a python script. 

steven


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

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