## Introduction

GEM is the Graphics Environment for Multimedia. It was written by Mark Danks to generate real-time computer graphics, especially for audio-visual compositions. Because GEM is a visual programming environment, users do not need any experience in traditional computer languages.

GEM is a collection of externals which allow the user to create OpenGL graphics within Pd, a program for real-time audio processing by Miller Puckette (of Max fame).

There are many different shapes and objects, including polygonal graphics, lighting, texture mapping, image processing, and camera motion. All of this is possible in real-time without any previous programming experience. Because GEM is an add-on library for Pd, users can combine audio and graphics, controlling one medium from another.

GEM is supported in part by a grant from the Intel Research Council for the The Global Visual Music project of Vibeke Sorensen, Miller Puckette and Rand Steiger.

An important thing to remember is that GEM is NOT an application. It is a library that Pd loads at run-time. Make sure that you see the section on using GEM with Pd. This manual assumes that you have Pd working correctly and can load up patches already. If you do not have that working yet, look at the Pd manual and the GEM FAQ. Also, it is assumed that you have a basic understanding of how to use Pd and the idea behind the data flow model. In other words, if I ask you to pass a message with 3 floats into an object, you would know what I mean.

The system requirements vary depending on your system and what you are trying to do. In general, you should have the most powerful computer available and the best graphics accelerator on the market. In reality, people have been doing some amazing work with a Pentium II and an nVidia Riva TNT or 3Dfx Voodoo2 card. If you are on an SGI, then everything from an O2 up seems to be okay. The biggest requirement is that you have some kind of OpenGL graphics accelerator. This means that a Matrox Millennium II will not run very quickly.

The other factor is what you are trying to do. Pushing real-time video around requires a fast bus, which really only exists on SGIs. Doing thousands of texture mapped polygons is great on a PC...if it is a constant texture. There are many issues which mean that there is no one answer to "Is this system good enough?". In general, you will have to try and see.

[return]