Rack 1.0 issues

@sanderbaancentrum its not a good idea to post your serial number…

@Phal-anx thanks, removed :slight_smile:

Spinlocks are used as a barrier on the N-1 threads waiting on the last thread to finish stepping (Core AUDIO in your case), so this is expected.

Don’t really understand what you are saying but if this is how multithreading is gonna work its not gonna be usable for me as I am unable to use another app like Ableton besides Rack as Rack takes all the CPU and therefor the rest becomes to slow to use.

That’s why you’re able to select the exact number of threads. If you want to leave one for Ableton Live, choose 3 in your case (one less than your physical cores) so Live will be assigned the remaining one by the operating system.

1 Like

6700K OS X 13.6 Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin17.7.0 Thread model: posix

Build on commit: ddebd2d8d28133e73d03da0367301184b0883fed

make dep fine

make gives:

clang: error: no such file or directory: ‘dep/lib/libomp.a’

I thought this dependency had gone:

1 Like

Should be fixed now.

Will v1.0 build on windows?

It should

getting an error on make dep

$ make dep
make -C dep
make[1]: Entering directory ‘/home/Phil/rack-1/dep’
mkdir -p .
cd glfw && mkdir -p build
cd glfw/build && cmake -G ‘MSYS Makefiles’ -DCMAKE_INSTALL_PREFIX="/home/Phil/rack-1/dep/." -DCMAKE_INSTALL_LIBDIR=lib …
-DGLFW_COCOA_CHDIR_RESOURCES=OFF -DGLFW_COCOA_MENUBAR=ON -DGLFW_COCOA_RETINA_FRAMEBUFFER=ON
CMake Error: The source directory “C:/msys64/home/Phil/Rack-1/dep/glfw” does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
make[1]: *** [Makefile:75: lib/libglfw3.a] Error 1
make[1]: Leaving directory ‘/home/Phil/rack-1/dep’
make: *** [Makefile:54: dep] Error 2

6700K OS X 13.6
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0

Clean clone and then build of 10308b60c6d556ec7715e962676943f19b1997d0.

I’m afraid there is a pile of warnings ending in a error now:

ld: warning: object file (dep/lib/librtaudio.a(RtAudio.cpp.o)) was built for newer OSX version (10.13) than being linked (10.7)

/// 76 similar removed

ld: warning: object file (dep/lib/libzip.a(zip_crypto_commoncrypto.c.o)) was built for newer OSX version (10.13) than being linked (10.7)
Undefined symbols for architecture x86_64:
  "_osdialog_file", referenced from:
      rack::PatchManager::saveAsDialog() in patch.cpp.o
      rack::PatchManager::loadDialog() in patch.cpp.o
      rack::app::ModuleWidget::loadDialog() in ModuleWidget.cpp.o
      rack::app::ModuleWidget::saveDialog() in ModuleWidget.cpp.o
  "_osdialog_message", referenced from:
      rack::PatchManager::init(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in patch.cpp.o
      rack::PatchManager::load(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in patch.cpp.o
      rack::PatchManager::resetDialog() in patch.cpp.o
      rack::PatchManager::saveTemplateDialog() in patch.cpp.o
      rack::PatchManager::fromJson(json_t*) in patch.cpp.o
      rack::PatchManager::revertDialog() in patch.cpp.o
      rack::plugin::init(bool) in plugin.cpp.o
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

You probably didn’t checkout the submodules.

1 Like

Is that…
git submodule update --init --recursive

Yes, that’s the step. You should see the dep/glfw folder populated with files.

I’m getting.

fatal: not a git repository (or any of the parent directories): .git

Are you following https://vcvrack.com/manual/Building.html?

Should I not be? :face_with_raised_eyebrow:

You should be, except of course with the extra step of git checkout v1. You should run git submodule update --init --recursive somewhere in the Rack git repo directory on your computer.

1 Like

Grand, looks like that’s the one now cheers!

Question on make -j$(nproc) is that physical cores? Iv’e 4 physical 4 threaded will the work be spread over 8 if I do -j8. Iv’e being doing -j4, 8 works but not sure if that is spread over 8 cores.

Best results are to use the number of logical cores. Since compiling is trivially parallelizable, hyperthreading is beneficial.