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