Timeline Clip interface ideas…
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?
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?
—– Original Message —–
From: "Joshua Kit Clayton"
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
> 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.
On Wed, Dec 10, 2008 at 3:22 PM, Anthony Palomba
> 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?
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.
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?
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" ;)
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
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?
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
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.
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
Awesome, thanks for all the pointers. I will keep you guys
posted on the progress.