Package Details: radium 6.9.96-1

Git Clone URL: (read-only, click to copy)
Package Base: radium
Description: A graphical music editor. A next generation tracker.
Upstream URL:
Licenses: GPL2
Submitter: speps
Maintainer: KenjiTakahashi (Teteros)
Last Packager: Teteros
Votes: 19
Popularity: 0.004485
First Submitted: 2013-05-22 03:41 (UTC)
Last Updated: 2021-09-05 15:16 (UTC)

Pinned Comments

Latest Comments

Noctivivans commented on 2021-12-26 22:20 (UTC) (edited on 2021-12-27 00:49 (UTC) by Noctivivans)

@Newk-B: It seems that it is radium developer decision:

I think that the solution would be creating new issue in radium git and ask author to update his version of faust.

In the meantime, you can modify PKGBUILD to use older version of llvm - I just checked with llvm11 and it builds successfully.

Newk-B commented on 2021-12-08 12:19 (UTC)

This? this was back in April.. Am i right when guessing the code for Faust has been incorporated into the source of Radium? Wouldn't it be better if it gets the recent version of the Faust source while building Radium? (i'm definitly not a programmer so excuse my stupid reasoning)

Newk-B commented on 2021-12-07 00:45 (UTC) (edited on 2021-12-07 02:04 (UTC) by Newk-B)

This package version used to work, but now when starting i get the following message on CLI:

libxcb is recent enough. We can use it
/opt/radium/radium_linux.bin: error while loading shared libraries: cannot open shared object file: No such file or directory

Since this Manjaro system has updated the package 'llvm-libs' to version 13 in the meantime it seems like the code to Radium is too explicit in which version it needs to run.

So i hoped by reinstalling this package it would pick the newer lib and work again.. but when compiling it tripped over something LLVM and Faust:

[ 64%] Building CXX object CMakeFiles/staticlib.dir/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/normalize/mterm.cpp.o
/usr/bin/g++ -DCPP_BUILD -DFAUST_SELF_CONTAINED_LIB -DINTERP_BUILD -DLIBDIR=\"lib\" -DLLVM_130 -DLLVM_BUILD -DLLVM_VERSION=\"13.0.0\" -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/boxes -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/documentator -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/draw -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/errors -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/evaluate -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/extended -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/fir -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/interpreter -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/rust -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/soul -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/dlang -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/normalize -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/parallelize -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/parser -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/patternmatcher -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/propagate -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/signals -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/tlib -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/transform -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/utils -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/draw/device -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/draw/schema -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/../architecture -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/cpp -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm -I/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/c -mtune=generic -msse2 -mfpmath=sse -fPIC -fno-strict-aliasing  -mtune=generic -msse2 -mfpmath=sse -fPIC -fno-strict-aliasing -fmax-errors=5 -I/home/kjetil/site_clang10/include -O3 -Wall -Wextra -Wno-unused-parameter -Wno-unused-function -Wno-overloaded-virtual -fPIC -DFAUST_LIB -std=gnu++14 -MD -MT CMakeFiles/staticlib.dir/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/normalize/mterm.cpp.o -MF CMakeFiles/staticlib.dir/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/normalize/mterm.cpp.o.d -o CMakeFiles/staticlib.dir/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/normalize/mterm.cpp.o -c /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/normalize/mterm.cpp
In file included from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh: In constructor ‘LLVMTypeHelper::LLVMTypeHelper(llvm::Module*)’:
/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:92:93: error: invalid conversion from ‘int’ to ‘const llvm::VectorType*’ [-fpermissive]
   92 |         fTypeMap[Typed::kFloat_vec]     = VectorType::get(fTypeMap[Typed::kFloat], gGlobal->gVecSize);
      |                                                                                    ~~~~~~~~~^~~~~~~~
      |                                                                                             |
      |                                                                                             int
In file included from /usr/include/llvm/IR/DataLayout.h:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:41,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/usr/include/llvm/IR/DerivedTypes.h:432:63: note:   initializing argument 2 of ‘static llvm::VectorType* llvm::VectorType::get(llvm::Type*, const llvm::VectorType*)’
  432 |   static VectorType *get(Type *ElementType, const VectorType *Other) {
      |                                             ~~~~~~~~~~~~~~~~~~^~~~~
In file included from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:99:95: error: invalid conversion from ‘int’ to ‘const llvm::VectorType*’ [-fpermissive]
   99 |         fTypeMap[Typed::kDouble_vec]     = VectorType::get(fTypeMap[Typed::kDouble], gGlobal->gVecSize);
      |                                                                                      ~~~~~~~~~^~~~~~~~
      |                                                                                               |
      |                                                                                               int
In file included from /usr/include/llvm/IR/DataLayout.h:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:41,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/usr/include/llvm/IR/DerivedTypes.h:432:63: note:   initializing argument 2 of ‘static llvm::VectorType* llvm::VectorType::get(llvm::Type*, const llvm::VectorType*)’
  432 |   static VectorType *get(Type *ElementType, const VectorType *Other) {
      |                                             ~~~~~~~~~~~~~~~~~~^~~~~
In file included from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:105:93: error: invalid conversion from ‘int’ to ‘const llvm::VectorType*’ [-fpermissive]
  105 |         fTypeMap[Typed::kInt32_vec]     = VectorType::get(fTypeMap[Typed::kInt32], gGlobal->gVecSize);
      |                                                                                    ~~~~~~~~~^~~~~~~~
      |                                                                                             |
      |                                                                                             int
In file included from /usr/include/llvm/IR/DataLayout.h:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:41,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/usr/include/llvm/IR/DerivedTypes.h:432:63: note:   initializing argument 2 of ‘static llvm::VectorType* llvm::VectorType::get(llvm::Type*, const llvm::VectorType*)’
  432 |   static VectorType *get(Type *ElementType, const VectorType *Other) {
      |                                             ~~~~~~~~~~~~~~~~~~^~~~~
In file included from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:111:93: error: invalid conversion from ‘int’ to ‘const llvm::VectorType*’ [-fpermissive]
  111 |         fTypeMap[Typed::kInt64_vec]     = VectorType::get(fTypeMap[Typed::kInt64], gGlobal->gVecSize);
      |                                                                                    ~~~~~~~~~^~~~~~~~
      |                                                                                             |
      |                                                                                             int
In file included from /usr/include/llvm/IR/DataLayout.h:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:41,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/usr/include/llvm/IR/DerivedTypes.h:432:63: note:   initializing argument 2 of ‘static llvm::VectorType* llvm::VectorType::get(llvm::Type*, const llvm::VectorType*)’
  432 |   static VectorType *get(Type *ElementType, const VectorType *Other) {
      |                                             ~~~~~~~~~~~~~~~~~~^~~~~
In file included from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:117:91: error: invalid conversion from ‘int’ to ‘const llvm::VectorType*’ [-fpermissive]
  117 |         fTypeMap[Typed::kBool_vec]     = VectorType::get(fTypeMap[Typed::kBool], gGlobal->gVecSize);
      |                                                                                  ~~~~~~~~~^~~~~~~~
      |                                                                                           |
      |                                                                                           int
In file included from /usr/include/llvm/IR/DataLayout.h:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_instructions.hh:41,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/generator/llvm/llvm_code_container.hh:26,
                 from /var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp:90:
/usr/include/llvm/IR/DerivedTypes.h:432:63: note:   initializing argument 2 of ‘static llvm::VectorType* llvm::VectorType::get(llvm::Type*, const llvm::VectorType*)’
  432 |   static VectorType *get(Type *ElementType, const VectorType *Other) {
      |                                             ~~~~~~~~~~~~~~~~~~^~~~~
compilation terminated due to -fmax-errors=5.
make[5]: *** [CMakeFiles/staticlib.dir/build.make:972: CMakeFiles/staticlib.dir/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/compiler/libcode.cpp.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory '/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/build/faustdir'
make[4]: *** [CMakeFiles/Makefile2:156: CMakeFiles/staticlib.dir/all] Error 2
make[4]: Leaving directory '/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/build/faustdir'
make[3]: *** [Makefile:156: all] Error 2
make[3]: Leaving directory '/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/build/faustdir'
make[2]: *** [Makefile:80: all] Error 2
make[2]: Leaving directory '/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust/build'
make[1]: *** [Makefile:33: most] Error 2
make[1]: Leaving directory '/var/tmp/pamac-build-newk/radium/src/radium-6.9.96/bin/packages/faust'
make: *** [Makefile:823: bin/packages/deletemetorebuild] Error 2
==> ERROR: A failure occurred in build().

oldcastle commented on 2021-11-24 18:30 (UTC)

It doesn't build on Manjaro. It says "Failed to prepare transaction", follow by "could not satisfy dependencies: - unable to satisfy dependency 'steinberg-vst36' required by radium"

Teteros commented on 2020-01-21 11:30 (UTC)

@bda Try building 5.9.90 I've just pushed (preferably in a clean chroot to rule out your build environment)

If you still have no luck you can add this patch to the PKGBUILD and remove both RADIUM_USE_CLANG=1 env vars in build() to use gcc instead of clang which might work for you better.

bda commented on 2019-12-22 09:49 (UTC)

Hi, i've got an error:

clang++ -mfpmath=sse -msse2 Qt/Qt_instruments.cpp -c  `cat buildtype.opt` -Ibin/packages/gc-7.4.16/include -IQt/ -I/usr/include/python2.7 `cat flagopts.opt`  -Werror=array-bounds -msse2 -fomit-frame-pointer -DFOR_LINUX -DQT_X11EXTRAS_LIB -I/usr/include/qt/QtX11Extras -I/usr/include/qt -I/usr/include/qt/QtCore -DQT_GUI_LIB -I/usr/include/qt/QtGui -DQT_CORE_LIB  -DWITH_FAUST_DEV -DWITH_PD  -I/home/bruno/boost_1_70_0 -I/home/bruno/boost_1_67_0 -I/home/bruno/boost_1_63_0 -I /usr/include/vst36 -I ~/SDKs/VST_SDK/VST2_SDK/ -I ~/SDKs/VST3\ SDK -I ~/SDKs/vstsdk2.4/ -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unknown-pragmas -fno-strict-aliasing -Wmissing-field-initializers -Wnull-dereference  -Wno-deprecated-register -DUSE_QT5 -Wmissing-declarations -DNDEBUG   -std=gnu++11 -DUSE_QT4 -DUSE_QIMAGE_BUFFER=1 `pkg-config --cflags Qt5Gui --cflags Qt5Network --cflags Qt5OpenGL --cflags Qt5Widgets --cflags Qt5WebKitWidgets --cflags Qt5WebKit --cflags Qt5Concurrent` -Ibin/packages/qhttpserver-master/src -I/home/bruno/.cache/yay/radium/src/radium-5.9.86/bin/packages/QScintilla_gpl-2.10.8/Qt4Qt5 -DQHTTPSERVER_EXPORT  -fPIC   `pkg-config --cflags sndfile` -Wno-null-dereference ; \

fi In file included from ../../../audio/Juce_plugins.cpp:79: ../../../audio/../common/nsmtracker.h:48:2: error: "Compiled with -mtune=native or -mtune=corei7"

error "Compiled with -mtune=native or -mtune=corei7"

^ 1 warning and 1 error generated. make[1]: [Makefile:102: build/intermediate/Release/Juce_plugins_6c083ccb.o] Error 1 make[1] : on quitte le répertoire « /home/bruno/.cache/yay/radium/src/radium-5.9.86/pluginhost/Builds/Linux » make: [Makefile:749: pluginhost/Builds/Linux/build/libMyPluginHost.a] Error 2 make: *** Attente des tâches non terminées....

^ It takes forever to compile this file with -Og
^ It takes forever to compile this file with -Og

==> ERREUR : Une erreur s’est produite dans build(). Abandon… Error making: radium

I've got -march=native in my CXXFLAGS and CFLAGS inside makepkg.conf. It work if i remove it. It doesn't work if i try : CXXFLAGS="-O3 -pipe -fno-plt" CFLAGS="-O3 -pipe -fno-plt" makepkg -s

arinlares commented on 2019-10-19 04:32 (UTC)

Idk what else to do on my systems, so that's what I did about bitstream.

Thanks for fixing the build issue.

Teteros commented on 2019-10-19 02:18 (UTC) (edited on 2019-11-06 10:41 (UTC) by Teteros)

@arinlares You're correct, the LLVM 9.0 update in means FAUST conditionals needed to be updated again.

I've updated the PKGBUILD with a patch (for radium's faust.patch :) and opened a pull request upstream:

As for ttf-bitstream-vera fonts, radium displays a warning about it at the start and maintainer claims it's harmless.

I haven't had any issues without it so I didn't include it in the PKGBUILD.

EDIT: It looks like Qt might silently replace fonts that are not installed so for radium to look right I've added the required fonts packages to the PKGBUILD.


arinlares commented on 2019-10-15 03:44 (UTC) (edited on 2019-10-16 06:57 (UTC) by arinlares)

I'm getting a failed compilation on the faust package

CMakeFiles/faust.dir/home/arin/Documents/git/radium/src/radium-5.9.74/bin/packages/faust/compiler/generator/cpp/cpp_gpu_code_container.cpp.o -o ../bin/faust -lpthread -L/usr/lib -lLLVM-9

Before make exits, that's the last line, no errors beforehand. I'll get more info if needed. I rolled back llvm and llvmlibs to 8.0.1-3 to see if it'll build, and just rolled back to Radium 5.9.65.

EDIT: It may be LLVM, it just got updated to 9.0.0 recently on the 11th, and I know the work probably needs to be done to patch it for the upgrade.

arinlares commented on 2019-05-17 00:35 (UTC)

Just a note, I'm not sure how common the issue is:

If you use a VST in it, and see squares at the top of the VST window, you'll want to install ttf-bitstream-vera. I believe the font is hard-coded to be used, I couldn't change it to another. Installing the font worked.

Teteros commented on 2019-03-23 06:00 (UTC) (edited on 2019-10-19 02:20 (UTC) by Teteros)


I had an error concerning faust which was not installed on my system, so I installed it.

faust should have been build during the compile? Radium includes patched faust so I would not recommend having another faust binary in your path.

Try the new PKGBUILD for 5.9.48 version I just pushed. It includes a needed build-fix. I'd recommend building in a clean chroot to rule out your environment interfering.

sylsau commented on 2019-03-17 22:36 (UTC) (edited on 2019-03-17 22:38 (UTC) by sylsau)

It failed to build on my part. I used @Teteros curl command to get proper llvm binairies.

First, I had an error concerning faust which was not installed on my system, so I installed it.

Then I got this:

I've tried to remedy the error, but to no avail.

Teteros commented on 2018-09-09 22:22 (UTC) (edited on 2019-05-16 09:38 (UTC) by Teteros)

EDIT: Since version 5.9.60 radium supports LLVM8 natively, making this binary redundant.

For your convenience (llvm can take really long to build), I have binaries for the LLVM version required for this package on gist.~~

Quick way to get this dependency before installing radium:

curl -OL && tar xvzf master.tar.gz && sudo pacman -U *-master/llvm40-*.tar.xz

If your pacman.conf requires all packages to be signed, you can add my key for this package to your keyrings with:

curl -sS | gpg --import # for .gnupg keyring
curl -sS | sudo pacman-key --add - # for pacman keyring
sudo pacman-key --lsign-key teteros # to trust key in pacman store

J5lx commented on 2018-08-12 00:26 (UTC)

I'm also getting those. I also recently got a notification about someone adopting a package submitted and still maintained entirely by myself. Probably gonna report it as a bug soon, but not today since it's already very late.

While I'm at it, it's true that I've been kinda busy and it's been tricky enough for me to keep track of my own packages. It's getting better though, so I hope I can also start looking after radium again soon. Thanks to Teteros for joining the effort and keeping the package maintained in the last few weeks!

KenjiTakahashi commented on 2018-08-11 22:20 (UTC)

Hm, did you also receive several "package disowned" notifications for this recently? Some kinda bug or what?

hylix commented on 2018-07-04 16:43 (UTC) (edited on 2018-07-05 08:15 (UTC) by hylix)


I finally managed to compile the package (probably thanks to the new update)

But now it crashes when I try to run it

Following my intuition (idk why) I tried to run it in root and it kinda works

I tried comparing the logs (god why ?) and nothing really caught my attention excepted the sample rate warning so I changed it and it still not run.

I also tried changing the rights, by changing owner, then directly chmod 777, still crashing.

So now I have no idea what to try next so if any of you have an idea for me I'd be glad reading it, meanwhile I'm going to keep searching.

Btw is there a way that the scanning / testing that happens at start crashes on some plugin stuff (vst/ladspa etc..)

Log for giggles:

Some day I'll manage to run this software (one way or another)

Teteros commented on 2018-07-03 11:24 (UTC)

@aropupu You're not alone on that one, I've heard from another user also having the same problem.

Unfortunately I could not reproduce this even on a clean chroot build. s7.tar.gz in the build should extract during ./ step (Makefile.Qt):

bin/packages/s7/s7.c: bin/packages/s7.tar.gz
    cd bin/packages && rm -fr s7 && tar xvzf s7.tar.gz && touch s7/s7.c

Inspecting my build log (makepkg -L) reveals s7.tar.gz was indeed extracted:

$ grep "s7.tar.gz\|^s7/" radium-5.8.2-1-x86_64-build.log
cd bin/packages && rm -fr s7 && tar xvzf s7.tar.gz && touch s7/s7.c

You can add this to your PKGBUILD before msg2 "Building radium" line:

msg2 "Extracting s7.tar.gz"
tar xvzf bin/packages/s7.tar.gz -C bin/packages

aropupu commented on 2018-07-03 09:15 (UTC)

Okay, so after toiling around a bit: Although the package does contain the required s7 scheme interpreter files as bin/packages/s7.tar.gz, this archive never gets extracted in the build process. Manually unpacking the archive to the directory it's at solved the problem and the whole thing now compiles.

aropupu commented on 2018-07-03 07:18 (UTC)

So, should this package compile now or not? my build fails with:

embedded_scheme/scheme.cpp:21:10: fatal error: s7.h: No such file or directory
 #include "s7.h"
compilation terminated.
make: *** [Makefile:2330: scheme.o] Error 1

KenjiTakahashi commented on 2018-06-17 21:20 (UTC)

Great! You should have push access now.

Teteros commented on 2018-06-17 12:23 (UTC)

@KenjiTakahashi Sure you can add me, also welcome back :)

Good timing too, llvm40 compiles now without manual patching, so we can switch to using it here. (I've been silently patching my gist till that happened)

[MY PKGBUILD] radium 5.7.0 => radium 5.7.6


  • Removed fix-qt-5.11-types.patch
  • Updated use-system-libxcb.patch use-system-vstsdk.patch

KenjiTakahashi commented on 2018-06-14 18:54 (UTC) (edited on 2018-06-14 18:55 (UTC) by KenjiTakahashi)


Sorry for such a very long absence, lots of real life stuff had caught me and things like AUR had to be sidetracked for a while. And it seems that the other maintainer is gone as well.

@Teteros, thanks for the continuous updates for this, you're doing great job here :-). If you're fine with it, I can add you as a maintainer, just let me know.

xtal commented on 2018-06-13 09:55 (UTC)

That would be really cool if you could take over the package Teteros. I haven't been able to get Radium running since some time last year.

t-ask commented on 2018-06-08 19:34 (UTC)

@Teteros Won't you just take over this package maintenance? It looks like the maintainer is no more updating it.

Teteros commented on 2018-06-02 20:26 (UTC) (edited on 2018-06-02 20:59 (UTC) by Teteros)

[MY PKGBUILD] radium 5.6.7 => radium 5.7.0


Teteros commented on 2018-05-18 13:14 (UTC) (edited on 2018-06-02 20:58 (UTC) by Teteros)

[MY PKGBUILD] radium 5.6.5 => radium 5.6.7

  • Updated use-system-vstsdk.patch upstream ref aaad1dd
Build & Install

llvm40 binaries provided in last comment if anyone has troubled building them

git clone radium && cd $_; makepkg -si

Teteros commented on 2018-05-10 10:09 (UTC) (edited on 2018-06-02 21:03 (UTC) by Teteros)

[MY PKGBUILD] radium 5.4.4 => radium 5.6.5

  • Added libtirpc as dependency as glibc no longer provides rtc.h needed by libpd. Used sed in this patch to avoid needing to unpack libpd in the PKGBUILD.

  • Fixed use-system-vstsdk.patch due to changes in upstream. Likely this will need to be checked again next radium update as there's vstsdk changes due in master.

  • LLVM...

LLVM39 has been dropped from community, AUR version does not compile (at time of edit).

LLVM40 currently compiles if tests are disabled. It takes a long to build so you can use my packages below if you trust them:

curl -OL -o && unzip -j $_ -d ${_%.*} && sudo pacman -U $_/llvm40-*.tar.xz

Teteros commented on 2018-01-12 07:32 (UTC) (edited on 2018-01-12 07:45 (UTC) by Teteros)

@j5lx I made a diff against the binary distribution of radium and the entire styles folder is included there.

I wanted to bring this package a bit closer to the official bin package because some features like pure-data (already fixed) and faustdev were missing files, preventing them from functioning properly.

If you're confident we can leave the other few files in styles out feel free to do so, I've played a bit with faust and noticed no problems with just the .lib files imported into the package, though the bin package of radium includes a bit of source files not needed to run it indeed.

5.4.6 is already out, you may want to bump the ver to the newest since radium updates so frequently :)

J5lx commented on 2018-01-11 20:43 (UTC) (edited on 2018-01-11 20:44 (UTC) by J5lx)

I wonder why you changed it to copy the entire Styles folder rather than just *.qss but still went for *.lib for the libraries. LGTM otherwise, I’ll try to find a moment to test and merge your changes tomorrow or on the weekend.

Teteros commented on 2018-01-07 02:10 (UTC) (edited on 2018-01-07 02:28 (UTC) by Teteros)

[AUR PKGBUILD] radium 5.4.2 => radium 5.4.4


Clone: git clone radium


Edits: More information on some comments and checksum update for the radium version bump.

My suggestions for this package:

1) Use llvm40 from AUR instead of llvm39 from Extra. This is because llvm39 conflicts with llvm, this creates problems on some machines. LLVM 4.0.1 is the last known version to work with radium's faust.

For instance on AMD, mesa's gallium/radeon driver requires LLVM on runtime, not only for make/compile. This means installing any other llvm than system llvm (that mesa is linked with) will cause errors on startup of any OpenGL or Vulkan application on systems that use Gallium accel.

(This explains my radium startup issues earlier which j5lx could not reproduce as my hardware uses the radeon driver.)

It seems to be a known issue and the llvm-dev mailing list has recommended either hacking the build script or linking LLVM statically:

Since llvm40 (AUR) is packaged so that it does not conflict with system llvm and llvm40-libs packages the dynamic .so as well as static .a libs, I've decided to use the latter approach.

radium and faust were patched to statically link to llvm40-libs, using llvm-config-4.0 Patch File: use-llvm40-static-libs.patch

The downside is that llvm40 needs to be compiled, which takes a while. Fortunately this is a one-time thing since newer LLVM versions are in extra.

I've looked into building radium without the faustdev instrument (so radium does not link to LLVM), but some kind of llvm is still needed to compile faust2 (which builds faust instruments for radium) Might as well compile with llvm if you need it to build I think.

A faust binary could be provided into the AUR package here, that is build with compatible LLVM, but I think that goes against AUR guidelines (build from source when possible)

2) Include .lib files from the faust distribution in package() Currently faustdev instrument can't even initialize without music.lib since that's the default line used in faustdev when it's added.

You can't do much without importing any .lib in faust either, as most signal processing functions are in the faust libraries for you to use in your synth/DSP.

.lib files from faust2/architecture should be bundled in the package (included in my PKGBUILD on gist)

urldog commented on 2017-09-16 12:55 (UTC)

This is what I'm getting now: AUR Packages (1) radium-4.9.14-1 Repo Packages (2) lld-4.0.1-5 llvm-4.0.1-5 Repo Download Size: 23.25 MiB Repo Installed Size: 156.95 MiB :: Proceed with installation? [Y/n] y :: Retrieving package(s)... :: radium build files are up-to-date -- skipping [sudo] password for quesada: :: Checking radium integrity... ==> Making package: radium 4.9.14-1 (Sa 16. Sep 14:53:45 CEST 2017) ==> Retrieving sources... -> Found 4.9.14.tar.gz -> Found radium -> Found use-system-libxcb.patch -> Found use-system-vstsdk.patch -> Found use-new-cxx11-abi.patch ==> Validating source files with md5sums... 4.9.14.tar.gz ... FAILED radium ... Passed use-system-libxcb.patch ... Passed use-system-vstsdk.patch ... Passed use-new-cxx11-abi.patch ... Passed ==> ERROR: One or more files did not t pass the validity check! :: failed to verify radium integrity --- Any idea why?

KenjiTakahashi commented on 2017-08-07 02:59 (UTC)

@Teteros: Thanks a lot for working on this! Especially for the faust/LLVM fix this time, I honestly couldn't make much sense of this problem ;-]. I've also changed to use a wrapper instead of a patch. Although that patch did what it was expected to, I don't understand the "else commented out" thing. But one less patch is one less patch. I only removed the LD_LIBRARY_PATH bit, there's no /opt/radium/lib dir in our distribution, so it didn't do anything. Added pure-data dir, too. Again, thanks for looking into all this.

Teteros commented on 2017-08-03 06:49 (UTC) (edited on 2017-08-03 06:50 (UTC) by Teteros)

To add to the last comment, pure-data dir is missing from libpd-master in packages. Needs to be installed to /opt/radium/packages/libpd-master/pure-data Otherwise pure data crashes when added in the mixer.

Teteros commented on 2017-08-02 03:39 (UTC)

@j5lx Hello again, issues for this to compile on latest git have been resolved. You may upgrade the package when 4.9.13 is released. The required patches are on my gist: Changes: 1) (Pull Req Merged, in master) LLVM 4.0.1 fix. 2) (Fixed, in master) Invalid Makefile target. 3) (New patch, use-new-cxx11-abi.patch) See above issue. I believe for compatibility with new gcc versions Kjetil has explicitly set D_GLIBCXX_USE_CXX11_ABI=0 in CXXFLAGS which makes gcc use the old CXX ABI. However this causes the faust package to not compile for us because LLVM in Arch repos has been build with the new ABI as per default in GCC5+. I've set the existing flags =0 in this patch, but more may be need to be set in later builds. 4) (Updated, use-system-libxcb.patch and use-system-vstsdk.patch) Patches were rejected due to file changes in upstream. PKGBUILD Suggestion: Kjetil looked through our patches (!) and suggested the empty lib paths patch shouldn't be emptied like done in dont-empty-qt-library-paths.patch as the "else" clause becomes commented out. I suggest we instead go with the wrapper approach like done in radium's binary release. One way... Remove the empty-qt-library-paths.patch and unsource/remove patch in PKGBUILD Include my from gist Change the install command in the PKGBUILD to install -Dm755 "${srcdir}/" "${pkgdir}/usr/bin/radium" This will remove the need for that patch and will run radium with arguments using the radium lib in /opt and system qt5-plugins.

J5lx commented on 2017-07-15 17:22 (UTC)

IIRC faust is quite picky about the LLVM version, so it will only accept 4.0.0 but not 4.0.1, we used to adjust those checks ourselves every time LLVM got an update before Teteros contributed that patch to upstream (see I’ll try to update the package soon™, but until then you should be able to work around that issue by compiling radium with llvm 4.0.0 which you can obtain from

actionless commented on 2017-07-14 19:22 (UTC) (edited on 2017-07-14 19:22 (UTC) by actionless)

@Teteros your patch seems to be merged already but i stil have problems compiling it with LLVM 4: make[1]: Entering directory '/home/lie/.cache/pacaur/radium/src/radium-4.8.5/bin/packages/faust2' make -C compiler -f Makefile.unix prefix=/usr/local make[2]: Entering directory '/home/lie/.cache/pacaur/radium/src/radium-4.8.5/bin/packages/faust2/compiler' Makefile.unix:121: *** "Unknown LLVM version 4.0.1". Stop.

J5lx commented on 2017-05-09 13:03 (UTC)

Yeah I use integrated graphics (Intel). I agree that it should not make a difference in theory, but if it does in fact happen I think it can be called a bug, be it in Radium, Mesa, LLVM or somewhere else entirely. It might be a good idea to consult somebody with a deeper understanding of the inner workings involved.

Teteros commented on 2017-05-09 11:53 (UTC) (edited on 2017-05-09 12:33 (UTC) by Teteros)

Do you by any chance have a non-radeon card? When I removed 4.0 libs the radeon/mesa opengl driver stopped working, but radium could start, although it printed an error that opengl is not working which is right of course. I was thinking of reporting it, but in theory only llvm39 should conflict with llvm, the libs packages are fine without the conflict array as they only provide the extra libs, rather than overriding anything. Anyway the fix is merged already (!) and in upstream 4.8.0 release, check it out when you can. EDIT: Merged in master but not in 4.8.0 yet.

J5lx commented on 2017-05-09 11:14 (UTC)

I still don’t quite get why that error occurs for you but not for me, even though I also have installed both 3.9 and 4.0, but if there is in fact some kind of incompatibility between those two versions of llvm-libs you might want to report a bug to the project (i.e. (I’d rather not report it myself because I can’t reproduce it and I still don’t really understand what happens). As for the patch, I don’t have the time/calm to review it properly right now so it’ll probably land in a few days or once it gets merged.

Teteros commented on 2017-05-09 03:11 (UTC)

TL;DR I patched radium's bundled faust to work with llvm 4.0, either grab the patch from here: and add this to the PKGBUILD (and source array) patch -d bin/packages/faust2 -p0 < "${srcdir}/0001-LLVM-4.0-support.patch" or wait for my pull request to be merged: Got the time to track this down, it appears the crash happens when you have llvm-libs from repo installed, which is the 4.0 version, this occurs because llvm39-libs does not seem to conflict with it, so I ended up with llvm39 and llvm39-libs installed (which is intented) as well as llvm-libs (4.0) Of course, this should work as ldd on radium shows it correctly links to lib, but for some reason it crashes for me with the 4.0 lib package installed. I ended up patching radium's faust to work with llvm 4.0 as without it, some important libs like mesa would have to be recompiled to work with llvm39.

Teteros commented on 2017-04-29 08:44 (UTC) (edited on 2017-04-29 08:45 (UTC) by Teteros)

Still occurs with your package build unfortunately. I'll snapshot my current partition, and do a fresh install to eliminate some linking or lingering cache/config from possibly interfering. Though you'd think a chrooted build would help if that was the case.

J5lx commented on 2017-04-29 08:09 (UTC)

Personally I don’t experience that at all. So weird! For now I uploaded my own build of the package at, could you try installing it and see whether the error occurs with that build as well?

Teteros commented on 2017-04-29 06:38 (UTC) (edited on 2017-04-29 07:03 (UTC) by Teteros)

Indeed 4.7.6 compiles without errors. However after I installed the build package and try to run radium, this is the output. $ radium JUCE v4.2.4 INIT4 INIT5 Executing -LD_LIBRARY_PATH= /opt/radium/crashreporter L3RtcC9yYWRpdW0uSjEyNjY4 PG5vcGx1Z2lubmFtZXM+ PG5vZW1lcmdlbmN5c2F2ZT4= is_crash&- QWidget: Must construct a QApplication before a QWidget Official x64 build runs without this error.

J5lx commented on 2017-04-28 20:18 (UTC)

The commit you mentioned is part of 4.7.6, so I suppose their is nothing special left to do for me. That aside, the package builds perfectly fine for me, both 4.7.4 and 4.7.6, so I’m a little curious as to what exactly you are referring to.

Teteros commented on 2017-04-27 21:15 (UTC)

New master: Allows it to build now, but I am getting "QWidget: Must construct a QApplication before a QWidget" on runtime with it, and 4.7.4

Teteros commented on 2017-04-11 20:58 (UTC)

You're right, on investigation: the extra files present in /opt/radium are actually the ones radium creates when it's able to at runtime (the 'warning' file import_midi/mod, python stuff, logs, autosaves...) Making whole .install file redundant, unless used for documenting.

J5lx commented on 2017-04-11 20:33 (UTC)

To address some of your points: - The reason I don’t want to see $pkgname everywhere is because one of the most common reasons for changing it is to have something like radium-git or radium-with-custom-patch-xy. In both those cases you're still e.g. installing files of a program called just Radium, and usually they are drop-in replacements for the original package rather than being meant for side-by-side installation, meaning that files would go to the same location (/opt/radium), too. I hope that makes sense the way I wrote it. - Regarding the user/group thing: Both transmission-cli and mariadb provide daemons running system-wide under their respective accounts via systemd (e.g. `systemctl start mariadb`). Radium however is not a daemon but a program run by end-users on their respective accounts rather than on a system account. - On my system, removing radium deletes /opt/radium just fine. Maybe you created some files in that directory yourself? Maybe autosaves? - I am going to test-build 4.6.8 now and if it works fine I'll push an update afterwards.

Teteros commented on 2017-04-11 20:07 (UTC)

Thanks for going through, and scrutinizing my changes rather than just merging blindly: - Somehow I missed that while researching about changelog() That makes a lot of sense now.As I wasn't sure why pacman/makepkg used the Changelog file before downloading/sourcing the source() array. - The sed lines were ment to reduce the high amount of one-liner diff .patch files we had in the previous PKGBUILD's. Though as I did them, I noticed they weren't even arch specific issues, so switched to making pull requests instead. I think the remaining .patch'a are matching lines very unlikely to be touched by upstream anytime soon, but I see your reasons. - Eh $pkgname was supposed to be a practical change thing, but the maintainer will propably vim/sed search/replace the name anyway if upstream changed it. See last point. - Giving a package its own user/group is standard practice whether it's an official package (transmission-cli: maria-db: or a popular self-contained aur package (jdownloader2) I'd agree however that, assigning ACL permissions to have /opt/radium in the 'audio' group is excessive, but there are benefits to have /opt/radium in radium:radium. Having said above, consider using the suggested .install file at least for the post_remove() function. The package as it is will leave /opt/radium lingering after package removal which might cause issues for the user when reinstalling the package at a later date. - The patch for this PKGBUILD was much bigger before my pull requests were merged, so I opted for changing the comsmetics as it looked like a different PKGBUILD either way. Though now that those changes got merged (!) my cut-down PKGBUILD looked weird and out of place compared to the old one. Having this comment way longer than I wanted... Thanks again for the merge, and I can confirm 4.6.8 builds fine with the current PKGBUILD, could you bump the version please? I'd say it's worth it as 4.6.8 introduces some long awaited features like sample-seek.

J5lx commented on 2017-04-11 18:43 (UTC)

Okay, so I just had a look at your changes and merged… some of them, because of this: - The $changelog field in the PKGBUILD is for changelogs of the package itself, not for changelogs of the packaged software. Software changelogs usually go into /usr/share/doc - We specifically opted to use patches rather than sed because sed lines broke on some updates in very subtle ways. Plus, it’s often harder to tell what exactly sed lines do. - Don’t use $pkgname excessively just because you can, use it when it makes sense – it’s not inherently synonymous with the software name. - I am absolutely not going to give write access to system directories under any circumstances unless there is a very, very, very good reason for it. Making a warning message disappear is not such a reason. - Generally, refrain from making lots of cosmetic changes since that makes review much harder Aside from that, thanks a lot for your efforts in getting those improvements into upstream (!) and integrating them into the PKGBUILD! So far, everything seems to work fine, so good job!

Teteros commented on 2017-04-09 05:30 (UTC) (edited on 2017-04-09 05:34 (UTC) by Teteros)

I've worked with upstream to update this package and make it more user friendly. Links Diff: Tarball: Related pull requests: Verified to compile on a clean chroot.

KenjiTakahashi commented on 2017-02-02 04:02 (UTC)

The problem reiterated for me and this time I was able to look at this in more detail. @pizzataco was mostly correct with his findings, but instead of crafting another part of a (primitive) package manager within a package (why radium's author is doing this is totally beyond me), I've patched it to use libxcb from [extra], which includes all necessary fixes. I also see the message about dir not being writable, but it does not appear to do any bad, does it? It would probably be best to check in the code why it might actually want to write into it's own dir, but, honestly, this code is total spaghetti. I kinda adore the guy for being able to keep it in a mostly working fashion, lol ;-].

J5lx commented on 2016-12-17 01:16 (UTC)

@pizzataco If all you want to do is build the package in a clean chroot you should have a look at archbuild: That’s what I use whenever I work on this package (IOW, it’s known to work) and I believe it’s pretty much the de facto standard for this task.

KenjiTakahashi commented on 2016-12-16 22:54 (UTC)

@pizzataco: I've written my own after getting annoyed enough by not being able to run makepkg as root anymore :-]. It's still quite hacky on the sides, so I've not released it to the public (yet).

pizzataco commented on 2016-12-14 07:06 (UTC)

So I encountered the same "tabs and spaces" issue when not using a clean chroot, the problem is from python3 I think. If you check out these patches over here: It is possible then to patch bin/packages/ from PKGBUILD to include these patches and build without chroot and install the package `pacman -U` style. However, once you start radium it gives a message that the folder it's in is not writeable by your user. @KenjiTakahashi what automated build tool are you using? I have always done things according to the AUR wiki page, which does not reference the technique.

KenjiTakahashi commented on 2016-12-01 19:28 (UTC)

I have an automated build tool that always builds in clean chroot :-). But I've triggered it manually to build again and... it went fine. Some transient problem? I don't know, but can't reproduce now, so sorry for the noise.

J5lx commented on 2016-11-30 23:03 (UTC)

That looks weird. For me it built just fine. My best guess right now is that it is somehow related to your system configuration. In that case building the package with archbuild (see should work just fine. I once had a similar issue where my system refused to build any OCaml packages because hardening-wrapper was installed (FS#42748). If archbuild doesn't solve it we'll have to dig deeper.

KenjiTakahashi commented on 2016-11-30 22:37 (UTC)

Don't have time to investigate right now, but I'm getting make[1]: Entering directory '/opt/radium/src/radium-4.3.2/bin/packages/libxcb-1.12' Making all in src make[2]: Entering directory '/opt/radium/src/radium-4.3.2/bin/packages/libxcb-1.12/src' GEN xproto.c File "./", line 1937 after_end_of_request = '(((char*)R) + R->length * 4)' ^ TabError: inconsistent use of tabs and spaces in indentation make[2]: *** [Makefile:1290: xproto.c] Error 1 make[2]: Leaving directory '/opt/radium/src/radium-4.3.2/bin/packages/libxcb-1.12/src' make[1]: *** [Makefile:788: all-recursive] Error 1 make[1]: Leaving directory '/opt/radium/src/radium-4.3.2/bin/packages/libxcb-1.12' make: *** [Makefile:455: bin/packages/deletemetorebuild] Error 2 trying to compile the newest version (4.3.0 worked fine).

J5lx commented on 2016-11-12 07:33 (UTC)

Update to 4.2.6 is currently blocked by an apparently missing file:

KenjiTakahashi commented on 2016-11-01 12:38 (UTC) (edited on 2016-11-01 12:38 (UTC) by KenjiTakahashi)

Thanks a lot for working on this, @J5lx! Unfortunately, my jack installation got buggered somehow, so I cannot test it much ATM, but it compiles and runs, so I'd call it's fine :-). Using patches is indeed a better idea, but sometimes I'm too lazy to do this. Most times these fixes do not last enough for it to be a problem, but here they often do, as we can see. Removed the SDK comment as not relevant anymore.

J5lx commented on 2016-10-29 22:31 (UTC)

@CrocoDuck Okay, I got the whole thing working now. @KenjiTakahashi You might want to unpin your comment about manually downloading the SDK now, since it's no longer relevant. I can't do that myself as a co-maintainer.

J5lx commented on 2016-10-29 17:11 (UTC) (edited on 2016-10-29 21:42 (UTC) by J5lx)

@KenjiTakahashi The platform plugin path error was caused by a wrong line number in the sed script in the PKGBUILD. I'm going to replace those sed lines with patches since those are a bit more robust when it comes to line number changes. I'm still looking into the other issues though. UPDATE: I just noticed that this platform plugin path error also affects other stuff like the crash reporter. I'll include those in the patch as well. UPDATE 2: argh why did they have to update clang just the moment I was going to finish this now I have to update the clang patch as well and REBUILD RADIUM FROM SCRATCH FOR THE UMPTEENTH TIME

J5lx commented on 2016-10-29 14:30 (UTC) (edited on 2016-10-29 16:09 (UTC) by J5lx)

I have now created the patch and it compiles just fine. However, when I try to run Radium, I get the error message reported by @esclapion. Using the command line provided by @KenjiTakahashi, I get the splash screen, but what follows are an error message and a (probably) unrelated crash. Since I haven't found time to update Radium in a while, I assume that this is not directly related to the system vst patch, but I'm still looking into it. For reference, the patch can be found here:

KenjiTakahashi commented on 2016-10-26 19:11 (UTC) (edited on 2016-10-26 19:13 (UTC) by KenjiTakahashi)

Yeah, I agree with @J5lx here. The main problem here (and the reason why this package was stagnant for a very long time in the past) is that upstream has refused to change the way he includes this SDK. There were several discussions on github and some ML (or sth, I don't remember exactly). In fact, I planned to look at patching it on our own as well, but no time now, sorry. If you'll find some time, @J5lx, please go ahead.

J5lx commented on 2016-10-23 17:21 (UTC)

Addendum: From a quick look, it looks like these are the file that we'd need to patch (in git master): - /, line 130 - /pluginhost/Builds/Linux/Makefile, line 41, and/or /pluginhost/MyPluginHost.jucer, line 19 - /Makefile.Qt, line 195 I don't have the time to actually do the patch and test it and everything right now, but I'll take care of it next friday or earlier if it's still a thing then.

J5lx commented on 2016-10-23 17:08 (UTC)

@CrocoDuck I don't know how @KenjiTakahashi thinks about it, but I'd rather not create any files outside of the build directory as part of the automatic build process. IMHO we should rather go for some downstream patching here, if anything. That would also make this package compatible with archbuild (I think).

CrocoDuck commented on 2016-10-23 14:41 (UTC)

Hi, thank you for your package! Just in case you didn't know, there is a Steinberg SDK package in the AUR: You could perhaps include this as a build dependency and link the required files in the prepare() function, like in here:

KenjiTakahashi commented on 2016-10-05 00:30 (UTC)

Sorry for a long delay, real life has got me for a while... Should be fixed now (also updated to latest version).

KenjiTakahashi commented on 2016-08-30 01:19 (UTC)

Ah, hell breaks loose again ;-]. I'll work on a proper fix later on, but for now you should be able to run it like this: QT_QPA_PLATFORM_PLUGIN_PATH=`qmake-qt5 -query QT_INSTALL_PLUGINS` radium

rmdes commented on 2016-08-29 18:44 (UTC)

I really tried to get "xcb" installed before letting a comment here but here it goes : Fatal: This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Read many threads on how to workout this issue with other platforms but I can't get it to work on arch. any hint ?

esclapion commented on 2016-08-29 12:38 (UTC)

Fatal: This application failed to start because it could not find or load the Qt platform plugin "xcb" in "".

KenjiTakahashi commented on 2016-08-29 12:03 (UTC)

Moved to Qt5, hopefully everything will work. Let us know if there are any problems.

KenjiTakahashi commented on 2016-03-10 21:35 (UTC)

That's fine by me. Most of the time it's not difficult, just bump the version and it works. But once upon a time it doesn't and the dev will probably not tell you why, so gotta figure that out and things might get strange. BTW: Already removed the hotfix mentioned earlier, it's fixed upstream.

J5lx commented on 2016-03-07 14:45 (UTC)

@KenjiTakahashi FYI, I'm a bit occupied with school work right now, so if packaging really is as difficult as you say I don't know whether I'll be able to actively contribute before March 17th (my deadline). But anyway, thanks for adding - I'll try to get up and running ASAP.

KenjiTakahashi commented on 2016-03-02 01:07 (UTC)

Updated and fixed symlink problem. @J5lx: I've added you as a co-maintainer. As, like I said earlier, the upstream maintainer cares little about us, he can change deps/building scripts/whatever without notice, so please make sure that a new release still works before uploading. Just saying :-). There is also a little compilation fix back ported from current master that should be removed with next version (provided that he doesn't break it again...).

KenjiTakahashi commented on 2016-02-24 00:11 (UTC)

FYI: The package currently cannot be built due to a bug in binutils package (see I'll come back to it when it's fixed (hopefully soon, Allan is on it already).

J5lx commented on 2016-02-14 21:21 (UTC)

3.6.3 is out. @KenjiTakahashi, if you feel unable to keep up with the release "cycle" of Radium, I'd be willing to jump in as a co-maintainer (or even adopt the package).

FreeFull commented on 2016-02-11 19:44 (UTC)

freefull@freefull-asus ~/A/radium> ls -la /usr/bin/radium lrwxrwxrwx 1 root root 54 Feb 11 19:27 /usr/bin/radium -> /home/freefull/AUR/radium/pkg/radium/opt/radium/radium* /opt/radium/radium does exist, but /usr/bin/radium ends up linking to the wrong place

KenjiTakahashi commented on 2016-02-08 23:14 (UTC)

Updated. Sorry for the delay and for not keeping it up to date, the upstream guy is spitting new number almost every day, it's not possible for me to keep up. Especially with him caring very little about info useful for packagers...

vasisualiy commented on 2016-01-20 13:27 (UTC)

The version is too old. 3.5.5 is actual one.

Nareto commented on 2015-01-27 11:53 (UTC)

working pkgbuild for 3.0.rc3 the package() is quite a hack, unfortunately "make install" is no longer supported, not sure why. Read the warning - you'll need to get the vst sdk version 2.4 from steinberg for compilation to work (see )

totalchaos commented on 2014-05-05 18:09 (UTC)

After reading the comments i guess the PKGBUILD needs to be rebuild anyway?

totalchaos commented on 2014-05-05 17:39 (UTC)

Will it be an issue if i use 'calf' as dependency instead of 'calf-kxstudio-git'?

Animtim commented on 2014-04-23 20:19 (UTC)

Here it didn't compile as I also have Qt5 installed, I added an extra "export QT_SELECT=4" before the make packages line and it works. Please add this to the PKGBUILD (or if there's a better way to do it..)

lievenmoors commented on 2014-04-17 19:07 (UTC)

Maybe the 'lsb-release' package should be added as a dependency, because radium is using /etc/lsb-release to decide for the name of the moc binary. There is a check for arch linux, but it didn't work because i didn't have that file.

Gimmeapill commented on 2014-01-11 10:23 (UTC)

1.9.35 is out:

DanielD commented on 2013-11-30 12:21 (UTC)

It crashes each time I try to open a PD patch. Anyone got this ?

frat commented on 2013-10-23 05:41 (UTC)

depends=('calf' 'liblrdf' 'libxaw' 'qt4''lsb-release') this will fix it.

frat commented on 2013-10-23 03:00 (UTC)

…… Makefile:1001: recipe for target 'qcolordialog.o' failed make: *** [qcolordialog.o] Error 1 …… Makefile:1006: recipe for target 'Qt_Bs_edit.o' failed make: *** [Qt_Bs_edit.o] Error 1 can not work out.

neuromancer85 commented on 2013-10-22 08:34 (UTC)

The build fails for me with this error: which: no moc in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl) Can not find moc. Make sure QTDIR and/or MOC is set correctly in the Makefile.