OM# Documentation


OM# visual programs (and functional programs in general) usually don’t deal much with memory. A function should produce no “side effects”, and always behave identically / return the same result from a given set of parameters, regardless of what happens in the meantime, or of what results were computed previously.

This rule breaks very often in practice: for instance as soon as a program preforms a file input or output. In addition, OM# provides various means to record and collect data in visual programs.

The boxes described in this page all embed a storage slot, or memory.

Note: Global variables are another way of dealing with memory and side effects in OM#.

A simple delay: mem

mem is a sort of delay that can be used in patches and iterations to recall the previous value or the n previous values that have passed through the box.

See the mem examples in OM# inbuilt Help Patches

Collectors: collect, accum, tcollect

collect, accum, and tcollect are advanced collectors inspired by the omloop feature of OpenMusic. They are meant to be used either inside OM# loops or in reactive programs, as a means to store and collect incoming data.

Remember that these boxes are simply holding the data in memory.


collect is the main collector box, from which are derived the two others. Its memory is a simple list.

collect has 3 inputs and 3 outputs, which behave slightly differently depending on whether they are evaluated in a standard way (“pulled” from the outputs, typically, in a loop) or activated by a reactive notifier (“pushed” on the inputs).

Standard case (pulling outputs)

In reactive processes (pushing inputs)

Any collect input receiving a reactive notification simulates the evaluation of the corresponding output:

See Reactive processes and the Core features/collect Help Patch


tcollect is similar to collect but includes a temporal dimension.

tcollect allows for instance the grouping of chords when processing a stream of incoming notes.
See also the Core features/collect Help Patch.


accum is a generalization of collect which performs user-defined collection strategies. The main difference with collectis the second input, which here must receive an accumulation function able to process a combination of the input (data-in) with the current content of the memory.

Possible functions are for instance +, in order to sum up the inputs (supposedly numbers), max to maximize the values, or any other function or patch processing one input value and the current state of the memory.

accum is mostly intended to be used in loops as a way to extend or specialize the behavior of collect when needed.
See the Core features/loop Help Patch.

Note: accum has no push input and therefore is not suited to work in reactive processes as collect/tcollect do.