Timeline Clip interface ideas…

Dec 9, 2008 at 4:28pm

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?

#41267
Dec 10, 2008 at 3:52am

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

#146754
Dec 10, 2008 at 2:20pm

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
>

#146755
Dec 10, 2008 at 4:07pm

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

#146756
Dec 10, 2008 at 4:56pm

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

#146757
Dec 10, 2008 at 5:22pm

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?

#146758
Dec 10, 2008 at 5:33pm

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

#146759
Dec 10, 2008 at 7:33pm

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?

#146760
Dec 10, 2008 at 7:50pm

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

#146761
Dec 10, 2008 at 8:06pm

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

#146762
Dec 10, 2008 at 8:16pm

Awesome, thanks for all the pointers. I will keep you guys
posted on the progress.

#146763

You must be logged in to reply to this topic.