1.2. Why Another Visual Patching Language for Music?

This question should really be "why do all music languages end up being visual patching languages?" The visual-patching paradigm actually has its routes in signal processing textbooks and early analog hardware (i.e., analog synthesis, analog computers, etc.) and is thus a natural means for expressing constructs that are ultimately signal processors and controllers. Even systems that originally started out as text based, such as Csound, now boast visual front-ends.

OSW has a similar history, starting out as a collection of highly-optimized C++ classes with a framework that was quite different from other real-time music systems. It included scripting interface that eventually incorporated a visual patching interface. However, OSW has attempted to push the envelope and make visual patching easier to use through features such as gestural editing. These features were developed from useability tests. Although there is still a lot of work to be done in this direction, the emphasis on increased useability is a key differentiating factor.

1.3. How is OSW different from Max/MSP, Pd or jMax?

One of the most frequently asked questions! Max/MSP, Pd and jMax are all descendants of the Max system developed by Miller Puckette and others at IRCAM in France. These systems have been used successfully in computer-music compositions and research projects for a long time. Among computer musicians, they have also been synonymous with the visual patching paradigm.

OSW started out as very different beast, emphasizing optimzed high-level C++, extensible type system, ease of adding features, and a flexible real-time scheduler. It adopted the successful visual-patching interface for reasons outlined in the previous question.

More information on the history of OSW can be found at http://osw.sourceforge.net/oswhistory.php