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 Olofson (audiality_AT_swipnet.se)
Date: pe tammi  21 2000 - 21:33:40 EST


On Fri, 21 Jan 2000, David Slomin wrote:
> 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.

Ok; I actually meant "real time editing", as opposed to destructive
editing. (Preferably, it should also be done without rendering for
several ages before playback starts, but that's more a matter of CPU
power than of system design.)

The point with that note was just that the distinction between
destructive and non-destructive editing might make a difference WRT
the clip sequencer/HDR problems you were thinking about.

Anyway, a playback engine for a clip sequencer would be a sampler, so
connecting it's output to a HDR would just be a matter of recording
the audio streams it generates.

WRT input data, the sampler and the HDR are very similar; in fact
they can be identical in a buffered system, where the sequence data
is already known well before the actual playback time of each clip or
note. That's always the case with a normal HDR, and never with a MIDI
sampler.

Looking at direct-from-disk samplers like GigaSampler, you end up
somewhere in between: When you select a patch (MIDI program change),
GigaSampler preloads enough data from disk to be able to start
playing notes without disk latency, and keep playing until the disk
read thread catches up, and sends the rest of the data to the mixing
thread.

I don't see where the irreversible mixdown step gets in here...

> > 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.

Not as long as it's really a single application, or a homogenous
suit. External programs OTOH, might even be running different
toolkits...

> First,
> all actions need keyboard shortcuts that are available regardless
> of which window has the current focus.

Very, *very* important! :-)
(Cakewalk gets a big, fat punch on the nose for that... It's even
getting worse for each version. :-( )

> 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).

Yep.

> I personally hate
> MDI, but this can work in a multi-window, SDI application too.

I agree; MDI is only good if it for some reason is complicated to
keep track of the windows, or if you're an inexperienced user of
windowed environments. Generally, I just get annoyed by not being
able to use the full screen space efficiently for multiple
applications... And when using the application alone, it doesn't
matter if it's MDI or not - you can keep it on a desktop of your own
if you like, but forcing the MDI style is M$ philosophy.

> 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.

Well, personally I think a custom keypad + mouse would be the most
efficient method. Multiselect and long distance drag copy/move just
doesn't work too well with keyboard only, and having to let go of the
mouse or move the other hand all over the keyboard to reach the
shortcut keys is very uncomfortable...

Are you planning on incorporating higher level callbacks, like
"select function #x" as well? IMHO, having only low level input device
oriented events would mean that it's up to the individual GUI elements
to decide what to do about things - which means that it gets
virtually impossible to change anything without changing all those
elements!

Defining a number of different event types, would mean that you
could provide a callback for "select object", and then let the host
application decide when to call it. That way, you can implement the
input device -> event type decoding in one place, rather than all
over the place, making it easier to keep things consistent, easier
to fix bugs, easier to add new selection/editing methods etc...

//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 -'


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