Reactive programming in OM is an intermediate model for visual programming inheriting both the off-line, demand-driven, computation paradigm of OpenMusic, and the reactive features of interactive/real-time systems. The objective is to integrate and control the interactions between the calculi denoted by CAC programs and their external context. In this model visual programming components are capable of "listening" to the environment or to other components, updating contents or triggering calculations accordingly, and propagating changes in a determined way in the program. This "dataflow-oriented" approach implies new semantic definitions, implementation and corresponding user interactions. It is based on the existing OM semantics and conservative with regard to this semantics, so that existing programs created in the environment remain valid in the reactive framework.
Implementations of the OM reactive model are available
- as a prototype library to load on top of OM 6.7/6.8. ⇒ [Download]
- an a native feature in OM >= 6.9
- Select boxes and type 'r' to set their reactive status on/off.
Reactive boxes are displayed with a coloured frame. Note that at the moment, not all boxes can be made reactive.
- Any modification to a reactive box will propagate downstream to the connected boxes that are also reactive.
Modifications can be:
- Evaluation ('v') [⇒ the box has a new value]
- Edition in the graphical editors or in the text field (for simple value boxes).
- Modification of an input value
- Action of an "interface" box (e.g. slider, etc.)
- External update (e.g. receive boxes – see below)
- Reactivity applies to the first-order visual program, that is, not inside the sub-patches. A sub-patch (even if it contains reactive boxes) is still considered as an atomic function in the reactive context.
- In order to check what is going on, you can use a reactive print or text-box and connect it to your patch.
Reactivity can make particular sense for receiving data from external applications and updating/computing OM visual programs accordingly.
- Set an osc-receive or midi-in (OM 6.9) box reactive and the data will be propagated at every incoming message.
This feature is compatible with the existing "lambda pre-processing" of incoming messages.
Note: OSC-receive/MIDI-in might need to be turned off and on again if an error occurs during the propagation of an incoming event.
- The route route-osc boxes can help routing incoming messages and notification. Route-osc is a route which default test is a string comparison of the OSC messages' address.
- Several dedicated tools will allow to collect or group incoming data, such as coll, group or timed-coll.
- coll has a temporary memory and allow to collect incoming data (can be seen as the reactive equivalent of an omloop collect. On update request, it behaves differently depending on the input:
- in collects the data in a list
- push propagates the updates with the current contents of the list
- init reinitializes the memory
- group has a configurable delay (in ms). Within delay, updates are collected in a list before to propagate.
- timed-coll combines coll and group and uses a delay parameter to collect lists of list from incoming data.
- J. Bresson, J.-L. Giavitto (2014) A reactive extension of the OpenMusic visual programming language, Journal of Visual Languages and Computing. [PDF]
This paper gives a formal semantics of the reactive model in OM, as well as preliminary orientation for its implementation. An extended state of the art and study of related works is given.
- J. Bresson (2014) Reactive Visual Programs for Computer-Aided Music Composition. IEEE Symposium on Visual Languages and Human-Centric Computing – VL/HCC, Melbourne, Australia, 2014.
This paper presents the reactive programming framework in OpenMusic, highlighting some characteristics of the programming and computation paradigms involved. It describes its implementation, and shows some preliminary extensions and applications.
- EFFICACe project report including semantics, implementation and preliminary applications.