Linux Ubuntu 16.04 - exported standalone / plugins not starting

[andioak]

I made an instrument in HISE that I built/exported on Linux Mint 17.3, so Ubuntu 14.04 based. I exported both Standalone and Linux VST. When I try it out in Mint 17, the one I built it on, it starts fine and runs perfectly, no crashes or nothing.

Build-tech: Designed in OSX 10.13, Xcode v8.3, Built on Mint 17.3 with Scriptnode 2020-08-02. No issues at all on anything built on mac.

In Ubuntu 16.04 (LTE, fully updated, Ardour running on it) it does absolutely nothing. It does not start, and only occasionally produces an error report, linked here as an image:

Image of error starting standalone on ubuntu - image

Images of Reaper vst crash / blacklisted in Ardour - image 1 + image 2

Under Ubuntu 16.04 I tried the standalone and the vst plugin. The plugin was tested in a Ardour 6.5 and Reaper 6.14 that both black-list the plugins immediately.

---

I tried these things:

• Terminal commands: run /path/to/file, cd /to/place/of/app (next line:) ./app-name as you would start an app that is an executable like this is. A few others too. Nothing.
• Then I tried making a .desktop file like my-app-name.desktop containing the same file headers as the Ardour version, THAT made something happen, started a jumping icon in the dock, but still the same error report as above. :/
• Permissions and ownership was changed on the files using chmod -v 775 and 755, 777, nothing there either. Then also chgrp to change the root root to root staff, still nothing. Restarting did not help.
• I installed everything with the initial Admin account but, which Ardour did not support, but Ardour still works fine. Reaper too.

---

Real time support - potential reason

Read up on Audio for Linux and Real-Time threads seem to be a problem on non-specifically-audio-enabled systems. Ardour installed JACK, but had some issues but is running fine and can load plugins of it´s own. Perhaps this will run fine in another OS which i´m now trying, Ubuntu Studio and AV Linux. Stil, it´s a bit eerie to not have an idea about the issue here.

What makes me hopeful though is that I tried the CollaB3 organ and it had the same issues. No dice in ubuntu on any user accunt in any situation.

You guys had the same results?

[d.healey]

@andioak Did you try building the plugin and standalone on Ubuntu 16.04 too?

[andioak]

@d-healey No, that should not be necessary, right? I Used an Ubuntu based (earlier ubuntu) version, Mint 17, to do it.

Is there a package list to tell the user to install with HISE outputted instruments? Never saw it in that case.

[andioak]

@d-healey However, if JACK or other drivers are not okay, or RT issues exist, it might be the reason. My bet is either dependencies or permissions/ownership.

[d.healey]

@andioak It shouldn't be neccessary but since that OS isn't working for you it might be a good idea to compile on that OS to check.

Can you send me the standalone and I'll test it on my system? I'm running Debian Buster which is later than Ubuntu 16 but should still provide some useful info.

Are you testing a debug build or release build?

[andioak]

@d-healey Release build. Never tried a debug. But I´ll send you a copy for testing, thanks a lot! Perhaps the compiler from your video (or the version apt installed in the end is too new)..

[d.healey]

@andioak Debug is better for... debugging :p You'll get more useful error messages/crash reports.

[andioak]

@d-healey hahaha, got it. Will test a debug as well. But perhaps my compiler needs to be another, an older one or different? Perhaps Debian 10 is to be preferred for all debian based OS:es? It´s the origin after all. And then do another for Arch, on actual Arch or Manjaro.

[d.healey]

@andioak Debian 10 is the latest stable. Ubuntu 14 is Debian 7 I believe.

[andioak]

@d-healey so too new then. Would have worse backwards compatibility. Linux should be called "distro-wars" instead :)

[andioak]

@d-healey said in Linux Ubuntu 16.04 - exported standalone / plugins not starting:

Can you send me the standalone and I'll test it on my system?

Just sent a folder for testing. PM.

[d.healey]

Both the standalone and VSTi (in Ardour) work on my computer so I suspect the problem is with your Ubuntu 16 system rather than your Linux Mint 17 system.

[andioak]

@d-healey Lovely to hear! I love when it´s just me, especially regarding instruments I build that for unknown reasons dont run on my own systems hahaha.

So that´s great, but I think HISE / JUCE may have set the bar a bit too high/low. In regards to CPU support. It seems that my Iintel Xeon X56xx system was too old for it. That´s in spite of it being 4 generations newer than the first one using SSE 4.1 instructions, that has been mentioned in the docs as being the requirements of a CPU that can be supported without "Legacy CPU support" in the settings.

This is the same processor/cpu that was in the Mac Pro models. So I´m worried about support for very normal studio computers out there, if you don´t set legacy cpu support to true.

But I´m gonna try to reproduce my plugin toady with legacy cpu support, cause if it won´t run on a Mac Pro, any 64-bit model, it feels a bit limiting.

[d.healey]

@andioak Xeon X56 supports SSE3 and SSE4.1 so it shouldn't require legacy support. Legacy is really only needed for old AMD chips as far as I know. Let me know if legacy gets it working for you though.

[andioak]

@d-healey I know, but we are not using only those, we are using JUCE 5 that require and needs AVX, or at least makes use of this newer instruction set! The docs should be updated here.

Here´s an issue in JUCE forums, talking about instruction sets and how to deal with them.

The JUCE docs don´t seem to include any complete list of what functions/features require or use what instruction sets. But since it´s extensible, perhaps @Christoph-Hart used other libs that require more? Or the instruction set was not documented past JUCE v4.x. Either way, the specs of JUCE are fishy at this point. Check out my forum post on JUCE forums and see what people are saying about this.

AVX was introduced in the Sandy Bridge set, so the Mac Pro 4.1 is the earliest you could run it on. Not sure about the instruction sets introduced in Ivy Bridge (my macbook pro 2012 model for example) if that may even be the requirement for default settings. Seems that you can add flags though for -AVX etc.

It also seems that having the Projucer´s setting "Architecture" set to "native" gives you the enabled instruction set of your build computer. So if it has AVX or even AVX2, your product will not start on any older model. So if you got a v4 xeon, you can forget about selling to even Mac Pro 6.1 "trashcan" customers, because that one has an old Ivy Bridge cpu, Xeon/i7 v2.

Not sure what "legacy cpu" is setting it down to, but it´s probably better setting the flags in the Projucer to specify maximum vector instruction sets.

[d.healey]

@andioak Are you setting the architecture to native?

[andioak]

@d-healey checking that out. But it might be set by HISE upon export, although that would of course perhaps depend on the setting in the Projucer that built my HISE itself, right?

[d.healey]

@andioak Shouldn't be affected by your HISE build

[andioak]

@d-healey I tried my plugin on my build system on Ubuntu instead. Moved the hard drive over. It works and so does the CollaB3. Phew... so it´s not just me who´s misunderstanding 'chmod 755' :) Good to know.

Building my app for older CPU:s but still retaining usage of newer instruction sets, from juce extra flags in the "architecture" setting in the Projucer. The problem is that Projucer does not have a setting for custom Architecture flags, doesn´t have a label to fill in there, so figuring out how that works. So...

@Christoph-Hart Is this the proper way to set the exact cpu-type / generation of computers? :

With this GNU/GCC compiler flags doc you can then use the desired CPU-type as your desired target, setting compiler flags to put into the Projucer (.jucer) -> Exporters -> Linux Makefile is like this:

Will that work for HISE? I am using g++ on linux here.

Update: after some more reading, -mtune=cpu-type is the thing to use, as -march docs say:

"... the compiler does not generate any code that cannot run on the default machine type unless you use a -march=cpu-type option. For example, if GCC is configured for i686-pc-linux-gnu then -mtune=pentium4 generates code that is tuned for Pentium 4 but still runs on i686 machines."

The unnecessary optimisation is not what I want though, so maybe just specifying all sets I don´t want to use and that wont run on Nehalem (45nm Mac Pro 3.1 at least. ), like so:
-mavx
-mavx2
-mavx512f

Except for the amount of sets available... :/ WIll have to check with JUCE docs for the highest used set.

(I realize that the normal setting in "debug/release" will have to be set to "architecture: none", or will this simply override it?)

[d.healey]

Did you try compiling with legacy mode enabled?