< Back to IRCAM Forum

SDIF, SuperVP and Pm2 in MATLAB

Hi,

I’d really like to read and write SDIF files in MATLAB’s most recent installment (R2020a). What do I need to do make it happen? I’m quite new to MATLAB, so I feel I really need to do this by the book…

And last but not least, is there a way to run Pm2 and SuperVP in MATLAB R2020? If so, and yet again, what do I need to do to make it happen?

Any hints or insights on these issues would be much appreciated.

All the best,
António

For SDIF, there are some mex files and matlab scripts here: https://sourceforge.net/p/sdif/code/HEAD/tree/
(download or use svn to get the code)
The README file includes instructions, but matlab has because more and more restrictive when it comes to compiling mex-files, so YMMV (feel free to ask if you run in trouble, but I don’t have access to matlab 2020)
You will need cmake (https://cmake.org/) to compile these

As for pm2 and supervp, these are command line executables. So you would run these from matlab code using the system function. Again, depending on the platform and matlab setup you may run into issues (because matlab comes with a set of libraries that may interfere with supervp or pm2), in which came it might be better to run these from outside matlab.

Hi Frédéric,

Thank you. I’ll try to set it up as you prescribed, If I run into trouble I’ll check back…

I think I’ll keep running SuperVP and Pm2 commands outside of MATLAB only, then.

All the best,
António

Since this was posted under “Audiosculpt”, I guess you’re on mac. The “system” issues are most common with linux (apart from the usual Catalina issues, where you’re on your own because I don’t have access to Catalina), so it might still work (are you using the supervp/pm2 versions from Audiosculpt or those from the “Analysis/synthesis command line tools”?)

Because I’m using older MacOS/matlab versions, I’m not current with the matlab/Xcode conflicts that may arise (I’m sure there are some, there always are). If you can’t compile the mex-files, I could try and send you older versions, but that’s unlikely to work

If you run into errors, please attach the output of whatever failed (either cmake or make). Maybe there will be a clue there. I’m unfortunately familiar with these tricky negotiations between matlab and compilers

There’s also http://sdif.sourceforge.net/wiki/index.php/SDIF_Matlab with a tutorial and a link to pre-built mex files. Not sure if everything is up to date, though…

Hi all,

I’m reactivating this topic since I’m trying to do the same, i.e. read sdif files in Matlab R2020a.

Frédéric, Diemo, I got the links to the binaries and sources, but I have questions and remarks:
. the binaries in SDIF - Browse /matlab at SourceForge.net are definitely not up to date and won’t run on Matlab R2020a

. are the sources in SDIF / Code / [r1861] up-to-date? The latest modifications are from 2008, and the changelog states:
“2004-07-20 Axel Roebel Axel.Roebel@ircam.fr
Version 0.4.0”

… whereas the old binaries are version 0.5.1.

So:

Would it be possible to add the up-to-date sources of the matlab tools to the main sdif distribution (I mean SDIF - Browse /sdif at SourceForge.net)?

Alexis

You probably should use the (more recent) Easdif versions instead, the source is at p/sdif/code - Revision 1861: /trunk/Easdif
The README file contains instructions to build the matlab interface, basically you need to pass -DEASDIF_BUILD_MEX:BOOL=on to cmake, then make mex.
For it to work, mex should be available and properly configured.
The older interface in sdif-matlab might still build, depending on your platform and configuration, but I don’t think it’s actively maintained.

Hi Frédéric,

Thanks for the information.

So, I tried and had only limited luck while compiling. The main problem is that cmake does not provide automatically the right parameters to the compiler so that it can finds the standard c++ libraries.

in practice. By default, i.e. by running “cmake -DEASDIF_BUILD_MEX:BOOL=on” or “cmake -GXcode -DEASDIF_BUILD_MEX:BOOL=on”, I get the following problems:
1/ during the cmake command:
“-- Looking for C++ include sstream
– Looking for C++ include sstream - not found
– Looking for C++ include strstream
– Looking for C++ include strstream - not found”
2/ then with “make” or “make mex”:
“[ 0%] Building CXX object easdif/CMakeFiles/Easdif_static_pic.dir/sdifentity.cpp.o
warning: include path for stdlibc++ headers not found; pass ‘-std=libc++’ on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
/Volumes/Data2/SDIF/EASDIF_SDIF/easdif/sdifentity.cpp:271:10: fatal error: ‘iostream’ file not found
#include
^~~~~~~~~~
1 warning and 1 error generated.
make[3]: *** [easdif/CMakeFiles/Easdif_static_pic.dir/sdifentity.cpp.o] Error 1
make[2]: *** [easdif/CMakeFiles/Easdif_static_pic.dir/all] Error 2
make[1]: *** [matlab/CMakeFiles/mex.dir/rule] Error 2”

I got similar errors while compiling from xcode

I tried many options, and went a little bit further and could compile in xcode with the following cmake command:
“rm CMakeCache.txt; cmake -GXcode -DEASDIF_BUILD_MEX:BOOL=on -DUSE_LLVM_STD=1 .”

(since it forces the use of the c++ standard libraries in SET_COMPILER_FLAGS.cmake)

But the “mex” target in the xcode project still does not work. And from the command line (i.e. with “make” or “make mex”) I still get the same errors. BTW: why is it that the command line does not call the xcode project and use a different compilation strategy?

My configuration:
10.14.6
Xcode 10.1

Any ideas?

Best

Alexis

Building a mex-file has to be done through MathWorks’s mex script, so it cannot be fully integrated into a proper Xcode project.
I would need the precise error you’re getting (attach the output or DM it to me): the joys of mex-file compilation is that it depends on the version of matlab and the version of the compiler, and none of it is documented.
For the record, it compiles fine with Xcode 11.3, macOS 10.14.6 and matlab 2014b, but fails with macOS 11.6, Xcode 12.5.1 and matlab 2019b. I don’t have your combination, so based on the error I’ll try to guess what’s wrong
The USE_LLVM_STD option could be handled better for sure, unfortunately clang still accepts the old -std=libstdc++ but fails at link-time, some versions even default to it but fail. Finding something that works with all combinations is trial and error.