Absolute scheduling of events


    Jul 13 2008 | 9:32 pm
    Hello,
    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.
    Thank you very much!
    Best Torsten

    • Jul 14 2008 | 8:30 am
      Hi,
      you could use qlist, but its timings are relative, non absolute.
      All the best
    • Jul 14 2008 | 9:17 am
      Dear Alessandro,
      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 :)
      Best Torsten
    • Jul 14 2008 | 10:59 am
      cant you just send some message to max when you are done in strasheela (i guess) which triggers playback?
      p
    • Jul 14 2008 | 12:56 pm
      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?
      Best Torsten
    • Jul 14 2008 | 4:12 pm
      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
      p
    • Jul 14 2008 | 5:08 pm
      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.
    • Jul 14 2008 | 5:57 pm
      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!
      Best Torsten
    • Jul 15 2008 | 11:15 am
      Dear Robert,
      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?
      Thank you!
      Best Torsten
    • Jul 15 2008 | 11:45 am
      Hi, another option would be the FTM library from Ircam:
      Or, but not free, JMSL:
      All the best
      -- Alessandro Fogar
    • Jul 15 2008 | 4:06 pm
      > 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.
    • Jul 15 2008 | 5:04 pm
      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
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Jul 15 2008 | 10:17 pm
      Hi, in the help file for qlist there is a complete example showing how to implement something like a 'cue point'.
      All the best
      -- Alessandro Fogar
    • Jul 15 2008 | 11:14 pm
      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?
      best peter
    • Jul 16 2008 | 9:48 pm
      Dear Peter, Alessandro, Stefan, and Robert
      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.
      Again, thank you all very much for your help!
      Best Torsten
    • Jul 16 2008 | 10:01 pm
      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...