Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: David Olofson (audiality_AT_swipnet.se)
Date: ke tammi 19 2000 - 21:31:27 EST
On Wed, 19 Jan 2000, David Slomin wrote:
> David Olofson wrote:
> >
> > Moving megabytes of data from one application to another can never be
> > lightweigt...
[...]
> applications, you could deal with that by storing the data in
> shared memory, accessed through another JNI callback. This
MuCoS will use shared memory for the interprocess communication, so
you kind of get that for free with the API... An audio engine and a
wave editor asking the data streamer daemon for peak data for the
same file would receive a pointer to the same data. The same applies
to sample players, HDRs etc sharing audio data.
> > 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.
Yes, there are implementation problems... However, I'd like it that
way, as popping up new windows can be a bit confusing. You shouldn't
be forced to use the window manager to get back to the event view -
switching should be possible to de with a single shortcut. Another
problem is that you still need an audio editor that lets you see the
relation between the waveform and the other events... Timestretching
and timing editing is still much of a trial-and-error process without
that.
> 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.
What problems are you thinking about? (Note that I prefer to do all
processing in real time as far as possible - that could make a
difference here...)
> > 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.
That's the problem here; I absolutely hate the way Cakewalk and
similar programs leave this to the WM. (Ok, one of the most limited
ones around, but anyway... :-) There are good WMs for X, but WMs are
still meant for "normal" application use - not for panel style
positioning, as in the old full screen trackers. The sequencer needs
to keep track of the size and position of all windows (per
*instance*, not per external app), so the user doesn't have to move
windows around all the time.
The classic style trackers do have an advantage here, as they can be
fully keyboard controlled, and you can access everything without
extra operations just to see things. Some people still prefer the
text screen UIs just because of that! Personally, I prefer having a
mouse for less frequently used functions, but other than that, the
mouse - as well as the keyboard - should be used only for actual
work, as far as possible.
//David
.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST