Timeline Clip interface ideas...


    Dec 09 2008 | 4:28 pm
    Now that the new SDK is out, I have finally started developing a
    timeline clip interface. Ideally these clips would be like
    generic containers that could represent anything: MIDI data,
    audio files, algorithmic processes. Smaller clips could
    be collected in to hierarchical composite clips.
    I had envisioned the user double clicking on a clip and it
    opening a bpatcher that could then be loaded with what ever
    patcher the user wanted.
    The question is, is there support in the SDK for bpatcher
    functionality that I can add to my external?

    • Dec 10 2008 | 3:52 am
      No specific support for bpatchers per se. It sounds to me like you'll want to make use of patcher scripting. You can do this from C just as you can do from javascript, or thispatcher. I woudl suggest you take a peek at the scripto SDK example for creating a new patcher window and instantiating an object inside it and subscribing to it. This might help get you up to speed with patcher scripting from C, at which point you can script loading a bpatcher, or whatever.
      -Joshua
    • Dec 10 2008 | 2:20 pm
      I am not sure I understand how that would work...
      I was envisioning a clip interface done in C using the JGraphics
      API, the user would double click on a clip which would
      open up a bpatcher window. Are you suggesting I use
      script to create the bpatchers, then hide them off-screen
      or in memory?
      Anthony
      ----- Original Message -----
      From: "Joshua Kit Clayton"
      To:
      Sent: Tuesday, December 09, 2008 9:52 PM
      Subject: [dev] Re: Timeline Clip interface ideas...
      >
      >
      > No specific support for bpatchers per se. It sounds to me like you'll want
      > to make use of patcher scripting. You can do this from C just as you can
      > do from javascript, or thispatcher. I woudl suggest you take a peek at the
      > scripto SDK example for creating a new patcher window and instantiating an
      > object inside it and subscribing to it. This might help get you up to
      > speed with patcher scripting from C, at which point you can script loading
      > a bpatcher, or whatever.
      >
      > -Joshua
      >
    • Dec 10 2008 | 4:07 pm
      On Wed, Dec 10, 2008 at 3:22 PM, Anthony Palomba wrote:
      > I am not sure I understand how that would work...
      >
      > I was envisioning a clip interface done in C using the JGraphics
      > API, the user would double click on a clip which would
      > open up a bpatcher window. Are you suggesting I use
      > script to create the bpatchers, then hide them off-screen
      > or in memory?
      >
      I think you're mistaking what is considered a bpatcher. A bpatcher is simply
      a "patcher displayed in a box" (in its parent patcher window). There is no
      such thing as opening a bpatcher window. It would display its patch it a
      patcher window. So if you talk about "opening a window" that would normally
      mean opening a patcher window.
      You could have your clips reference patcher files (just like a bpatcher) and
      open the window when you click on them. Maybe your clips represent something
      else, and you can script that something else inside a patcher window when
      you double-click on the clip.
      What your clips represent and how you translate that to a custom UI window
      or patcher window is up to you. If you use patchers you can script their
      content like Joshua pointed out. You are talking about a composite
      hierarchical structure. Does that mean patchers and subpatchers? Or
      something else altogether?
      Your idea sounds interesting, but also really tricky. Clicking on an audio
      or midi clip could open a sequencing view/edit window I imagine. But what
      would clicking on an arbitrary algorithm give you? A max object composition
      with a standardized interface protocol?
      Thijs
    • Dec 10 2008 | 4:56 pm
      Clips at the atomic level would represent a bpatcher. That
      bpatcher could be anything: a MIDI file, sample player,
      algorithmic process, etc.
      These atomic clips could be combined into hierarchical composite
      structures for example an [algorithmic MIDI sample player]. Or
      even a tree of [algorithmic MIDI sample player]. These could then
      form larger gestures or compositional forms. Double clicking on
      the composite clip would open up a clip editor that shows the
      clips hierarchy. Only atomic clips would open up a bpatcher.
      Composite clips provide a very flexible way to combine different
      instrument primitives and use them on a time line. To facilitate
      the creation of composite clips, bpatchers would have to have
      some standardized inlets and outlets so that data could be passed
      from clip to clip.
      It would also be interesting if clips understood scalar time as
      well. Not only would it understand "start time" and "end time",
      but also be able to scale the gesture it represents over a larger
      time period. Similar to Curtis Road's micro/meso/macro
      representation of time.
      Anthony
    • Dec 10 2008 | 5:22 pm
      I guess the real dirty work this external would have to
      do is manage instantiations of patchers and connecting
      them together to form these larger structures.
      Basically I would have to use script calls to re-create
      the clip representation in patcher form. I could create
      a subpatcher for each composite clip, and then fill that
      subpatcher with all the instances of needed patchers.
      And then connect everything up. I would then manage the
      data sent to these subpatchers.
      Sounds like the brute force way of getting the job done.
      Is there some more sophisticated software solution that I
      am not aware of?
    • Dec 10 2008 | 5:33 pm
      On Dec 10, 2008, at 9:22 AM, Anthony Palomba wrote:
      >
      > Sounds like the brute force way of getting the job done.
      > Is there some more sophisticated software solution that I
      > am not aware of?
      Um...I haven't the foggiest idea what you mean by "more sophisticated"
      in this case. This question sounds to me like "Is there something
      which already does this for me?" In which case the answer is "no" ;)
      -Joshua
    • Dec 10 2008 | 7:33 pm
      By more sophisticated, I mean I would rather have a
      way of building these patcher instances in memory rather
      than in the patch. That way the interface is nice and
      clean.
      Also, I would need to be able to save all the data associated
      with these structures. Does the SDK provide any kind of serialization or file i/o?
    • Dec 10 2008 | 7:50 pm
      On Dec 10, 2008, at 11:33 AM, Anthony Palomba wrote:
      > By more sophisticated, I mean I would rather have a
      > way of building these patcher instances in memory rather
      > than in the patch. That way the interface is nice and
      > clean.
      Just use a hidden patcher window if you don't want anyone to see it.
      Otherwise I don't see how it's any more or less "sophisticated" if
      there is a containing patcher object associated with your structure or
      not. The patcher which contains it *is* "in memory". In order for the
      modules to communicate they must be patched together. The API exposed
      for accomplishing this is through a patcher. If you want to use
      "nobox" classes (e.g. linklist, hashtab, dictionary, etc.), there's no
      patcher object required, but for all Max "box" classes (i.e. anything
      which exists in a max patcher), there needs to be a containing
      patcher. This includes bpatcher which is a "box" class.
      > Also, I would need to be able to save all the data associated
      > with these structures. Does the SDK provide any kind of
      > serialization or file i/o?
      Generic file i/o is available via the sysfile API. If you make use of
      the internal dictionary "nobox" class as a data container, it has
      methods for automatic serialization and deserialization to/from a JSON
      file. If you have specific questions about these things, don't
      hesitate to ask.
      -Joshua
    • Dec 10 2008 | 8:06 pm
      Don't forget to check out the scripto example I mentioned. You just
      wouldn't send the patcher object the "vis" method, and no one sees
      what you are doing with the patcher. i.e. just comment out the
      following line:
      object_method(x->s_patcher,gensym("vis"));
      -Joshua
    • Dec 10 2008 | 8:16 pm
      Awesome, thanks for all the pointers. I will keep you guys
      posted on the progress.