torsten.anders

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 

I should mention that I am new to Max, apologies if I overlooked 

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  
snippets precisely.

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  
timing.

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  
something obvious.

absolute-scheduling-of-events

you could use qlist, but its timings are relative, non absolute.

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 :)

On Jul 14, 2008, at 9:30 AM, Alessandro Fogar wrote:
> you could use qlist, but its timings are relative, non absolute.

cant you just send some message to max when you are done in strasheela 

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

Thanks for your reply. Could you point me to some documentation how I 

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 

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 
help you

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.

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 

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 

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?

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?

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?

thanks for your help. Its very nice getting different takes on the  
problem!

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?

another option would be the FTM library from Ircam:

Hi,
another option would be the FTM library from Ircam:

> 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.

> 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.


> 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 

Torsten Anders schrieb:
> Is there something I miss which would make coll preferable over
> qlist?

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 
actual events...
Relative time is easier to extract from absolute time as the other way 
around...

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...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


in the help file for qlist there is a complete example showing how to

Hi,
in the help file for qlist there is a complete example showing how to
implement something like a 'cue point'.

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. 

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!

sorry for the late reply and again thank you all very much for your  
help.

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.

> 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...

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...


Absolute scheduling of events