Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: to syys 02 1999 - 21:46:42 EDT
On Thu, 2 Sep 1999, Eli Brandt wrote:
> Dunno offhand. First off, I think my idea of time says that if two
> events aren't at the same time, they shouldn't have the same timestamp.
> Maybe make the timestamp a pair (time, tiebreaker) and order
> lexicographically.
Scary, but a potential solution. I'm not crazy about an arbitrary
tiebreaker field which would be used for nothing else. It seems a little
far removed from the music, but then so is any system in which
simultaneous events have a distinct order.
> I don't think I understand the difference between markers and
> selections. A marker is an event, while a selection endpoint isn't?
> But that's an implementation detail, not user-visible.
That's it exactly, but I meant to make it (optionally) user-visible.
The implementation of course would have to drop markers at the left and
right of a drag selection, but the user could also place them manually.
This allows several things:
1. Accuracy. A drag selection doesn't lend itself to popping up a dialog
box when it's necessary to type in an exact timestamp. Cakewalk, for
example, gets around this by using three markers (begin, end, and now) but
doesn't allow an arbitrary list of markers.
2. Bookmarks. Especially since I'm pushing for a non-structured
sequencer, jumping around the file to arbitrary timestamps is pretty
important. If you've ever used a text editor equipped with markers,
you'll never want to do without them again (Vi sold me on them, but it's
not unique in this regard).
3. Persistance. If markers are implemented as events (and yes, there
really is a standard defined "marker" event in SMF), then they can be
saved with the file, which can be convenient.
That said, they're less convenient for discontiguous selections, so I'll
have to handle those separately (unless you can recommend a better way).
> I think I'm nervous about really making markers events, because you
> get into a situation where you've got events at t and t+1 and want to
> drop something in between, and there is no such time. (Unless your
> timestamps are scary and unbounded in length.) Whereas if you have a
> selection-endpoint timestamp at t+1, that selects exactly one of the
> two events.
That's where the single-merged-list-of-events-per-song model helps. To
insert a marker between two events even with the same timestamp, just
insert it between them. That way you don't need infinitely accurate
timestamps... you don't have to change the marker's timestamp to guarantee
a specific order.
BTW, I have at least two hitherto unseen sequencer interface concepts
I'm itching to implement that rely on having markers work this way:
The first I call "rhythm shadows". You select a phrase (or such), and run
a function (plugin, etc) on it. The plugin creates a marker for each
note-on and note-off at the same timestamps. These markers can now be
copied and pasted anywhere without the notes of the phrase, but preserving
the phrase's rhythm.
You then use a custom pencil (note insert) tool that quantizes start time
and duration to the nearest markers. Voila, same rhythm, new melody.
Delete the markers when you're done, or set an option on the pencil tool
to do it automatically as you go.
I haven't come up with a decent name for the second function, but I've
referred to it on this list before as "semi-automatic interpolating
timestamp adjust". It's meant to make quantizing a thing of the past. To
use it, first record the song in realtime, ignoring the sequencer's
metronome entirely. This is essential for me, because I don't hold a
tempo very well when I'm playing the piano (shame on me, I should be more
disciplined).
Next, look at what you recorded. The rhythm will be approximately correct
(even if the tempo changes over time), but the actual measures won't line
up with what the sequencer calls measures. Drop some markers at points in
the music for which you know the intended timestamp (regardless of what
the sequencer thinks the marker's timestamp is). Label each of those
markers with a string version of the intended timestamp (in some syntax
which has yet to be decided).
Run the nifty function (plugin, etc), and it will adjust the timestamps of
all events in the specified range so that the intended timestamps become
real. Everything between the markers will be linearly interpolated.
This runs rings around quantization for three reasons: first, it works
even if you're _really_ far off from the intended rhythm; second, it
doesn't lose rhythmic nuances unless you tell it to; and third, it handles
any sort of rhythm you want, not just straight and swing.
See why I like markers? :-)
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST