One of the big differences between Reaktor and Max/MSP is the way information for your own design is represented within the system.

Numeric Data types

Reaktor has two levels of design: primary and core. In the primary level, all numbers are stored and calculated as 32-bit floats. Some processors, such as the Celeron, do not have hardware floating-point acceleration, so mathematical calculations (especially division and transcendentals) can take up alot of CPU cycles. Reaktor also supports 64-bit numbers, integers, and some bitwise manipulations in the core.

Max/MSP supports intermingling of integers and floats throughout the design.

Numeric Arrays

In the primary level, Reaktor supports the storage of 2-D and polyphonic data arrays of 32-bit floats in table modules. The table modules also provide a range of display options. In the core level, Reaktor's built-in modules support 1-D arrays only, but they may be integer and 64-bit types as well as 32-bit floats.

Max/MSP also has table objects, but their display is not as comprehensive as in Reaktor's primary-level table modules. Tables are also not passed as messages, they are for storage only.

Jitter also supports arrays, glowingly described in the promotional materials, and at first I thought I could use Jitter for advanced DSP audio calculations. However while audio manipulation in Jitter could be possible with some significant effort, the Jitter arrays (called matrices) are really intended for displaying Quicktime pictures, videos, and animations. For audio, Jitter's main benefit is to display oscilloscope-style waveforms or color-coded temporal bars. Jitter is not natively intended to provide any array processing of audio data.

Text Strings

Reaktor permits users to store strings in the module properties, so that ports and screen elements can be named for example. However it is not possible to manipulate strings with Reaktor modules.

Max/MSP handles text strings just like numeric values. Strings are passed from the ports of one object to another just like numbers. There are a range of functions for changing text strings. This is one area where Max/MSP is really superior to Reaktor. Max/MSP can change text strings much like mathematical manipulation of numbers. This enables designs to change the text in drop-down list boxes for example, which is not possible in Reaktor.


An additional data type in Max/MSP, lists, provides the ability to pass messages containing more than one value in an ordered array called a list. While this theoretically simplifies design, in practice it can be very difficult to debug as the values in the lists are difficult to observe. One notes that there are a number of college courses in Max/MSP and all of them spend quite a bit of time on lists, so obviously, they are not as simple to use as they may appear at first blush.

On the other hand, lists can be very powerful if you do not overload the system with them (a fast list processing object in Max/MSP is called the 'Ouzi,' a type of submachine gun. There are strong warnings in the documentation that indiscriminate firing of the Ouzi object can hang your computer).

Environment Messages

Max/MSP is also more powerful than Reaktor in that it can access and control environment control variables via messages. In Reaktor, environment properties are preset in the environment and cannot be changed unless a module is available to set them.

Max/MSP interacts directly with the environment so it is possible to change internal characteristics, change menus, set alert boxes, and so on.


Finally, Max/MSP really beats Reaktor hands down on providing the Bang message. The 'bang' message is issued at startup for initialization, as well as to set and pass parametric values through the network. A 'BangBang' module is available to send 'bangs' at power-up and preset change.

This is a vast improvement over Reaktor, which provides no systematic method to manage initialization events. I was very happy to discover the 'BangBang' object, after having spent many days struggling with event initialization order in Reaktor.

But do You Really Care about Data Types?

Now after presenting all the data types available in each system, there is the opposing question: should an artist really need to care about data types? Well, if you are intending to create something with Max/MSP, you really need to be able to manipulate data types just like in a software program. You can get away without understanding data types too much in Reaktor, but for Max/MSP, you have to understand data types at least to the level of basic programming. So the argument here is that you should regard being able to write software programs just like being able to mix paints: it is a necessary skill that the artist must master. As to which paints the artist chooses to mix, that is the fundament of being a successful artist.

Do Data Types Really Work in GUI Environments?

Historically, those who sell GUI environments that manipulate data types have often had a hard time persuading the rest of us that the GUI environments actually help. Messages of different types move invisibly on the wires between the objects, and the objects need to receive messages of the type they expect in order to respond properly (messages of incorrect types are usually ignored).

This is an area where many state a scripted language program is much better, because one can directly observe and control the data types moving between objects. The graphical interface actually makes it much more difficult to find problems, because the type data and messages are hidden and obscured by the pretty graphical interface.

So from this perspective, if you are looking for a simple graphical environment, Reaktor is better because it has less data types. At primary level, everything is forced to one data type which may be slower to process, but at least the likelihood of there being a programming error that is difficult to find is smaller too.

However Reaktor's data types are more limited in power than Max/MSP, which also has interfaces to other programming environments. it does take some significant effort to set up these interfaces, but I hope to have it done and ready for a report very soon.

Views: 2392


You need to be a member of dance-tech to add comments!

Join dance-tech

welcome to

Welcome! provides movement and new media artists, theorist, thinkers and technologists the possibility of sharing work, ideas and research, generating opportunities for knowledge exchange, interdisciplinary explorations, innovations and collaboration. is a social networking website connecting people concerned about innovation and experimentation on movement  arts and  its evolving embodied practices knowledge, stories and histories.

So, dance-tech.TV and .net are FREE...

but it is supported by the generosity of its members and special funds from Motion Bank/Choreographic Coding Labs (Frankfurt)


You must SIGN-UP to interact with members enjoy the social networking features

The use of and is FREE

This networked is maintained and administrated by Marlon Barrios Solano for free as an independent project.

You can donate to support my work here:


Support making a single donation of any amount.
Thank you!


for more information


Creative Commons License
All content uploaded @
is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.





© 2018   Created by marlon barrios solano.   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service