Absolute scheduling of events
I am looking for a way to absolutely schedule events (e.g., lists of
numbers representing MIDI notes) in time.
I am creating score snippets outside of Max (using another
programming language and communicating via OSC). This external
creation is triggered by some Max events, and Max also plays back the
resulting score snippets. The problem is that I don’t know how long
this external computation takes (the computation time varies).
Nevertheless I want to schedule the playback of the resulting score
I solved this problem in SuperCollider with OSC timetags: for each
event I specified some timetag in the near future. The SuperCollider
scheduler could then play my timetagged score snippets with correct
How could I realise something similar in Max? For example, is there
any object which I could send a bunch of events — not necessarily
sorted by start time — and which would output each event at its
individually specified absolute start time (e.g., depending on
[cpuclock] or ticks from [date])?
I should mention that I am new to Max, apologies if I overlooked
Thank you very much!
you could use qlist, but its timings are relative, non absolute.
All the best
On Jul 14, 2008, at 9:30 AM, Alessandro Fogar wrote:
> you could use qlist, but its timings are relative, non absolute.
thanks a lot for pointing me to this, its a start :)
cant you just send some message to max when you are done in strasheela
(i guess) which triggers playback?
On Jul 14, 2008, at 11:59 AM, pure wrote:
> cant you just send some message to max when you are done in strasheela
> (i guess) which triggers playback?
Thanks for your reply. Could you point me to some documentation how I
can do that?
maybe i completely misunderstand you but if your other tool does not
only receive OSC but also send this would be the way to go.
if you can tell more about your other application it should be easy to
i think coll is your friend in this case. however you will have to handle the reading and writing yourself.
lots of different ways to handle the time (timer, cpuclock, clocker, etc.), but i guess the idea is to receive an event with a timestamp, and use that timestamp as the index for the coll, and write the event to the coll at that index.
for reading, you would use a metro (or whatever) to set your grain, then each clock tick, you would use an uzi to bang every integer from the previous clock tick to this clock tick, into the coll which stores the events. this would output all the events for that clock tick.
of course this only works with integers, so your probably want to use millisec time. easiest would be millisec time since the start of the piece.
Dear pure (sorry, don’t know your real name :)
Again, thanks for your reply. Here is the story in somewhat more
detail. As you guessed already, I am generating small polyphonic
scores in Strasheela (http://strasheela.sourceforge.net), using a
realtime constraint solver. From within Max I am sending arguments
for this score generation process to Strasheela, and that way also
trigger the generation process. As soon as Strasheela finds a
solution (i.e. a small polyphonic score) it is send back to Max. The
communication works both ways with OSC. I am presently sending all
notes of one solutions from Strasheela to Max as a single bundle in
order to preserve their order and also to know where some solution
ends ([OpenSoundControl] kindly outputs a bang at the end).
Presently, in Max I am then collecting all notes of a solution in a
[qlist], play this once and then clear it immediately. Then the next
solution already arrives etc.
Are you saying that I could instead somehow talk to some scheduler of
the Max application directly for controlling the playback? How can I
do that — or where can I read more about that?
Thank you very much!
thanks for your help. Its very nice getting different takes on the
On Jul 14, 2008, at 6:08 PM, Robert Ramirez wrote:
> i think coll is your friend in this case. however you will have to
> handle the reading and writing yourself.
Alessandro suggested qlist before. Looking at both coll and qlist I
prefer qlist because it has the (relative) scheduling buildin,
whereas with coll I have to build that myself. Is there something I
miss which would make coll preferable over qlist?
> Alessandro suggested qlist before. Looking at both coll and qlist I
> prefer qlist because it has the (relative) scheduling buildin,
> whereas with coll I have to build that myself. Is there something I
> miss which would make coll preferable over qlist?
well use whatever works, but you specifically stated in your post title you wanted "absolute scheduling".
there’s several things coll has that qlist doesn’t and vice versa. the help file’s and reference file’s reveal all.
with the scenario you described (asynchronous events scheduled for some unknown time in the future), i don’t think qlist will cut it. but i don’t know qlist that well.
Torsten Anders schrieb:
> Is there something I miss which would make coll preferable over
Yes, the complete lack of navigation possibilities. All workarounds turn
out to be more complicated than doing it in coll entirely…
I haven’t seen a common language yet, but one possibility is to have two
colls, one to keep the (absolute) time of events, and one to store the
Relative time is easier to extract from absolute time as the other way
To play a piece from beginning to end is fine with qlist, but if you are
at a rehearsal and they want to start somewhere precisly in the middle
you are out of luck…
in the help file for qlist there is a complete example showing how to
implement something like a ‘cue point’.
All the best
sorry for the late reply… i think your question got already answered
with mentioning [coll] but as robert said whatever works for you is fine…
i´d probably prepend the time when you want your snippets to be played
before putting them into coll and read out the coll by a metro´ed date.
does this make sense?
Dear Peter, Alessandro, Stefan, and Robert
sorry for the late reply and again thank you all very much for your
Meanwhile I have a version with relative scheduling using qlist which
is sufficient as a demo. Later, I will come back to this matter and
try creating something for absolute scheduling. Nevertheless, I was
surprised to find that a system for realtime computer music which
such widespread use as Max does not have something like that buildin.
Again, thank you all very much for your help!
2008/7/16 Torsten Anders
> Nevertheless, I was surprised to find that a system for realtime computer music which such widespread use as Max does not have something like that buildin.
I think you’ve just discovered why ChucK was created…