Re: [linux-audio-dev] News about sequencers (not my own though!)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: David Slomin (david.slomin_AT_av.com)
Date: ke tammi  19 2000 - 13:07:00 EST


David Olofson wrote:
>
> Moving megabytes of data from one application to another can never be
> lightweigt... Unless it all happens in real time - which is where the
> communication/integration part of MuCoS gets in! :-) Using that
> interface, they could all use the same database and streaming daemon
> (which is required anyway, unless you have one drive/application),
> and integrate seamlessly on the engine level. Then the UI is the only
> remaining problem - still not trivial, but at least there's a point
> in trying, as it'll really work the way intended for a change. (That
> is, no minutes of moving/converting data, even if it could be
> automated...)

Agreed, and I'm not sure exactly how to address the issue. One
good building block for a solution is that PEGS has no built-in
versions of file I/O nor realtime I/O; rather these are provided
by user callbacks. A callback for realtime I/O via MuCoS is
certainly possible (although you'd need to have the buffering done
in C through JNI rather than in Java or DynamicJava like most PEGS
callbacks). As for the overhead of file I/O when switching
applications, you could deal with that by storing the data in
shared memory, accessed through another JNI callback. This
certainly isn't the final solution, but could be a start. Of course,
if the HDR program was also written in Java (unlikely, but possible),
then they could run in the same JVM process and share data directly.

> There probably has to be a separation of sequencer and detailed audio
> editor... Unless the audio clips automatically turns into audio
> editing applets when zoomed in close enough. :-)

I like that, although embedding an arbitrary application's window
inside the piano roll would not be my choice of how to implement it.
I'd prefer to pop up a separate window, which involves less
difficult issues in both UI design and cross-platform implementation.
Optimally, of course, the audio editor wouldn't have to be reloaded
(or even reload the data) every time the window popped up. This
can be accomplished by sending messages rather than exec'ing a new
process each time.

That aside, what you're describing here is much easier than what you
described above... before a clip sequencer can interact with an HDR,
you really need a mixdown step which is not usually reversible. For
a clip sequencer to interact with an audio clip editor, there's no
mixdown... you just edit that one clip in isolation. Both of these
tasks are important, but they're not identical.

> Note that this is probably only useful for sequencer/sampler or
> tracker style editing. Using the Y axis for pitch isn't very handy
> when dealing with normal HDR tracks... Reserving a part of the Y axis
> display range for an area with a different mapping? Split the window
> vertically? Just make the HDR events use Y axis for display only, and
> use some other dimension for pitch? Sounds like hacks to me, but
> anything to avoid this jumping around between uncoordinated views! It
> can't get much worse than that... (Ok, you *can* use a sampler with a
> tiny LCD display for editing, together with a stopwatch style UI
> sequencer, instead of a HDR! :-)

In PEGS, this is up to the user. The only one that's predetermined
is X-axis for time... I wouldn't use the Y-axis for pitch if I was
using PEGS as a clip sequencer either (unless maybe the mixdown
renderer could transpose clips like in a tracker).
 
> Next thought: This could replace the pop-up-a-new-window thing when
> editing events containing other events. (What I used to call sub
> clips - what about container events?) If you zoom in enough (or just
> doubleclick for direct full zoom), the clips turn into embeded edit
> windows. One problem; what about Y axis = pitch when zooming is like
> that? Would a make it practically impossible to edit multiple
> container events at once. You could multiselect and tile the edit
> windows or something...

Possible, but messy. The separate window approach leaves issues of
window management to the actual window manager. I'm not in the
business of competing with Enlightenment.

Div.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST