Linux public beta (4408)

Official support for: u-he.com
Locked New Topic
RELATED
PRODUCTS

Post

If I understood you correctly, you're talking about Zebra. I think you need to configure (switch off) the focus stealing prevention in your desktop environment.

Post

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.
I created PKGBUILDs for Hive, Podolski and TripleCheese, for all those Arch Linux users out there.
https://aur.archlinux.org/packages/uhe-hive-vst/ (https://aur.archlinux.org/packages/uhe-hive-vst/)
https://aur.archlinux.org/packages/uhe-podolski-vst/ (https://aur.archlinux.org/packages/uhe-podolski-vst/)
https://aur.archlinux.org/packages/uhe- ... heese-vst/ (https://aur.archlinux.org/packages/uhe-triplecheese-vst/)

Make sure to follow the post-installation instructions which instruct you to copy the presets from /opt/Hive/Presets/Hive/ to ~/.local/share/Hive/ if you want to use them (and same with the others). The Arch packages try to better follow the XDG directory standards (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html), hence the use of ~/.local/share instead of ~/.u-he (which also avoids some technical limitations).

I don't plan to make packages for any of the other non-freeware synths (Hive is the only one which I own a license to). But so far, there seems to be enough similarity amongst the u-he plugins that one could pretty easily adjust the uhe-hive-vst package for the remaining plugins.

Post

@phantom-one yes it s about the zebra2, sorry that i havent been clear!

I switched off the focus stealing, still the same, but havent rebooted yet /(will try that now..)

@wallacoloo thanks for the links i ll try that right now! I installed all the demos from the script in the first post of this thread.. but I ll check if it will work better like that..

Post

I get this error when i try to install Podolski via yaourt:
-> Extracting Podolski-3965.tar.gz with bsdtar
==> Starting build()...
File 'Podolski.64.so' contains strings equal to '%s/.%s/%s/Data':
/tmp/yaourt-tmp-kalimerox/aur-uhe-podolski-vst/./PKGBUILD: line 45: xxd: command not found
also the other problem persists although i switched off all the focus stealing options etc..

another thing: in the start screen for "purchase" and "license info" etc, I also cant click anything /fill out the form etc...

Post

calimerox wrote:I get this error when i try to install Podolski via yaourt:
I've updated the PKGBUILDs to pull in the right dependencies automatically - thanks for catching that one.

Post

cool, they installed smoothly!!

with all plugins i have the same problem: They all work great, but any pop up text or menu, i just cant click on them.. before they disappear.. might be still the same problem with xfce in manjaro ;(

edit: i just checked with bitwig-studio, and everything works fine within manjaro, strange.. so it might be the gcc5 version of mixbus as a host.. anyone having a similar behaviour?

Post

calimerox wrote: with all plugins i have the same problem: They all work great, but any pop up text or menu, i just cant click on them.. before they disappear.. might be still the same problem with xfce in manjaro ;(

edit: i just checked with bitwig-studio, and everything works fine within manjaro, strange.. so it might be the gcc5 version of mixbus as a host.. anyone having a similar behaviour?
I checked ACE and Hive in the latest Mixbus (64-bit) on Fedora 21. Xfce is the WM, I had no problems with the pop-up stuff, e.g. mode selector or voices selector. The menus display properly, I could make selections from them without problems.

However, I have a different problem with Mixbus and the u-he plugins. I have half a dozen u-he synths installed, but Mixbus sees only ACE and Hive. Are yours found and listed correctly by Mixbus ?

Best,

dp

Post

hi dp,

yes they are found correctly, when i go to the preferences - plugins and add the u-he plugin folder which is a hidden folder in your home folder (.u-he)

thanks for the feedback. i also talked with people on the ardour mailing list and got no new clues, it s strange...

I guess it must be connected to my desktop system (xfce) in combination with mixbus/ardour, because i experience the same behaviour on two different machines (one using proprietary drivers, the other dont..) and only with mixbus, it runs fine on bitwig....

Post

Hi,
Will there be a Linux version of Repro-alpha?

Post

please delete

Post

wallacoloo wrote:I created PKGBUILDs for Hive, Podolski and TripleCheese, for all those Arch Linux users out there.
https://aur.archlinux.org/packages/uhe-hive-vst/
https://aur.archlinux.org/packages/uhe-podolski-vst/
https://aur.archlinux.org/packages/uhe- ... heese-vst/

Make sure to follow the post-installation instructions which instruct you to copy the presets from /opt/Hive/Presets/Hive/ to ~/.local/share/Hive/ if you want to use them (and same with the others). The Arch packages try to better follow the XDG directory standards, hence the use of ~/.local/share instead of ~/.u-he (which also avoids some technical limitations).

I don't plan to make packages for any of the other non-freeware synths (Hive is the only one which I own a license to). But so far, there seems to be enough similarity amongst the u-he plugins that one could pretty easily adjust the uhe-hive-vst package for the remaining plugins.
Hi wallacoloo,

This is very impressive! I'm quite surprised that you managed to get it to work. Great job. Don't forget that using the packaged plugins, makes you implicitly agree the license.

Did you think about making one PKGBUILD, which creates a package for each plugins? Maybe it is less work that way (and all plugins are covered)? You may also want to package Repro, Protoverb and Zebra2 as it contains the free Zebralette.

I'm open to change the default installation paths of the u-he plugins & data, and make it more friendly for a "packaged" installation. But those paths have to be set in stone and defined as a standard by the community.

Yet I don't like the idea that a path depends on an environment variable as it can be with XDG, because the path can be different from one shell to an other. Then, it becomes harder to help each other if everyone use different path.
Last edited by abique on Thu Apr 07, 2016 12:56 pm, edited 1 time in total.

Post

Hi,

I did update the plugins to the revision 4408!

It brings Repro to the collection, new presets for Podolski: TUC and initial VST3 support.

Be aware that Presswerk vst id changed.
Please read http://www.kvraudio.com/forum/viewtopic ... 1&t=459412 for more details. If you want to downgrade Presswerk to the previous version, you can use this one: Presswerk-3965

Enjoy!
Alex

Post

Phlox.s wrote:I use Bitwig 1.0.7
Update, my friend, update. :)

Best,

dp

Post

abique wrote:I did update the plugins to the revision 4408!
Yes indeed you did. Abique remains Da Man !

Thanks again, Alex, and of course great thanks and props to the crew at u-he.

Best,

dp

Post

abique wrote: Don't forget that using the packaged plugins, makes you implicitly agree the license.
Good point. I'll have the PKGBUILD print out the license before installation & look into what Arch's standards are for non-open source licenses.
abique wrote: Did you think about making one PKGBUILD, which creates a package for each plugins?
I considered creating a single package that contains every plugin. But it would have been very large, so I think it's better to split them up into separate packages. Also, since most of these plugins require a license, the user would end up with a lot of plugins that they just have to remember not to use, which adds noise to e.g. most DAW's plugin choosers. All the PKGBUILDs are identical except for 2-3 lines at the top which specify the name of the package, etc. I'm not sure if it's possible to get better code reuse across the different packages.
abique wrote: I'm open to change the default installation paths of the u-he plugins & data, and make it more friendly for a "packaged" installation. But those paths have to be set in stone and defined as a standard by the community.
I think the biggest improvement is to just use relative paths in some locations. For example, if hive.so is located in /some/directory/hive/hive.so, then it should look for all of its read-only data via a relative path: instead of looking for ~/.u-he/hive/Data, it should just check in ./Data (i.e. /some/directory/hive/Data) and its modules should be loaded from ./Modules (i.e. /some/directory/hive/Modules). This way it will work when installed into ~/.u-he/Hive OR /opt/Hive, etc. Better still would be to use ./lib, ./share directories, etc, but a packager can still work with the previous form and fit it into the standard unix directory tree using symlinks.

Only data that needs to be modified at runtime (e.g. presets, Support files) should be loaded from an "absolute" ~/.u-he path (this is a permissions thing, since a normal process can't write to any of the standard installation directories). That way the plugin can still be installed system-wide.

abique wrote: Yet I don't like the idea that a path depends on an environment variable as it can be with XDG, because the path can be different from one shell to an other. Then, it becomes harder to help each other if everyone use different path.
I have no problem with using ~/.u-he for all the support files/presets (i.e. anything that needs to be modified at runtime). The reason I couldn't put them here in my package is because the vst plugins depend on the ~/.u-he/<plugin-name>/{Support,CCMaps} folders already existing - they will crash if one tries to open the gui without the Support directory existing, for example. A package can't create a user directory, since packages are installed system-wide rather than per-user, so I changed it to ~/.local/share because one can mostly rely on that directory already existing and hence, the vst will work out-of-the-box.

If the vsts were to create ~/.u-he/<plugin> and all folders within it at the time they are loaded, that would resolve that particular problem, and the Arch PKGBUILDs could use the default ~/.u-he/<plugin> directory instead.

Locked

Return to “u-he”