Grand Orgue fails to load in LINUX MINT 17.3 32-bit

I only provide precompiled binaries for the major distributions - for any other you need to compile yourself.
GO requires cmake >=2.8 and wxWidgets >= 3.0.2 installed. Mint seems to be Debian based, recompiling the debian packages (via dpkg-source -x .., dpkg-buildpackage -rfakeoot) should work.

If you want a lean solution for GO PCs, look at GOLive https://sourceforge.net/p/ourorgan/dis…hread/7cb70c40/

The GrandOrgue binaries for LinuxMint 17 (which is a debian via Ubuntu linux distro) are available from the standard repositories and installable through the 'Synaptic Package manager' as well as the LM 'Software Manager'. Although I have also built GO from source I don't bother doing that anymore and use only the repository versions, currently in LM 17.3. I know that having only 3 gigs of RAM will cause problems with almost any sample set I have tried, and in fact I bumped up the RAM in my VPO computer from 8 gigs to 16 gigs because some of the larger (and best) sample sets couldn't be used with only 8 gigs of RAM.
I am using a computer with a 64 bit processor but if you are running a 32 bit LM then the package manager should install the proper version. I assume you have a 32 bit processor because it only makes sense to use 64 bit linux on 64 bit processors, although you can run 32 bit linux on a 64 bit processor. It is also possible to install 32 bit versions of software in a 64 bit system but that involves also installing various 32 bit and compatibility libraries, and in most situations that makes no sense.
It would be helpful if you expanded a little by what exactly happens when you try to load GrandOrgue, so does GO itself generate error messages (in that small window)? You might also get insight into the problem by looking at the log files in '/var/log', such as 'dmesg'. As well, if you normally launch GO from a menu try it instead from a terminal/shell because that will show error messages that you normally don't see when launching from a menu. In the repository version the GrandOrgue binary is in fact 'GrandOrgue' (in '/usr/bin') so typing that at a prompt in a shell will launch it (or attempt to launch it). Another check is to navigate in a shell to '/usr/bin' and type 'ldd GrandOrgue' (obviously without the single quotes) and check in the output any line that has (I think it is) "not found" or something similar. On my machine that produces a long list of the libraries GO depends on, and that does include for example the 'jack' libraries, which are not installed by default but are needed by GO, even though I have found that the 'jack' server does not have to be running to get audio working with GO.

A 32 bit GO is limited to 3 GB address space. The system places the various libraries, the GrandOrgue binaries and other stuff at various locations. Only remaining, fragmented address space is available for samplesets The memory mapped GP cache is further limited to the largest contiguous memory region.

A 64 bit GO supports a much larger address space and is therefore not affected by these limits.

If the loaded sampleset size grows somewhere beyond 2 GB, a 64 bit GO will provide a benefit even on computers with small memory sizes.

PS: Don't forget to adjust the memory limit in the GO settings, if you add memory.

Technically 32 bit operating systems are constrained to 4 gigabytes of memory, but that includes more than just the RAM that most people consider synonymous with 'computer memory'. For example better video cards have onboard graphics RAM and that is included (but not at 1-to-1) in the 4 gig limit, along with a few other parts of the computer system, so although '3 gig' is often listed as the maximum usable RAM in 32 bit operating systems if you have really high end video card(s) in your computer your actual usable system RAM (so what GO can actually use) can be even less than 3 gigs.
I have built and run GrandOrgue on a Raspberry Pi 2 Model B on which I installed the Raspian operating system (a derivative of debian). That Pi model uses an Arm processor so it is 32 bit but the default processor speed is only 900 MHz and it comes with just 1 gig of RAM (not expandable). I could build GO (you must be very patient in waiting for the compiling to finish) and it is possible to use the smallest samples sets for GO but I would not consider the Pi 2 Model B to really be useful for a VPO. There is now a newer Raspberry Pi with a 64 bit processor and higher processor speed but it is still limited to 1 gig of RAM so unfortunately not much use for GO.
The original poster does not specify what he meant by "...cannot get Grand Orgue to load" so it may indeed be simply inadequate RAM and that cannot be solved on a computer with a 32 bit CPU, or with a 32 bit operating system running on a 64 bit computer.

Here is output response from TERMINAL -

/usr/bin $ GrandOrgue
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started

MidiInJack::initialize: JACK server not running?

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started

MidiInJack::initialize: JACK server not running?

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started

MidiOutJack::initialize: JACK server not running?

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started

MidiOutJack::initialize: JACK server not running?

Illegal instruction

NOTE: On my other machines Grand Orgue runs fine without JACK.

Is your computer SSE3 capable (cat /proc/cpuinfo)?
My default GO builds are optimized for SSE3.

Zitat von DFSpencer

Technically 32 bit operating systems are constrained to 4 gigabytes of memory, but that includes more than just the RAM that most people consider synonymous with 'computer memory'. For example better video cards have onboard graphics RAM and that is included (but not at 1-to-1) in the 4 gig limit, along with a few other parts of the computer system, so although '3 gig' is often listed as the maximum usable RAM in 32 bit operating systems if you have really high end video card(s) in your computer your actual usable system RAM (so what GO can actually use) can be even less than 3 gigs.

Graphic RAM only reduces the system RAM, if you uses an onboard graphic card without its own RAM.

Modern OS like Linux use virtual memory. A 32 bit Linux process is limited to 3 GB of user address space [and 1 GB for ther kernel]. Each process space can map different parts of the available memory and PAE allows map pages from more than 4 GB on a 32 Bit OS.
So on a 32 bit PAE-enabled Linux, you could eg. run concurrently 3 distinct GO processes each with a 2 GB sampleset, if you have >= 6 GB of RAM. That might be useful for other purposes, but not for GO.

I would recommend a 32 bit GO only for non-64 bit capable hardware and with less than 2 GB of RAM.

Zitat von DFSpencer

There is now a newer Raspberry Pi with a 64 bit processor and higher processor speed but it is still limited to 1 gig of RAM so unfortunately not much use for GO.

The PI 3 distributions are still 32 bit [If there are no essential non-opensource parts, a 64 bit distribution could be created by the community].