Victor Shepardson

I notice that when using PackageCompiler with the 1.7.1 release build of Julia, `libjulia.dylib` and the entry point built by PackageCompiler (in my case `libscjulia.dylib`) end up in a `lib`...

after more debugging, it definitely fails here: https://github.com/JuliaLang/PackageCompiler.jl/blob/ab5d6cf008b25a0868c61b21287d46ca2104ef05/src/julia_init.c#L27 where `libname` is `"libscjulia.0.1.0.dylib"`, and was compiled into `libscjulia` itself here https://github.com/JuliaLang/PackageCompiler.jl/blob/94fdba2b99b7f0d3be9906de831c1ca6a0091488/src/PackageCompiler.jl#L583 if I start `scsynth` with `DYLD_PRINT_RPATHS=1 DYLD_PRINT_LIBRARIES=1`: ``` ... dyld:...

like the locally built julia-debug 1.7.1, locally built 1.7.1 in release mode also works as expected and causes PackageCompiler to place everything under `lib/` and not `lib/julia`. this directory structure...

No problem! I think the reconstruction losses in the paper are similarly given as norms, where they are also means in the code. And the latent space loss is said...

I ran into this as well and found the same fix. passing n_channels to the RAVE constructor prevents it from getting saved in the gin file.

Agree that this change doesn't affect training, only logging. However I'm quite certain it works as described, I've been using it on my fork. Since the beginning part of the...

thanks! will probably not be trying nc waveRNN then, due to limited budget. But I'll post here if I do.

I have not tried it under linux. What happens exactly -- scsynth crashes silently? Also: are you sure the RAVE you are using has a prior method? Do you maybe...

should now print a warning about missing prior model, if that was the issue.

hey sorry for the late reply! it sounds like you are probably using an x86 python, since it is looking for intel MKL stuff? were you trying to build an...