See the readme for installing Pd.

GEM should be at pd/gem

If you run GEM.INSTALL.sh, then all of the example files and documention should be put in the correct locations.

See the readme for installing Pd.

GEM should be at

chdir to /src/Gnu and build Gem following the instructions in the README.build (./configure; make)

If you then make install, then all of the example files and documention should be put in the correct locations.

if you are using debian, Gem should be available via apt

if you are using an rpm-based distribution, check out the builds at planetCCRMA

See the readme for installing Pd.

unzip GEM so that it is at

pd\gem

If you run GEM.INSTALL.bat, then all of the example files and documentation should be put in the correct locations.
(Note that you eventually have to edit GEM.INSTALL.bat to match your local directory layout.)

There is also an installer for windows.

For Windows 8 and 10 there is a missing dll that is needed for GEM to run. If your system doesn't have msvcr71.dll already then find it on the Web and install it in the pd\bin folder.

See the readme for installing Pd.

there is also an installer for macOS.

GEM is not an executable. It requires Pd to work and is loaded in at run time. For example, I have an alias on the SGI which does

/usr/people/mdanks/pd/bin/pd -lib /usr/people/mdanks/pd/gem/Gem

and on WinNT

\pdDir\pd\bin\pd -lib /pdDir/pd/gem/Gem

on UNIX-systems you will probably want to use a .pdrc file, where you can put the command-line arguments for pd that you "always" need.

If you don't see a startup message from GEM, then something went wrong.

Most people use use the command shell to start Pd. It is not very difficult to configure Pd to run from double-clicking on the icon.

Notice that the -lib flag always requires Unix styles slashes. This is the case even on Windows.

You may also want to use the -nosound flag. For instance, my PC has problems using audio (it leaks memory), so I just turn off the audio part of Pd. However, other people can't get GEM to work if the -nosound is used (on Win95). You can also try the -nodac or -noadc flags (for digital-analog-conversion only and analog-digital-conversion only).

Since Gem has a lot of external dependencies and there are a lot of different linux distributions, many of them providing different libraries, there are usually no pre-built binaries for Gem on linux.

Instead, you are invited to get the latest sources of Gem and build it yourself.

Getting the sources:

• if there is a source-package for a certain release, grab it, extract it, cd into the /src directory, and run
  • ./configure (optionally with some flags) and
  • make
• if there is no source-package available get the latest and greatest sources via CVS, cd into the /src directory, and run
  • aclocal,
  • autoconf,
  • ./configure (optionally with some flags) and
  • make

Download the Gem-installer and run it.

You should install it into the "extra/Gem" directory of your local Pd-installation.

By default this is: %PROGRAMFILES%\Pd\extra\Gem, which should be fine if you have accepted the defaults when installing Pd.

That's it.

available build environemnts

you should be able to build Gem either using autoconf or XCode

autoconf

coming from a linux background (and often running builds on remote machines), i personally prefer the "autoconf" build-system

this is also used for the Pd-extended autobuilds

setup for Gem-0.92.0

• PowerBook G4 running OSX 10.5.8
• FTGL/freetype2 have been compiled statically into a universal binary beforehand (by somebody; the URL is dead by now; i happen to have a local copy on my machine)
• all the rest seems to come with OSX
• i used autoconf (rather than XCode) with the following configure-line::

  PKG_FTGL_CFLAGS="-I/Users/zmoelnig/Development/pd-gem/GemLibs/FTGL/freetype\ include/ -I/Users/zmoelnig/Development/pd-gem/GemLibs/FTGL/include/" PKG_FTGL_LIBS="/Users/zmoelnig/Development/pd-gem/GemLibs/FTGL/mac/build/Universal/libftgl.a" ./configure --with-pd=/Users/zmoelnig/Development/pure-data/pd --with-extension=d_fat --enable-fat-binary

notes on OSX-10.6 (aka "Snow Leopard")

• since i only have a PowerBook, i cannot upgrade to 10.6 (which has dropped support for PowerPC)
• users report that compilation works fine when forcing the build to be i386 only (OSX10.6 has no legacy support for ppc; Gem has no support for x86_64 on OSX yet). for this to work you have to specify --enable-fat-binary=i386

Xcode

in build/osx-xcode you can find a xcode-project for Gem

font-support

you need FTGL (which in turn needs freetype)

for downloadable Gem-binaries it is better to have FTGL (and freetype) linked statically!

freetype

• get freetype-2.4.4 from e.g. sourceforge and unpack it
• ./configure --disable-shared --enable-biarch-config CFLAGS="-arch ppc -arch i386"
• make && sudo make install

FTGL

• get FTGL from sourceforge (i did a checkout of the SVN trunk; today this was revision 1266)
• ./configure --without-x --disable-shared --disable-dependency-tracking CFLAGS="-arch i386 -arch ppc" CXXFLAGS="-arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc"
• make && sudo make install

building Gem

these are the additional flags (rather environment variables) passed to Gem

• ./configure --disable-dependency-tracking --enable-fat-binary=ppc,i386 PKG_FTGL_CFLAGS="-I/usr/local/include/FTGL $(freetype-config --cflags)" PKG_FTGL_LIBS="-L/usr/local/lib/ -lftgl -lfreetype"

Building on W32 is a pain.

I happen to have a buildsystem running and try not to touch it, in case it breaks and i cannot create one again...

Visual Studio 2003

setup for building Gem-0.92

• AMD64 laptop running XP (sp3 i think)
• GemLibs: later check which version / incarnation
• compiled using the project for Visual Studio 2003 (see build/win-vs2003)
• installer is compiled using NSIS (build/win-nsis)

autoconf

in theory it should be possible to build Gem using autoconf on W32 using msys/cygwin

problems probably occur, due to the use of DirectShow for grabbing/decoding

OSX

on OSX you can change the path where a library is searched for with the install_name_tool

using the special path @loader_path, the path where the external lives will be searched

here's a small script to make all /sw/lib/ dependencies "local":

  for f in *.pd_darwin
  do
   otool -L ${f} | grep sw | awk '{print $1}' | while read i
   do j=@loader_path/${i##*/}
     echo $f $i $j
     install_name_tool -change ${i} ${j} ${f}
   done
  done

Here is the script that is used in the readanysf~ library for including lots of libraries using the above technique: embed-MacOSX-dependencies.sh

multi-arch binaries (aka "fat" or "universal" binaries) are only possible on OSX.

super simple solution:

• pass the --enable-fat-binary flag to Gem's configure. by default, this will create fat binaries for PowerPC (ppc) and MacIntel (i386)
• you can also specify the architectures, e.g. --enable-fat-binary=x86_64 will create a "fat" binary with one architecture (MacIntel 64bit)

using compiler/linker flags:

• add "-arch " (multiple times, if you need multiple architectures) to your compiler & linker flags; really, the super simple solution does exactly that behind the scenes
• e.g. adding -arch i386 -arch x86_64 to your CXXFLAGS and LDFLAGS will create fat binaries to run on MacIntel 32bit and 64bit

generating fat binaries from non-fat binaries:

• sometimes it is simpler to merge a number of non-fat binaries into a single fat binary
• using lipo for this:

      lipo -create <file1> <file2> <...> -output <file>
  

• e.g.:

      lipo -create ppc/Gem.pd_darwin i386/Gem.pd_darwin ia64/Gem.pd_darwin -output Gem.d_fat