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.