Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: David Slomin (dgslomin_AT_alumni.princeton.edu)
Date: pe tammi 21 2000 - 13:14:21 EST
David Olofson wrote:
>
> 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.
Very true. I tend to think of clip sequencers as fire-and-forget
type systems, but that's not the reality except in trivial cases.
Then again, can any clip sequencer give you full control over this
type of thing? It seems that that, in part, was why protocols like
MIDI were invented, so that you could control a sample (or other
"note") with decent accuracy _after_ it was already fired. Once
you move into that domain, you're back in an area where the PEGS
design is pretty proficient... sequencing control messages.
> (Note that I prefer to do all processing in real time as far as
> possible - that could make a difference here...)
Realtime is an important thing, but it is not the goal of PEGS.
If you're as sloppy a pianist/synthesist as I am, at some point
you'll need a strong editing interface to clean up your mess or
assemble a grand composition from the little snippets you're capable
of playing accurately in realtime. This is where PEGS comes in.
> 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.
Although I do not have a tracker background (I first experimented
with them after already being very biased towards sequencers), I do
appreciate the feature which you describe here. The ability to
navigate your entire interface cleanly without touching the mouse
is definitely important for efficiency (I do use vi as my editor on
all platforms).
However, believe it or not, you are not limited to using a single
window to acheive this effect. I've never seen a program which
does this properly, but it would not be hard to write one. First,
all actions need keyboard shortcuts that are available regardless
of which window has the current focus. Second, all windows of
the application should be navicable from the keyboard using
direct jumps instead of ctrl+tab (the traditional MDI equivalent
of alt+tab, at least in the Windows world). I personally hate
MDI, but this can work in a multi-window, SDI application too.
Since PEGS is programmatically driven (other than the graph editing
window, there are no inherent GUI elements: no menus, no buttons,
no keyboard shortcuts, etc), it's hard to say where it would fall.
Of course it could be turned into a mouse-only program by providing
only mouse-based callbacks, but it with a little more effort it
could be turned into a keyboard-only program too. I plan to
include hooks for various types of window-specific mouse callbacks,
window-specific keyboard callbacks, and global keyboard callbacks.
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST