`>> phaseretmex

********* Compiling libltfat **********

********* Compiling libphaseret **********

********* Compiling MEX files **********

Error using phaseretmex (line 176)

Make failed with:

Error using phaseretmex (line 126)

The mex executable in not in the PATH`

All steps mentioned in the installation procedure has been followed.

The following has been reported:

1. I noticed that ltfatmex.m make an extensive use of system calls. The command 'mex' is not available in OSX terminal. Indeed when installing MATLAB, all MATLAB binaries are not automatically added to the terminal search path (probably there is some good reason).

This was the source of my first issue. Indeed at line 124 of ltfatmex.m the script check of the system command 'mex -help', which in my case was failing.

WORKAROUND. instead of permanently adding the MATLAB binary to the search path, I did it only for the instance of MATLAB I've used to compile the library:

Open a TERMINAL enter the command 'export PATH=$PATH:/Applications/MATLAB_R2017b.app/bin/' (it can be different depending on matlab version) then launch MATLAB from the terminal typing 'matlab' (and do not close the terminal until done with MATLAB).

Path to the mex parent directory is added to PATH by default on both Windows and Linux.
Consider using $(CC) instead.

2. The file 'uchar.h' included at line 6 of mex_helper.h is missing. This file does not exist on OSX (seems a common issue, just Google it), it should exist on Linux.

WORKAROUND: replace #include <uchar.h> with the following
#include <stddef.h>
#include <stdint.h>
typedef uint16_t char16_t;
typedef uint32_t char32_t;

I don't even remember why it is there.

3. The file 'fftw3.h' is missing. On the machine I'm using, I never installed the library FFTW3, but even if I did, I believe that the installation path wont be found by the ltfatmex.m. Indeed on OSX there are at least 3 or 4 common path to install libraries (it depends on what you use to install these), while on Linux the search paths for include file and libraries are more standard.
   Indeed in the ltfat library, the file 'fftw3.h' is provided in ltfat/libltfat/modules/libltfat/include/ltfat/thirdparty

WORKAROUND: I've copied 'fftw3.h' from ltfat into one of the header file search path for lphaseret ( libphaseret/include/ )

That will be easy to fix.

4. the linker cant find libfftw3. The script ltfatmex.m is very smart with respect to this. Indeed during compilation I've got the following message:

   ========= Compiling MEX interfaces ========
   ...using libmwfftw3.3.dylib from Matlab installation.
   ...using libmwfftw3f.3.dylib from Matlab installation.

The script recognizes that the library can not be found on the default search path, and so it works with the equivalent library inclided in the matlab installation (dynamically changing the linker options).

WORKAROUND: here there are two options. Install libffw3 on OSX, or use MATLAB one (I went for the second).

Mind that building fftw3 on OSX can be a nightmare (much easier on Linux). Compiled binaries can be found here http://www.finkproject.org/pdb/package.php/fftw3?rel_id=10.13-x86_64-current-bindist

MATLAB fftw3 (the one working on double) is in in the following path and it has a slightly different name '/Applications/MATLAB_R2017b.app/bin/maci64/libmwfftw3.3.dylib'
I had to change line 26 of paseret/mex/Makefile to the following

$(MEX) CFLAGS='$(MYCFLAGS)' $&lt; $(TARGETUP) -L/Applications/MATLAB_R2017b.app/bin/maci64 -lmwfftw3 -lm > /dev/null

This is working but is not very elegant (it's an absolute path, better to use a relative path to MATLAB main folder).

It should do the same thing as LTFAT is doing i.e. preferably link the Matlab libfftw.

Pretty much what is in the title. I only saw this because a colleague trying to use the current version had trouble compiling. Was there a plan for an overhaul similar to libltfat, or should the old version still work properly?

Hi, when I run the demo_phasevocoder.m, the error named "No description of comp_rtpghiupdate" return. Is there anywhere I can find the description. Thanks.

Noticed in test_libltfat_fftshift.py, @susnak you show us how to use ltfat with python. Could you show some example about how to use phaseret with python ?

Hi,
As the executable pvdoneright.exe provide a bar to change the stretches. However, the stretches in demo_phasevocoder.m is fixed. How can I achieve dynamic stretches over time, and how to deal with the hop change between frames.

Hi,

When I run demo_phasevocoder.m and pvdoneright.exe of the same input signal, I got two outputs with big difference. For stretch of 2, the output of pvdoneright.exe sounds good, while some music noise in the output of demo_phasevocoder.m. May I known is there any diference between them. Thanks

Hi @susnak, I try running the phaseret-0.2.0/libphaseret/testing/mUnit test codes, but I encounter some errors. First, the loadlibphaseret.m cannot load the lib correctly. Then I run make shared in libltft and libphaseret, and modify the loadlibphaseret.m script to

function loadlibphaseret(varargin)

definput.keyvals.lib='libphaseret.so';
definput.flags.phase={'load','reload'};
[flags,~,lib]=ltfatarghelper({'lib'},definput,varargin);

[~,libname]=fileparts(lib);
    
if libisloaded(libname) 
    if flags.do_reload
        unloadlibrary(libname);
    else
        error('%s: libphaseret is already loaded. Use ''reload'' to force reload.',upper(mfilename));
    end
end

warning('off');
currdir = fileparts(mfilename('fullpath'));
libpath = [currdir, filesep, '..', filesep, '..' , filesep,'build',filesep,lib];
headerpath = [currdir, filesep, '..', filesep, '..' , filesep, 'include',filesep,'phaseret.h'];
loadlibrary(libpath,headerpath,'mfilename','libphaseretprotofile.m', 'includepath', '/home/liupeng/phaseret-0.2.0/libphaseret/include', 'includepath', '/home/liupeng/phaseret-0.2.0/libltfat/include');
warning('on');

This script can run without any error.
But when I run test_libphaseret_gla.m, it says

Error using calllib
Method was not found.

Error in test_libphaseret_gla (line 20)
calllib('libphaseret','phaseret_gla_d',cinPtr,g,L,gl,1,a,M,maxit,coutPtr);

Could you please offer some help?

Now I have some images (.jpg) which are all spectrogram generated by the matlab function'spectrogram'. How can I use your code to reconstruct signals corresponding to the spectrogram with Griffin & Lim algorithm?

Hey there,

Could you give me an impression of the performance of pvdoneright, or demo_phasevocoder.m?

For instance given 1 second of sound, on your computer that you you have in front of you, how long does it take to speed up to 0.9 it's length? (Obviously you don't have 1 second of sound right in front of you, so rough estimate is fine)

I'm currently installing octave- but I think it will be several hours of fiddling before things run on my end :-(. Or maybe it won't run at all actually.

I'm considering porting to C++, if the general performance is adequate for my needs (should be realtime or better than realtime). There is an implementation in rust, however it is ... not optimal.

Thanks,

-tim

Create a working phase vocoder and a simple demo on how to use it.

It should probably be a pair of functions:

• phasevocodersimple to just change the running time of a signal based on DGTREAL
• phasevocoder to do time-varying resampling based on NSDGT

Hey there,

I'm about to ask a non-well-formed question. I apologize in advance. If it doesn't make sense, or etc, ignore as you wish. But here goes:

So I'm porting a rust implementation of PVDoneRight, mostly because I don't want to look at any GPL code.
This rust implementation is really clear and follows your paper.

However there is one variable that doesn't make much sense to me:
analysis_frequency_step

analysis_frequency_step is calculated by taking the input_length and dividing it by the fft size like so:
(rust code)
let analysis_frequency_step = input_len as f64 / fft_size as f64
(this just says, analysis_frequency_step = input_len / fft_size (but use floats))

Then later this analysis_frequency_step is used while calculating deltas-- for instance:

in this example i corresponds to the frame index and j corresponds to fft frequency value. Essentially he is writing, "if there is no necessary surrounding frames then just use frequency_delta_phi, but if there are- calculate the frequency_forward_delta_phi using phases of the previous frames"

            // (∆f,fwdφa) (m, n) = 1 / ba [φa(m + 1, n) − φa(m, n)] 2π
            frequency_forward_delta_phi[i][j] = if j + 2 >= fft_size || j as isize - 1 < 0 {
                frequency_delta_phi[i][j]
            } else {
                synthesis_frequency_step / 2.0
                    * (1.0 / analysis_frequency_step
                        * principal_argument(phase[i][j] - phase[i][j - 1])
                        + 1.0 / analysis_frequency_step
                            * principal_argument(phase[i][j + 2] - phase[i][j + 1]))
            };

Here is my question:
Since the analysis hopsize (the hop between the fft on the input data) is not dependent of the input length and the synthesis hopsize (the hop between the fft on the output data) is not dependent on the input length, shouldn't the analysis_frequency_step also be independent of the input length?

Shouldn't analysis_frequency_step be somehow a scalar multiplied by synthesis_hop_size?

If you have any hints or insights, I would appreciate. I realize this is not the code you wrote, however I believe I've summarized what's happening - and as you are the world expert you can probably understand instantly more than I.

Thanks in advance.

-tim

The rust implementation can be found here:
https://github.com/Hajime-san/phase-gradient-vocoder/blob/main/src/main.rs

noticed in gla.h, function phaseret_gla_s(const ltfat_complex_s cinit[], const float g[], ltfat_int L, ltfat_int gl, ltfat_int W, ltfat_int a, ltfat_int M, ltfat_int iter, ltfat_complex_s c[]); has 9 parameters.

But when i load libphaseret.so, and print(getattr(lib_phaseret, 'phaseret_gla_s')), the result told me that phaseret_gla_s has 10 parameters.

In [4]: print(getattr(lib_phaseret, 'phaseret_gla_s'))
<cdata 'int(*)(float(*)[2], int *, float *, int, int, int, int, int, int, float(*)[2])' 0x7f1a3ef80ec0>

The default phase convention of the phase rec. algorithms is timeinv, but (i)dgtreal from LTFAT works with freqinv.

• Either make all the algorithms work with freqinv phase conv. by default
• or create a wrapper for computing (i)dgtreal