sdif-devel — Developer list: discussion of programming the SDIF library and tools that use it

Re: [sdif-devel] how to write '1TYP' frame header in sdif-file with gabarit form ?

[Diemo S. <Die...@ir...>]

Hi Jean,

didn't you try with SdifFGetAllTypefromSdifString?

								...Diemo


Jean Holleville wrote:
> hello,
> 
> I'm trying to write a gabarit (-OS4 supervp option) sdif file by hand 
> (C, Xcode);
> but I get no information in my sdif file.
> 
> here are the C subroutines I use :
> 
>  
>    
> 
> that I call in this order :
> 
> #define    SDIF_SEQC_PREDEFINED_TYPES_FILE    "./SdifTypes.STYP"
> 
>     Sdif_SeqC_Init_Gen(SDIF_SEQC_PREDEFINED_TYPES_FILE);
>     creer_ouvrir_fichiers_FFT_OUT_SDIF(nb_fic_synZEF);
> 
>     pad_and_close_sdif_file(fpOut_Sdif_AetB_FFT);
>     SdifGenKill();
> 
> when I run, I get  that stdout debugging :
> 
> 
> 
> 
> and with the following shell command  :
> 
> Pwb-jh:data/sdif/out->querysdif -a DR0_vl-DR0_vla.AetB.FFT_OUT.sdif ; 
> querysdif -d DR0_vl-DR0_vla.AetB.FFT_OUT.sdif ; sdiftotext -i 
> DR0_vl-DR0_vla.AetB.FFT_OUT.sdif -o DR0_vl-DR0_vla.AetB.FFT_OUT.sdif.txt 
> ; more DR0_vl-DR0_vla.AetB.FFT_OUT.sdif.txt
> 
>  I get that :
> 
> 
> *Sdif* erreur size 1NVT: lu: 368  Attendu: 184
> 
> Ascii chunks of file DR0_vl-DR0_vla.AetB.FFT_OUT.sdif:
> 
> SDIF
> 
> 1NVT
> {
> SampleRate    44100.000000;
> SoundFiles    ./data/sdif/out/DR0_vl-DR0_vla.AetB.FFT_OUT.sdif;
> GabaritMode    4;
> Date        Tue Jan 26 14:52:20 CET 2010;
> TableName    FFT;
> 
> softWare    SeqC Version    0.4.1;
> Written by    jh;
> 
> Command        commande ...;
> NumChannels    1;
> Version        version : 2.95.23 (compiled by roebel  on Nov 28 2008 
> 13:22:41 ) Prec=Float;
> Creator        SuperVP;
> }
> 
> 
> *Sdif* erreur size 1NVT: lu: 368  Attendu: 184
> 
> Data in file DR0_vl-DR0_vla.AetB.FFT_OUT.sdif (440 bytes):
> 
> *Sdif* erreur size 1NVT: lu: 368  Attendu: 184
> 
>              440 bytes have been read from 
> "DR0_vl-DR0_vla.AetB.FFT_OUT.sdif".
> SDIF
> 
> 1NVT
> {
> SampleRate      44100.000000;
> SoundFiles      ./data/sdif/out/DR0_vl-DR0_vla.AetB.FFT_OUT.sdif;
> GabaritMode     4;
> Date            Tue Jan 26 14:52:20 CET 2010;
> TableName       FFT;
> 
> softWare        SeqC Version    0.4.1;
> Written by      jh;
> 
> Command         commande ...;
> NumChannels     1;
> Version         version : 2.95.23 (compiled by roebel  on Nov 28 2008 
> 13:22:41 ) Prec=Float;
> Creator         SuperVP;
> }
> 
> ENDF
> Pwb-jh:data/sdif/out->
> 
> 
> 
> 
> and no 1TYP frame written in the sdif file.
> 
> could you help me to write this 1TYP frame header, please ?
> 
> regards.
> jean
> 
> 
> 
> 
> Jean Holleville
> Conservatoire national supérieur musique et danse de Lyon
> Département de composition
> Sonvs
> 3 quai Chauveau
> CP 120
> F-69266 Lyon Cedex 09
> 
> tél        33 (0)472 19 26 29
> fax       33 (0)472 19 26 00
> Courriel  jean point holleville at cnsmd-lyon.fr
> 

-- 
Diemo Schwarz, PhD -- http://diemo.concatenative.net
Real-Time Music Interaction Team -- http://imtr.ircam.fr
IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
Phone +33-1-4478-4879 -- Fax +33-1-4478-1540

[sdif-devel] how to write '1TYP' frame header in sdif-file with gabarit form ?

[Jean H. <jea...@cn...>]

hello,

I'm trying to write a gabarit (-OS4 supervp option) sdif file by hand  
(C, Xcode);
but I get no information in my sdif file.

here are the C subroutines I use :

Re: [sdif-devel] easdif - audiosculpt python wrapper. modification to sdif_matrix.cpp

[edu <mog...@gm...>]

I cannot reproduce the segfaults with that you report
>  with the latest Easdif (version 1.3.1)
> which you find in cvs and with swig 1.3.31. Both methods work
> perfectly for me under linux and the sample script test.py
> that you can find in the swig/python directory.
>
> What os are you working with?
>
Hi. I'm using linux->debian/sid, Easdif 1.3.0, using SWIG 1.3.31. I will 
try 1.3.31 and see if I still get the segfaults. I can confirm that the 
problem is from SWIG because accessing directly the library with 
python/ctypes works ok.

>
> > Also, in order to read the matrix more efficiently in python, I
>
> > implemented small helper functions in sdif_matrix.cpp to read a whole
>
> >  matrix into a python array..
>
> what would that look like? If it could be of general use I
> could put it into the official source.
>
Here are the extra functions to access matrices either as a whole or the 
rows/cols.
The caller is responsible for allocating and deallocating the array. On 
the python side, the arrays are actually numpy arrays of the desired 
type (no need to deallocate anything). The caller is also responsible 
for sending an array of the right size.
In the SWIG interface file this should be implemented to use numpy 
arrays (not normal lists, which is what SWIG does by default). I found 
it a bit troublesome to get the typemaps work correctly in SWIG and on 
the profiling I did, the ctypes module in python is in fact more 
efficient than SWIG, but of course it would be more elegant  to have all 
done with SWIG, as it is much easier to maintain.

The python module sdiflib is a wrapper on eaSDIF to make it still easier 
to read / write sdifs. Insbesondere it uses a double implementation 
which allows to iterate through the data as:

import sdiflib
entity = sdiflib.Entity('mysdif.sdif' [,selection=':1TRC/1TRC'])
for frame in entity:
    for matrix in frame:
        data = matrix()
        # data is now a numpy array holding the whole matrix
    
       

or

for frame in entity:
    matrix = frame[0]
    # do something with matrix

and also
entity(t, y) -> returns an interpolation of matrix at y of the frames 
before and after t
This is only useful if wanting to access a specific part of the data.

matrices having the same size are buffered on the python side so for 
sdifs like 1GB0 allocation is done only once. The caller is responsible 
to copy the data if needed.

here are the added functions (only interface code actually):

extern "C"
void
Matrix_GetRow_double(Easdif::SDIFMatrix* matrix, int irow, double* out)
{
    matrix->mInter->GetRow(&(out[0]), irow);
}

extern "C"
void
Matrix_GetCol_double(Easdif::SDIFMatrix* matrix, int icol, double* out)
{
    matrix->mInter->GetCol(&(out[0]), icol);
}
   
extern "C"
void
Matrix_GetRows_double(Easdif::SDIFMatrix* matrix, int row0, int row1, 
double* out)
{
    for (int row = row0; row < row1; row++) {
        matrix->mInter->GetRow(&(out[row]), row);
    }
}

extern "C"
void
Matrix_GetRow_int(Easdif::SDIFMatrix* matrix, int irow, int*  out)
{
    matrix->mInter->GetRow(&(out[0]), irow);
}

extern "C"
void
Matrix_GetCol_int(Easdif::SDIFMatrix * matrix, int icol, int * out)
{
    matrix->mInter->GetCol(&(out[0]), icol);
}

extern "C"
void
Matrix_GetRows_int(Easdif::SDIFMatrix * matrix, int row0, int row1, int 
* out)
{
    for (int row = row0; row < row1; row++) {
        matrix->mInter->GetRow(&(out[row]), row);
    }
}

extern "C"
void
Matrix_GetRow_float(Easdif::SDIFMatrix * matrix, int irow, float * out)
{
    matrix->mInter->GetRow(&(out[0]), irow);
}


extern "C"
void
Matrix_GetCol_float(Easdif::SDIFMatrix * matrix, int icol, float * out)
{
    matrix->mInter->GetCol(&(out[0]), icol);
}


extern "C"
void
Matrix_GetRows_float(Easdif::SDIFMatrix * matrix, int row0, int row1, 
float * out)
{
    for (int row = row0; row < row1; row++) {
        matrix->mInter->GetRow(&(out[row]), row);
    }
}


extern "C"
int
Matrix_GetNbRows(Easdif::SDIFMatrix * matrix)
{
    return matrix->GetNbRows();
}

extern "C"
int
Matrix_GetNbCols(Easdif::SDIFMatrix * matrix)
{
    return matrix->GetNbCols();
}

extern "C"
void
Matrix_SetRows_double(Easdif::SDIFMatrix * matrix, double * in, int nrows)
{
    int num_cols = matrix->GetNbCols();
    for (int row = 0; row < nrows; row++) {
        matrix->mInter->SetRow(&(in[row * num_cols]),row);
    }
}

extern "C"
void
Matrix_SetRows_float(Easdif::SDIFMatrix * matrix, float * in, int nrows)
{
    int num_cols = matrix->GetNbCols();
    for (int row = 0; row < nrows; row++) {
        matrix->mInter->SetRow(&(in[row * num_cols]),row);
    }
}

extern "C"
void
Matrix_SetRows_int(Easdif::SDIFMatrix * matrix, int * in, int nrows)
{
    int num_cols = matrix->GetNbCols();
    for (int row = 0; row < nrows; row++) {
        matrix->mInter->SetRow(&(in[row * num_cols]),row);
    }
}


extern "C"
void
Matrix_SetRow_int(Easdif::SDIFMatrix * matrix, int irow, int * in)
{
    matrix->mInter->SetRow(&(in[0]), irow);
}


extern "C"
void
Matrix_SetRow_float(Easdif::SDIFMatrix * matrix, int irow, float * in)
{
    matrix->mInter->SetRow(&(in[0]), irow);
}

extern "C"
void
Matrix_SetRow_double(Easdif::SDIFMatrix * matrix, int irow, double * in)
{
    matrix->mInter->SetRow(&(in[0]), irow);
}

Re: [sdif-devel] easdif - audiosculpt python wrapper. modification to sdif_matrix.cpp

[Axel R. <Axe...@ir...>]

On Saturday 07 July 2007, edu wrote:
> hi.
> for personal use i implemented a wrapper to wrap the python bindings of
> Easdif. While doing that I noticed some problems with the SWIG bindings,
> which are independent of the SWIG version (I tried ALL of them):
> Matrix.GetNbRows and Matrix.GetNbCols result always in segfaults.

Hello Eduardo,


I am happy to see that you have been making such nice use of
the Easdif library.

I cannot reproduce the segfaults with that you report
 with the latest Easdif (version 1.3.1)
which you find in cvs and with swig 1.3.31. Both methods work
perfectly for me under linux and the sample script test.py
that you can find in the swig/python directory.

What os are you working with?


> Also, in order to read the matrix more efficiently in python, I
> implemented small helper functions in sdif_matrix.cpp to read a whole
> matrix into a python array..

what would that look like? If it could be of general use I
could put it into the official source.

> This changes are not reflected in the SWIG bindings: since these
> functions are used for interfacing with numpy arrays (c arrays in
> python),  I access the shared library directly from python and map the
> data to the python arrays.



> In this way, you can do, in python:
>
> from sdiflib import *
> entity = Entity('my_sdif_file.sdif', selection=':1GB1/1GB1')  #
> selection is optional
> for frame in entity:
>     for matrix in frame:
>         print matrix()[0:100]  # will print the first 100 rows in all
> the matrices
>
> given that the sdif has matrices of constant size, the reading is
> buffered and you can do interpolation without reading everything first
> into memory. (not possible with partial tracking, still)
>
> entity = Entity('my_very_big_spectral_envelope.sdif',
> selection=':1GB1/1GB1')
> print entity(10.5, 300)
>
> will print the value of the spectral envelope at time=10.5 secs at
> frequency 300Hz. Values are interpolated linearly by default.
>
> Based on this library, I made a python module to talk to supervp and
> pm2. At the moment some features are still not implemented (gabarit
> filter, surface filter) but besides that, everything seems to work quite
> good. This library works both in OSX and Linux. It also integrates
> audiosculpt's kernels with libraries like Loris and aubio.
>
> you can do things like:
>
> from audiosculpt import *
> sp = SpectralEnvelope(An('source.aiff', ws=4000), order=30)
> sp.plot3d()  # will plot a 3d image of sp
> print sp(10.5, 300)  # print the value at time=10.5sec, freq=300Hz
> sp *= 0.5 # scale all the values
> sp.write('out.sdif') # write the new results
>
>
> even more, you can do:
>
> sp0 = SpectralEnvelope(An('source.aiff', ws=4000), order=30)
> sp1 =SpectralEnvelope(An('source.aiff', ws=4000), order=2000)
> interpolation_bpf = bpf.HalfCos((0,0), (10, 1))
> interpolated_envelope = sp0 * interpolation_bpf + sp1 * (1 -
> interpolation_bpf)
>
> out = FilterBreakpnt(An('white_noise.aiff', ws=4000),
> interpolated_envelope) # this will call supervp to produce a breakpoint
> filter calculated out of the
> # interpolation of the two spectral envelopes with the given shape
> (halfcos interpolation
> # in 10 seconds). This could of course  be done
> # quite easily with envscal filter, but this is just a very easy
> example.  Once gabarit
> # filter is supported, it will be much more efficient, of course.
>
> mask = MaskingEffect(An('source.aiff', ws=4000))
>
> print mask(1, 300)   # print the weight of the spectrum at time=1sec,
> freq=300Hz
> mask.plot()     # plot the results as a surface plot
> out = FilterBreakpnt(An('white_noise.aiff', ws=4000), sp * mask)
> # will filter the  white noise file only at the places where
> # the source file has relevant spectral information
> # (otherwise weight=0 --> result = 0)
>
>
> if someone is interested, I can post the sources.
>
> cheers,
>
> Eduardo Moguillansky
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sdif-devel mailing list
> sdi...@li...
> https://lists.sourceforge.net/lists/listinfo/sdif-devel



-- 
Axel Roebel    
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540

[sdif-devel] easdif - audiosculpt python wrapper. modification to sdif_matrix.cpp

[edu <mog...@gm...>]

hi.
for personal use i implemented a wrapper to wrap the python bindings of 
Easdif. While doing that I noticed some problems with the SWIG bindings, 
which are independent of the SWIG version (I tried ALL of them):
Matrix.GetNbRows and Matrix.GetNbCols result always in segfaults.

Also, in order to read the matrix more efficiently in python, I 
implemented small helper functions in sdif_matrix.cpp to read a whole 
matrix into a python array..

This changes are not reflected in the SWIG bindings: since these 
functions are used for interfacing with numpy arrays (c arrays in 
python),  I access the shared library directly from python and map the 
data to the python arrays.

In this way, you can do, in python:

from sdiflib import *
entity = Entity('my_sdif_file.sdif', selection=':1GB1/1GB1')  # 
selection is optional
for frame in entity:
    for matrix in frame:
        print matrix()[0:100]  # will print the first 100 rows in all 
the matrices

given that the sdif has matrices of constant size, the reading is 
buffered and you can do interpolation without reading everything first 
into memory. (not possible with partial tracking, still)

entity = Entity('my_very_big_spectral_envelope.sdif', 
selection=':1GB1/1GB1')
print entity(10.5, 300)

will print the value of the spectral envelope at time=10.5 secs at 
frequency 300Hz. Values are interpolated linearly by default.

Based on this library, I made a python module to talk to supervp and 
pm2. At the moment some features are still not implemented (gabarit 
filter, surface filter) but besides that, everything seems to work quite 
good. This library works both in OSX and Linux. It also integrates 
audiosculpt's kernels with libraries like Loris and aubio.

you can do things like:

from audiosculpt import *
sp = SpectralEnvelope(An('source.aiff', ws=4000), order=30)
sp.plot3d()  # will plot a 3d image of sp
print sp(10.5, 300)  # print the value at time=10.5sec, freq=300Hz
sp *= 0.5 # scale all the values
sp.write('out.sdif') # write the new results


even more, you can do:

sp0 = SpectralEnvelope(An('source.aiff', ws=4000), order=30)
sp1 =SpectralEnvelope(An('source.aiff', ws=4000), order=2000)
interpolation_bpf = bpf.HalfCos((0,0), (10, 1))
interpolated_envelope = sp0 * interpolation_bpf + sp1 * (1 - 
interpolation_bpf)

out = FilterBreakpnt(An('white_noise.aiff', ws=4000), interpolated_envelope)
# this will call supervp to produce a breakpoint filter calculated out 
of the
# interpolation of the two spectral envelopes with the given shape 
(halfcos interpolation
# in 10 seconds). This could of course  be done
# quite easily with envscal filter, but this is just a very easy 
example.  Once gabarit
# filter is supported, it will be much more efficient, of course.

mask = MaskingEffect(An('source.aiff', ws=4000))

print mask(1, 300)   # print the weight of the spectrum at time=1sec, 
freq=300Hz
mask.plot()     # plot the results as a surface plot
out = FilterBreakpnt(An('white_noise.aiff', ws=4000), sp * mask)
# will filter the  white noise file only at the places where
# the source file has relevant spectral information
# (otherwise weight=0 --> result = 0)


if someone is interested, I can post the sources.

cheers,

Eduardo Moguillansky

Re: [sdif-devel] [Sdif-devel] Python sdif reader

[Axel R. <Axe...@ir...>]

On Sunday 22 October 2006 19:37, Eduardo Moguillansky wrote:
> so, here is a small example of the eaSDIF library in Python. This
> module reads many different types of sdif files and returns them in a
> way that makes sense. Also implemented is a parser to convert between
> 1TRC, RBEP (Loris) and the binary format from ATS (I don't include this
> yet, needs some testing). To be able to make the interaction more tight
> I would really appreciate having access to Pm2 for Linux since i'm now
> doing all the work there
> I also attach a revised version of the wrapper eaSDIF.py with most of
> the documentation in it, so you can use python's  clever pydoc.
> I have only one question. I don't get to see any function to access all
> the data in a Row at the same time, so a have to read element by
> element. this is not very effective. But there are actually many
> functions that are not totally usable in Python because of many pointer
> issues where there is no type conversion implemented. That might be the
> reason. for instance. in the documentation of eaSDIF there seems to be
> a function GetRow which is not wrapped.
>
> cheers, Eduardo

The  GetRow (and GetCol) function are templates.
If I compare with the basic Get function which is a template as well
I see that the template itself is not wrapped, but, the overloaded
version for float is.

So you may try to provide overloaded functions like

void GetRow(double* out,int irow) const throw (SDIFArrayPosition) {
    mInter->GetRow(out,irow);
    return;
  }

void GetCol(double* out,int irow) const throw (SDIFArrayPosition) { 
   mInter->GetCol(out,irow);
   return;
}

in sdif_matrix.hpp
These functions will be used instead of the template if the 
argument is a double pointer. For c++ this changes nothing, but, for
swig that may help to find a proper wrapping.

If this works we may put these overloads into the next library 
release to help swig.

As far as I understand we may even add these overloads
in a swig encapsulated section, so that these functions are 
visible for swig only. I don't work much with swig, so I don't 
know whether there is a swig macro name for such sections.

 

-- 
Axel Roebel    
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540

[Sdif-devel] Python sdif reader

[Eduardo M. <mog...@gm...>]

so, here is a small example of the eaSDIF library in Python. This 
module reads many different types of sdif files and returns them in a 
way that makes sense. Also implemented is a parser to convert between 
1TRC, RBEP (Loris) and the binary format from ATS (I don't include this 
yet, needs some testing). To be able to make the interaction more tight 
I would really appreciate having access to Pm2 for Linux since i'm now 
doing all the work there
I also attach a revised version of the wrapper eaSDIF.py with most of 
the documentation in it, so you can use python's  clever pydoc.
I have only one question. I don't get to see any function to access all 
the data in a Row at the same time, so a have to read element by 
element. this is not very effective. But there are actually many 
functions that are not totally usable in Python because of many pointer 
issues where there is no type conversion implemented. That might be the 
reason. for instance. in the documentation of eaSDIF there seems to be 
a function GetRow which is not wrapped.

cheers, Eduardo

Re: [Sdif-devel] eaSDIF - SWIG Python Bindings

[Axel R. <Axe...@ir...>]

On Thursday 19 October 2006 03:47, Eduardo Moguillansky wrote:
> dear Axel,
>
> ok, now I think I got it correct!!!!!  The building step, after getting
> the .o file should read
>
> g++ -Wl,-bind_at_load -flat_namespace -undefined suppress -o
> your_nice_library.so -bundle  your_wrapped_file.o
> your_original_library.dylib
>
> it works indeeeeeeeed!!!!!!!
>
> the final line, in this case, reads:
>
> g++ -Wl,-bind_at_load -flat_namespace -undefined suppress -o _eaSDIF.so
> -bundle  eaSDIF_wrap.o  ../../easdif/.libs/libEasdif-1.2.7.dylib
>
> a next step would be to include the documentation in the wrappers
> (through %feature), but it's good enough as it is.
>
> I spent some hours looking at the output of the build of the loris
> wrappers and tried almost all combinations of flags...

I never compiled these wrappers on macosx. Thanks to your=20
results I may update the makefiles for mac.=20
Currently I don't have time for that though, so I cc these=20
infos to the sdif-devel mailing list to take care of it later.

Note, that I tried the most recent
1.3.29. It works for python, but not for=20
perl and java!

Good luck for the next steps of your project,

Axel


> I hope you did not spend time reading the previous mail...
>
> cheers,
>
> Eduardo
>
> On Oct 18, 2006, at 12:59 AM, Axel Roebel wrote:
> > On Tuesday 17 October 2006 23:21, you wrote:
> >>> dear Axel,
> >>>
> >>> Now I can confirm that the problems with the wrappers in OSX are no=
t
> >>> due to g++ or gcc. I have tryed and installed 4.1 and it does not
> >>> change anything.
> >>>
> >>> Here are the errors:
> >>>
> >>> g++ : unrecognized option '-shared'
> >>> g++: ../../easdif/.libs/libEasdif.so:  No such file or directory
> >
> > That means that this swig version does not support
> > mac os x. -shared would then be something else
> >
> > you may look here
> > http://www.dabeaz.com/cgi-bin/wiki.pl?SwigFaqMaxOSXSharedLibraries
> >
> > TRy using the latest macosx version .
> > Either it works with easif or you may simply
> > copy the g++ commandlines to compile the
> > wrapper sourec file that you geenrate with swif 1.3.21.
> >
> > A bit hacky, but it may work.
> >
> >
> > Cheers,
> >
> > Axel
> >
> >>> in fact, -shared is not an option in OSX.
> >>>
> >>> The furthest I got was to be able to compile the wrapper
> >>> eaSDIF_wrap.cxx into eaSDIF_wrap.o
> >>> But then I don't know how to link it so that it generates the .so
> >>> files needed.
> >>>
> >>> I don't want to give up on OSX since it compiled so cleanly in Linu=
x!
> >>>
> >>> bets regards,
> >>>
> >>> Eduardo
> >>>
> >>> Begin forwarded message:
> >>>> From: Eduardo Moguillansky <mog...@gm...>
> >>>> Date: October 17, 2006 7:24:08 PM CEST
> >>>> To: Axel Roebel <Axe...@ir...>
> >>>> Subject: Re: [Sdif-devel] eaSDIF - SWIG Python Bindings
> >>>>
> >>>>> Why do you do disable shared.
> >>>>> The swig modules are shared libraries
> >>>>> you need to do
> >>>>>
> >>>>> ./configure
> >>>>>
> >>>>> only.
> >>>>
> >>>> I was trying to compile it in OSX 10.3.9, and it said in the readm=
e
> >>>> to disable sharing
> >>>>
> >>>> I just compiled it succesfully in Linux. I had to install SWIG
> >>>> 1.3.21.
> >>>> It gave many warnings but produced the .so files. One step is
> >>>> missing
> >>>> in the make install which would put the files where python can see
> >>>> them, but it can be done manually. Also when doing "make" on the
> >>>> swig
> >>>> directory in did not finish because the java modules throwed
> >>>> mistakes. so one must cd to python and then make.
> >>>>
> >>>> On OSX I have the following problem, which is the same as before. =
I
> >>>> did NOT use the --disable-shared flag for the first ./configure:
> >>>>
> >>>> g++ -shared ../../easdif/.libs/libEasdif.so eaSDIF_wrap.o -o
> >>>> _eaSDIF.so
> >>>> g++: ../../easdif/.libs/libEasdif.so: No such file or directory
> >>>> g++: unrecognized option `-shared'
> >>>>
> >>>> I supposed it coulb be  a problem with the gcc compiler so I
> >>>> installed the gcc 4.1
> >>>> thanks anyway.
> >>>>
> >>>> best regards, Eduardo
> >>>>
> >>>>>> works ok
> >>>>>> make
> >>>>>> works ok
> >>>>>> make install
> >>>>>> works ok
> >>>>>>
> >>>>>> then I do cd swig
> >>>>>> ./autogen.sh
> >>>>>> works fine
> >>>>>> ./configure
> >>>>>> works fine
> >>>>>> make
> >>>>>> attempts to build perl wrapper, many errors, stops
> >>>>>>
> >>>>>> then I did: cd python
> >>>>>> to build only python
> >>>>>> make
> >>>>>>
> >>>>>> it has following error:
> >>>>>>
> >>>>>> g++ -shared ../../easdif/.libs/libEasdif.so eaSDIF_wrap.o -o
> >>>>>> _eaSDIF.so
> >>>>>> g++: ../../easdif/.libs/libEasdif.so: No such file or directory
> >>>>>> g++: unrecognized option `-shared'
> >>>>>> make: *** [_eaSDIF.so] Error 1
> >>>>>
> >>>>> There are two errors here:
> >>>>>
> >>>>> First ../../easdif/.libs/libEasdif.so: No such file or directory
> >>>>> this one is easy. You did configure with disable-shared so you
> >>>>> don't get the shared library!
> >>>>>
> >>>>>> g++: unrecognized option `-shared'
> >>>>>
> >>>>> This one I don't understand, shared is a valid compiler option
> >>>>> on all linux systems that I know. It should work on macosx as wel=
l.
> >>>>> If your compiler is not able to compile shared
> >>>>> then you need to replace your compiler.
> >>>>>
> >>>>> What OS are you using and which compiler?
> >>>>>
> >>>>>> I'm terribly sorry to bother you with such a stupid question,
> >>>>>> since
> >>>>>> it's probably swig who is messing things up. should I give up?
> >>>>>
> >>>>> No you shouldn't!
> >>>>> This is not swig here.
> >>>>>
> >>>>> regards,
> >>>>>
> >>>>> Axel.
> >>>>>
> >>>>>> best regards, Eduardo
> >>>>>>
> >>>>>> On Oct 17, 2006, at 12:49 PM, Axel Roebel wrote:
> >>>>>>> On Tuesday 17 October 2006 11:46, Eduardo Moguillansky wrote:
> >>>>>>>> hi!
> >>>>>>>>
> >>>>>>>> I tried to compile the python bindings of eaSDIF but swig keep=
s
> >>>>>>>> reporting some errors. I tried it both in Linux (swig 1.3.24)
> >>>>>>>> and
> >>>>>>>> OSX
> >>>>>>>> (1.3.28). I was told that new versions of swig sometimes mess
> >>>>>>>> with c++
> >>>>>>>> but since I found two naming differences between the interface
> >>>>>>>> and the
> >>>>>>>> source files  I thought that maybe the interface files are not
> >>>>>>>> completely updated.
> >>>>>>>
> >>>>>>> I fixed the names in the swig interface files.
> >>>>>>> For me it now compiles cleanly with swig version 1.3.21,
> >>>>>>> I've tested all wrappers : perl, python and java.
> >>>>>>>
> >>>>>>> Let me know if you have success with a more recent
> >>>>>>> version of swig.
> >>>>>>>
> >>>>>>>> Only to try if swig was working fine I compiled the perl
> >>>>>>>> bindings
> >>>>>>>> and
> >>>>>>>> they work perfectly in both versions of swig.
> >>>>>>>>
> >>>>>>>> As told, sdif 1TRC can be read in python through the Loris
> >>>>>>>> wrappers,
> >>>>>>>> but
> >>>>>>>> it would be great to have access to all the other formats used
> >>>>>>>> by
> >>>>>>>> supervp without having to convert to text first.
> >>>>>>>>
> >>>>>>>> thanks!
> >>>>>>>>
> >>>>>>>> Eduardo Moguillansky
> >>>>>>>>
> >>>>>>>> On Tue, 2006-10-17 at 10:05 +0200, Diemo Schwarz wrote:
> >>>>>>>>> Dear Eduardo,
> >>>>>>>>>
> >>>>>>>>> I'm also forwarding this mail to the sdif-devel@sourceforge.n=
et
> >>>>>>>>> list
> >>>>>>>>> (subscribe at
> >>>>>>>>
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/sdif-devel),
> >>>>>>>>
> >>>>>>>>> where interesting development topics like these should go and
> >>>>>>>>> where
> >>>>>>>>
> >>>>>>>> Axel
> >>>>>>>>
> >>>>>>>>> can read them who wrote eaSDIF and the swig python bindings. =
 I
> >>>>>>>>
> >>>>>>>> started
> >>>>>>>>
> >>>>>>>>> all this swig thing, but only took care of the perl bindings.
> >>>>>>>>>
> >>>>>>>>> What version of swig are you using?
> >>>>>>>>>
> >>>>>>>>> Eduardo Moguillansky wrote:
> >>>>>>>>>> dear Diemo,
> >>>>>>>>>>
> >>>>>>>>>> thank you very much for the information. I did get the CVS
> >>>>>>>>>> files and
> >>>>>>>>>> found the python wrappers. They refuse to compile however.
> >>>>>>>>>> First 2
> >>>>>>>>
> >>>>>>>> files
> >>>>>>>>
> >>>>>>>>>> have changed name: sdifframe.hpp and sdifmatrix.hpp appear a=
s
> >>>>>>>>>> sdif_frame.hpp and sdif_matrix.hpp. That changed, it starts
> >>>>>>>>
> >>>>>>>> compiling
> >>>>>>>>
> >>>>>>>>>> but throws an error when trying to compile the wrapped file.=
 I
> >>>>>>>>
> >>>>>>>> wonder if
> >>>>>>>>
> >>>>>>>>>> some renaming has taken place since the interface files were
> >>>>>>>>>> done.
> >>>>>>>>>>
> >>>>>>>>>> I first compiled and installed easdif (and sdif) with no
> >>>>>>>>>> problems
> >>>>>>>>
> >>>>>>>> and
> >>>>>>>>
> >>>>>>>>>> they work fine.
> >>>>>>>>>>
> >>>>>>>>>> I did actually write a parser for 1TRC files from scratch ju=
st
> >>>>>>>>>> by
> >>>>>>>>>> following the specifications and reading the hex dumps.
> >>>>>>>>>> But for all the other formats, it seems at the moment more
> >>>>>>>>>> efficient
> >>>>>>>>
> >>>>>>>> to
> >>>>>>>>
> >>>>>>>>>> convert to text and write a small parser.
> >>>>>>>>>>
> >>>>>>>>>> The whole idea is to be able to provide a scripting layer
> >>>>>>>>>> which
> >>>>>>>>>> is
> >>>>>>>>>> common to some of the softwares working with spectral data
> >>>>>>>>>> -supervp
> >>>>>>>>
> >>>>>>>> and
> >>>>>>>>
> >>>>>>>>>> loris at the moment (I'm trying to make it work both for mac
> >>>>>>>>>> and
> >>>>>>>>
> >>>>>>>> linux,
> >>>>>>>>
> >>>>>>>>>> so it is a pity that Pm2 does not seem to have a Linux
> >>>>>>>>>> version),
> >>>>>>>>
> >>>>>>>> spear
> >>>>>>>>
> >>>>>>>>>> for fast visualization of partial tracking with loris and Pm=
2.
> >>>>>>>>>> In
> >>>>>>>>
> >>>>>>>> this
> >>>>>>>>
> >>>>>>>>>> way it is possible to choose the best tool for each task -to
> >>>>>>>>>> do
> >>>>>>>>>> morphing, for instance, it is very useful to resort to Loris=
,
> >>>>>>>>>> for
> >>>>>>>>>> cross-synthesis supervp is much better -also because it is s=
o
> >>>>>>>>>> fast.
> >>>>>>>>
> >>>>>>>> Also
> >>>>>>>>
> >>>>>>>>>> it is useful to do peak analysis in supervp and use the
> >>>>>>>>>> information
> >>>>>>>>
> >>>>>>>> to
> >>>>>>>>
> >>>>>>>>>> control the morphing envelope in Loris, and things of the
> >>>>>>>>>> sort.
> >>>>>>>>>>
> >>>>>>>>>> Thanks!
> >>>>>>>>>>
> >>>>>>>>>> Eduardo
> >>>>>>>>>
> >>>>>>>>> That sounds great!  Your work would make for an interesting
> >>>>>>>>
> >>>>>>>> presentation
> >>>>>>>>
> >>>>>>>>> at the Ircam Forum Workshops.
> >>>>>>>>>
> >>>>>>>>> Cheers...
> >>>>>>>>>
> >>>>>>>>> ...Diemo
> >>>>>>>>>
> >>>>>>>>>> I forgot, here is the compilation error:
> >>>>>>>>>>
> >>>>>>>>>> eaSDIF_wrap.cxx:1760: error: no type named =91category=92 in
> >>>>>>>>>> =91struct swig::traits<std::pair<std::basic_string<char,
> >>>>>>>>>> std::char_traits<char>, std::allocator<char> >,
> >>>>>>>>>> std::basic_string<char, std::char_traits<char>, std::alloca
> >>>>>>>>>>
> >>>>>>>>>> On Tue, 2006-10-10 at 15:49 +0200, Diemo Schwarz wrote:
> >>>>>>>>>>> Hi Eduardo,
> >>>>>>>>>>>
> >>>>>>>>>>> look in the CVS sources of easdif.  (Now on
> >>>>>>>>>>> http://sourceforge.net/projects/sdif/!)  I think the java,
> >>>>>>>>>>> perl
> >>>>>>>>
> >>>>>>>> and
> >>>>>>>>
> >>>>>>>>>>> python bindings are not part of the distribution, yet,
> >>>>>>>>>>> because
> >>>>>>>>
> >>>>>>>> nobody
> >>>>>>>>
> >>>>>>>>>>> asked for them up to now.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm forwarding this question to the sdif mailing list for
> >>>>>>>>>>> more
> >>>>>>>>
> >>>>>>>> details...
> >>>>>>>>
> >>>>>>>>>>> ...Diemo
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> email message attachment (eaSDIF - Python bindings)
> >>>>>>>>>>>
> >>>>>>>>>>>> -------- Forwarded Message --------
> >>>>>>>>>>>> From: Eduardo Moguillansky <mog...@gm...>
> >>>>>>>>>>>> To: Die...@ir...
> >>>>>>>>>>>> Subject: eaSDIF - Python bindings
> >>>>>>>>>>>> Date: Tue, 10 Oct 2006 14:36:49 +0200
> >>>>>>>
> >>>>>>> --
> >>>>>>> Axel Roebel
> >>>>>>> IRCAM Analysis/Synthesis Team
> >>>>>>> Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------=
--
> >>>>>>> --
> >>>>>>> ----
> >>>>>>> --
> >>>>>>> Using Tomcat but need to do more? Need to support web services,
> >>>>>>> security?
> >>>>>>> Get stuff done quickly with pre-integrated technology to make
> >>>>>>> your
> >>>>>>> job
> >>>>>>> easier
> >>>>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apac=
he
> >>>>>>> Geronimo
> >>>>>>> http://sel.as-us.falkag.net/sel?
> >>>>>>> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> >>>>>>> _______________________________________________
> >>>>>>> Sdif-devel mailing list
> >>>>>>> Sdi...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/sdif-devel
> >>>>>
> >>>>> --
> >>>>> Axel Roebel
> >>>>> IRCAM Analysis/Synthesis Team
> >>>>> Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
> >>>
> >>> Eduardo Moguillansky
> >>> Str=FCmpfelbacherstrasse 52
> >>> 70329 Stuttgart
> >>> +49-711-8829907
> >>
> >> Eduardo Moguillansky
> >> Str=FCmpfelbacherstrasse 52
> >> 70329 Stuttgart
> >> +49-711-8829907
> >
> > --
> > Axel Roebel
> > IRCAM Analysis/Synthesis Team
> > Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
>
> Eduardo Moguillansky
> Str=FCmpfelbacherstrasse 52
> 70329 Stuttgart
> +49-711-8829907

--=20
Axel Roebel   =20
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540

Re: [Sdif-devel] eaSDIF - SWIG Python Bindings

[Axel R. <Axe...@ir...>]

On Tuesday 17 October 2006 11:46, Eduardo Moguillansky wrote:
> hi!
>
> I tried to compile the python bindings of eaSDIF but swig keeps
> reporting some errors. I tried it both in Linux (swig 1.3.24) and OSX
> (1.3.28). I was told that new versions of swig sometimes mess with c++
> but since I found two naming differences between the interface and the
> source files  I thought that maybe the interface files are not
> completely updated.

I fixed the names in the swig interface files.
For me it now compiles cleanly with swig version 1.3.21,
I've tested all wrappers : perl, python and java.

Let me know if you have success with a more recent=20
version of swig.

> Only to try if swig was working fine I compiled the perl bindings and
> they work perfectly in both versions of swig.
>
> As told, sdif 1TRC can be read in python through the Loris wrappers, bu=
t
> it would be great to have access to all the other formats used by
> supervp without having to convert to text first.
>
> thanks!
>
> Eduardo Moguillansky
>
> On Tue, 2006-10-17 at 10:05 +0200, Diemo Schwarz wrote:
> > Dear Eduardo,
> >
> > I'm also forwarding this mail to the sdi...@so... list
> > (subscribe at
>
> https://lists.sourceforge.net/lists/listinfo/sdif-devel),
>
> > where interesting development topics like these should go and where
>
> Axel
>
> > can read them who wrote eaSDIF and the swig python bindings.  I
>
> started
>
> > all this swig thing, but only took care of the perl bindings.
> >
> > What version of swig are you using?
> >
> > Eduardo Moguillansky wrote:
> > > dear Diemo,
> > >
> > > thank you very much for the information. I did get the CVS files an=
d
> > > found the python wrappers. They refuse to compile however. First 2
>
> files
>
> > > have changed name: sdifframe.hpp and sdifmatrix.hpp appear as
> > > sdif_frame.hpp and sdif_matrix.hpp. That changed, it starts
>
> compiling
>
> > > but throws an error when trying to compile the wrapped file. I
>
> wonder if
>
> > > some renaming has taken place since the interface files were done.
> > >
> > > I first compiled and installed easdif (and sdif) with no problems
>
> and
>
> > > they work fine.
> > >
> > > I did actually write a parser for 1TRC files from scratch just by
> > > following the specifications and reading the hex dumps.
> > > But for all the other formats, it seems at the moment more efficien=
t
>
> to
>
> > > convert to text and write a small parser.
> > >
> > > The whole idea is to be able to provide a scripting layer which is
> > > common to some of the softwares working with spectral data -supervp
>
> and
>
> > > loris at the moment (I'm trying to make it work both for mac and
>
> linux,
>
> > > so it is a pity that Pm2 does not seem to have a Linux version),
>
> spear
>
> > > for fast visualization of partial tracking with loris and Pm2. In
>
> this
>
> > > way it is possible to choose the best tool for each task -to do
> > > morphing, for instance, it is very useful to resort to Loris, for
> > > cross-synthesis supervp is much better -also because it is so fast.
>
> Also
>
> > > it is useful to do peak analysis in supervp and use the information
>
> to
>
> > > control the morphing envelope in Loris, and things of the sort.
> > >
> >  > Thanks!
> >  >
> >  > Eduardo
> >
> > That sounds great!  Your work would make for an interesting
>
> presentation
>
> > at the Ircam Forum Workshops.
> >
> > Cheers...
> >                                                               ...Diem=
o
> >
> > > I forgot, here is the compilation error:
> > >
> > > eaSDIF_wrap.cxx:1760: error: no type named =E2=80=98category=E2=80=99=
 in
> > > =E2=80=98struct swig::traits<std::pair<std::basic_string<char,
> > > std::char_traits<char>, std::allocator<char> >,
> > > std::basic_string<char, std::char_traits<char>, std::alloca
> > >
> > > On Tue, 2006-10-10 at 15:49 +0200, Diemo Schwarz wrote:
> > >> Hi Eduardo,
> > >>
> > >> look in the CVS sources of easdif.  (Now on
> > >> http://sourceforge.net/projects/sdif/!)  I think the java, perl
>
> and
>
> > >> python bindings are not part of the distribution, yet, because
>
> nobody
>
> > >> asked for them up to now.
> > >>
> > >> I'm forwarding this question to the sdif mailing list for more
>
> details...
>
> > >>                                                            ...Diem=
o
> > >>
> > >>
> > >> email message attachment (eaSDIF - Python bindings)
> > >>
> > >>> -------- Forwarded Message --------
> > >>> From: Eduardo Moguillansky <mog...@gm...>
> > >>> To: Die...@ir...
> > >>> Subject: eaSDIF - Python bindings
> > >>> Date: Tue, 10 Oct 2006 14:36:49 +0200

--=20
Axel Roebel   =20
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540

Re: [Sdif-devel] [Fwd: eaSDIF - Python bindings]

[Axel R. <Axe...@ir...>]

On Tuesday 17 October 2006 10:37, Diemo Schwarz wrote:
> Dear Eduardo,
>
> I'm also forwarding this mail to the sdi...@so... list
> (subscribe at https://lists.sourceforge.net/lists/listinfo/sdif-devel),
> where interesting development topics like these should go and where Axe=
l
> can read them who wrote eaSDIF and the swig python bindings.  I started
> all this swig thing, but only took care of the perl bindings.
>
> What version of swig are you using?
>
> Eduardo Moguillansky wrote:
> > dear Diemo,
> >
> > thank you very much for the information. I did get the CVS files and
> > found the python wrappers. They refuse to compile however. First 2 fi=
les
> > have changed name: sdifframe.hpp and sdifmatrix.hpp appear as
> > sdif_frame.hpp and sdif_matrix.hpp. That changed, it starts compiling
> > but throws an error when trying to compile the wrapped file. I wonder=
 if
> > some renaming has taken place since the interface files were done.

Hi,

in fact renaming of sdifframe.* and sdifmatrix.* files became necessary=20
because  the mac does not distinguish lower and upper case letters
such that the related object files were confused with the sdif objects
SdifFrame.o. The issue popped up from time to time and I decided to
solve it forever.

Unfortunately I did not update the swig files since then.
Thanks for the remark. I'll fix that.

> > I first compiled and installed easdif (and sdif) with no problems and
> > they work fine.
> >
> > I did actually write a parser for 1TRC files from scratch just by
> > following the specifications and reading the hex dumps.
> > But for all the other formats, it seems at the moment more efficient =
to
> > convert to text and write a small parser.

What could be simpler as parsing an sdif file with Easdif?

> > The whole idea is to be able to provide a scripting layer which is
> > common to some of the softwares working with spectral data -supervp a=
nd
> > loris at the moment (I'm trying to make it work both for mac and linu=
x,
> > so it is a pity that Pm2 does not seem to have a Linux version), spea=
r
> > for fast visualization of partial tracking with loris and Pm2. In thi=
s
> > way it is possible to choose the best tool for each task -to do
> > morphing, for instance, it is very useful to resort to Loris, for
> > cross-synthesis supervp is much better -also because it is so fast. A=
lso
> > it is useful to do peak analysis in supervp and use the information t=
o
> > control the morphing envelope in Loris, and things of the sort.

Sounds interesting.=20

For the people that manage to put the libraries in the=20
correct place we may give a pm2 linux version in the=20
next forum release as well.=20
I'll see how much I'll have to do for that.

> > I forgot, here is the compilation error:
> >
> > eaSDIF_wrap.cxx:1760: error: no type named =E2=80=98category=E2=80=99=
 in
> > =E2=80=98struct swig::traits<std::pair<std::basic_string<char,
> > std::char_traits<char>, std::allocator<char> >,
> > std::basic_string<char, std::char_traits<char>, std::alloca

As I wrote in my last email swig support for c++
is not very stable.
What version of swig are you using?

> > On Tue, 2006-10-10 at 15:49 +0200, Diemo Schwarz wrote:
> >> Hi Eduardo,
> >>
> >> look in the CVS sources of easdif.  (Now on
> >> http://sourceforge.net/projects/sdif/!)  I think the java, perl and
> >> python bindings are not part of the distribution, yet, because nobod=
y
> >> asked for them up to now.
> >>
> >> I'm forwarding this question to the sdif mailing list for more
> >> details... ...Diemo
> >>
> >>
> >> email message attachment (eaSDIF - Python bindings)
> >>
> >>> -------- Forwarded Message --------
> >>> From: Eduardo Moguillansky <mog...@gm...>
> >>> To: Die...@ir...
> >>> Subject: eaSDIF - Python bindings
> >>> Date: Tue, 10 Oct 2006 14:36:49 +0200
>
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apach=
e
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Sdif-devel mailing list
> Sdi...@li...
> https://lists.sourceforge.net/lists/listinfo/sdif-devel

--=20
Axel Roebel   =20
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540

Re: [Sdif-devel] [Fwd: eaSDIF - Python bindings]

[Diemo S. <Die...@ir...>]

Dear Eduardo,

I'm also forwarding this mail to the sdi...@so... list
(subscribe at https://lists.sourceforge.net/lists/listinfo/sdif-devel),
where interesting development topics like these should go and where Axel
can read them who wrote eaSDIF and the swig python bindings.  I started
all this swig thing, but only took care of the perl bindings.

What version of swig are you using?

Eduardo Moguillansky wrote:
> dear Diemo,
>=20
> thank you very much for the information. I did get the CVS files and
> found the python wrappers. They refuse to compile however. First 2 file=
s
> have changed name: sdifframe.hpp and sdifmatrix.hpp appear as
> sdif_frame.hpp and sdif_matrix.hpp. That changed, it starts compiling
> but throws an error when trying to compile the wrapped file. I wonder i=
f
> some renaming has taken place since the interface files were done.
>=20
> I first compiled and installed easdif (and sdif) with no problems and
> they work fine.=20
>=20
> I did actually write a parser for 1TRC files from scratch just by
> following the specifications and reading the hex dumps.
> But for all the other formats, it seems at the moment more efficient to
> convert to text and write a small parser.
>=20
> The whole idea is to be able to provide a scripting layer which is
> common to some of the softwares working with spectral data -supervp and
> loris at the moment (I'm trying to make it work both for mac and linux,
> so it is a pity that Pm2 does not seem to have a Linux version), spear
> for fast visualization of partial tracking with loris and Pm2. In this
> way it is possible to choose the best tool for each task -to do
> morphing, for instance, it is very useful to resort to Loris, for
> cross-synthesis supervp is much better -also because it is so fast. Als=
o
> it is useful to do peak analysis in supervp and use the information to
> control the morphing envelope in Loris, and things of the sort.
>
> Thanks!
>
> Eduardo

That sounds great!  Your work would make for an interesting presentation
at the Ircam Forum Workshops.

Cheers...
								...Diemo


> I forgot, here is the compilation error:
>=20
> eaSDIF_wrap.cxx:1760: error: no type named =E2=80=98category=E2=80=99 i=
n=20
> =E2=80=98struct swig::traits<std::pair<std::basic_string<char,=20
> std::char_traits<char>, std::allocator<char> >,=20
> std::basic_string<char, std::char_traits<char>, std::alloca
>=20
> On Tue, 2006-10-10 at 15:49 +0200, Diemo Schwarz wrote:
>> Hi Eduardo,
>>
>> look in the CVS sources of easdif.  (Now on=20
>> http://sourceforge.net/projects/sdif/!)  I think the java, perl and=20
>> python bindings are not part of the distribution, yet, because nobody=20
>> asked for them up to now.
>>
>> I'm forwarding this question to the sdif mailing list for more details=
...
>> 								...Diemo
>>
>>
>> email message attachment (eaSDIF - Python bindings)
>>> -------- Forwarded Message --------
>>> From: Eduardo Moguillansky <mog...@gm...>
>>> To: Die...@ir...
>>> Subject: eaSDIF - Python bindings
>>> Date: Tue, 10 Oct 2006 14:36:49 +0200