RTMix
<< | table of contents
| >>
1. Introduction
Thanks for your interest in RTMix -- a real-time interactive multimedia art performance, composition, production, and coaching interface. The purpose of this manual is to provide you with the feature overview that will enable you to unlock RTMix's full potential. However, it needs to be noted this manual is a work-in-progress, so please accept my apologies for typo's and grammatical inconsistencies.
1.1 Disclaimer
RTMix
Copyright (C) 2001 Ivica Ico
Bukvic
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your option)
any later version.
This program is distributed in the hope that it will
be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for more details.
You should have received a copy of the GNU
General Public License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA.
To see the complete GNU license see 7.7. Alternately, you may want to visit the official GNU GPL website (http://www.gnu.org/copyleft/gpl.html) or read the license in plaintext format (COPYING file in the root of the install directory).
1.2 What is RTMix?
RTMix is an open-source (GPL-licensed) software application designed to provide stable, user-friendly, standardized, and efficient performance interface that enables performer(s) to interact with both the computer and each other in the least obtrusive fashion. What this means is that RTMix offers an array of visual stimuli that can be utilized on-stage in order to coordinate various performing forces utilizing diverse media.
1.3 What do I need it for?
How many times have you witnessed an interactive work that requires coordination between the composer and performer, composer usually being off-stage and posing as an aircraft navigator sending out all kinds of signals with waving hands and other distracting (perhaps even comical) physical gestures?
Have you ever questioned computer's off-stage presence when it has an important role in generating the resulting sonic landscape (or even a multimedia setting)?
Did you ever wish to have an elegant on-stage interface that is easy to use and furthermore provides the least amount of distraction for the performer(s) -- an interface that offers standardization, transportability, and most importantly low cpu-footprint, therefore enabling user to utilize majority of processor cycles for the stuff that matters the most -- the content-generation, processing and reproduction?
Have you ever wished to have your work more "transportable", to have it more accessible and more easily performable in settings where you were not physically available to provide technical support to the not-so-computer-literate performer?
Did you ever write a chamber acoustic work that required considerate amount of coordination but you did not want to use a conductor? How about a work for a large performing groups?
Do you use powerful Music-N languages for real-time work but do not have an elegant interface for real-time performance settings?
Are you a PD/Max/MSP/jMax object-oriented multimedia composer, but do not want to deal with designing the user-interface for your contraptions, nor with the lack of standardization such interfaces impose on end-users (i.e. performers other than the composer themselves)?
Did you ever feel like using only one multimedia tool at a time was limiting your creativity (i.e. Csound, RTcmix, Supercollider, Pd, Max/MSP, etc.) and that you always wanted to have multiple audio applications to coexist in your work?*
If you have answered any of these questions positively, then RTMix just might be the answer to your needs :-).
*NB: I am aware of the fact that this has been partially addressed by the recent developments in various software packages, such as embedded CSound objects for Pd and Max/MSP. However, in many cases such implementations are more limited than the models they emulate because often the two architectural designs do not have a lot in common and are therefore hard to port and/or adapt without taxing their functionality.