data recording

Thoughts on a streaming API project model with Max.

I’ve been trying to come up with generalized methods to handle the class of Max projects which read a stream of data from the Web, and use it to trigger events, for example, sound and graphics.

OSC is generally a good way to get data into Max from Web API’s. One issue with data streams, is that they do not always provide a constant flow. In some cases, this is what makes them musical. The rhythm of the flow becomes the rhythm of the music.

But in some cases we are vexed by too little flow or too much.

When the flow is too sparse, and the project requires a constant flow – the stream can be fattened up by using a [metro] object to output the current stream value at a higher frequency.

When the flow is too fast – you can use [speedlim] for numbers – but not for text data like tweets about cats, which seem to stream in like a flood. One solution is to use a data-recorder, like our modified CNMAT list recorder in the Irish Train project.

You would need separate access to the record and play ‘heads’ – so for example you could record in real time, but start playing back at a slower rate (while the recording continues). This is essentially a form of stream buffering. The data recorder approach would also allow you to use various algorithms to ‘thin’ the data – for example, to keep up with the real time rate, but by using less of the data.

[update] got this working with the modified CNMAT data recorder patch. It allows separate control of recording and playback, simultaneously.

patch is in tkzic/max teaching examples/ data-recorder-tester.maxpat