o m b O S

max/msp, simon2002-2011, current vers.2.1

The ombOS Concept

It is long practice, partly based on a still perpetuated myth, that electric and electronic devices are (and according to mainstream design-rational should be) presented as a kind of miracle, that e.g. when you actuate a switch here, then magically an effect is triggered somewhere there. Of course nowerdays this trick is not regarded magic in a physical sense, but it still has a certain appeal to enable the owner & master of a device, to instanciate a difference - an effect - with the snip of a finger.

For an instrumentalist it is increasingly part of the (show-)business to present a performance as magic and with the advent of electronic generation and control of performance, it can be alluring for the instrumentalist himself, to let himself be trapped by the magic of disconnected cause and effect.

The causes and effects in electronic music are the ins&outs of signals between processing units.

So, particularly in a performance-situation where you need to have a continuous workflow, devices or software have the character of a black-box with cables going in and out and switches, that allow to control their behavior.

Usually it suffices to hardcode a certain setup for a performance - at least that is what most electronic performer do. My programming- and documentation-work has the purpose to work out more general instruments, that have to proove that they are capable of surving the requirements and special adaptions of a number of different performances. And in particular this workstyle has to be regarded as a research approach to electronic instrument design in general.

experimental purposes to explore extensive multi-medial representation of diffenent aspects of the performance.

I was getting used to the fact that every interaction (breath-control a tone) involves parameter-changes.

to see the changing values - as in the in&out-panel - is enlightning for some moments, but after a time it gets uninterresting, because the main feedback-channel - the main purpose is the auditive output.

perhaps i should invest a little bit in the presentation of these values, create representations that can be grasped a bit more intuitively.

This is not a program to be used once a week or month, but daily. The target group is myself. Or someone like me. So most important is immediate access. Therefore the hierarchy is flat. I saved a lot of screen-space that descriptors would occupy (but hinting the mouse over a control will show up its name).

A great deal of ombOS is concerned with the integration and control of different pieces of hardware.

The interface consists of a main panel and several specific instrument-modules: two hardware and three software-synths, a mixer/recorder, an elaborated metronome, an audio-looper, a midi-looper, a grafical sound analyzer, an in/output-modul and some minor extensions. Every modul-panel can be opened seperately (or even standalone), the main window allows to control the integrative features. The interface looks packed with controls and may seem too complex to be used intuitively, but this is not my experience in many years of usage. I find the interface well structured and I can arrange a set of panels, that fits the needs of most working/performing situations.

The main panel is a kind of wrapper of modules: it integrates these modules and features a sophisticated preset management system that allows to define and recall combinatoric settings.

The moduls are defined in a way that they can be used also standalone (to avoid to work on several versions of a modul) and in a way that changes do not require to touch modules they are connected with.

uea-io.de/wax