Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: David Slomin (david.slomin_AT_av.com)
Date: ti tammi 18 2000 - 18:47:40 EST
Fredrik wrote:
>
> This looks a lot like the Logic drum editor, except that it doesn't have the East spike. It's a drum editor, so it doesn't need one, since drums are always "one-shot" events.
> Looking at Logic's piano roll, there's another way of representing event properties. The events look like this:
>
> _______________________
> | _________ |
> |_______________________|
>
> The line inside the block represents note-on velocity. If this line
> goes all the way to the right, the note has a velocity value of
> 127 (100%). If it's invisible, it's zero. Also, the same property
> is also represented by color. So Logic is capable of representing
> 4 properties with every event. (Start time, duration, pitch,
> velocity). Your idea of North spikes is a nice idea, and it can be
> extended, by adding more spikes.
Logic's one is kind of cute, but not too extensible. I planned to
implement 8 spikes in PEGS, but theoretically, you could have a
nearly infinite number, one at every possible angle around the
circle. People are used to seeing 8 (a compass) or 12 (a clock),
so I'd probably stick to one of those.
> |
> | |
> | |
> *-----------*
> | |
> |
>
> Here we have pitch, start time, duration, note-on velocity and
> note-off velocity. There is also two new values that could be used
> for things like envelopes. My example above would have a medium
> attack time, and a short release time. All this is without using
> colors, or logic-style "velocity-lines" descibed above.
Right... the idea is that in PEGS, you as the user get to choose
what spikes represent what properties, so this is definitely
possible. However, if the asterisk on the right was not meant to
be a separate event, but rather just an artifact of drawing in ASCII,
I'm afraid that PEGS in its current design doesn't handle that.
All spikes have to radiate from a single plotted point per event.
More complex renderings could be possible, but I have to draw the line
at some point, and this seemed to be sufficiently expressive. A
PEGS-compatible rendering (one of many) of your example might be the
following:
| e = duration
| / n = attack velocity
|/ s = attack rate
*----------- ne = release velocity
|\ se = release rate
|
> Contiguous events like modulation and aftertouch are a bit harder.
> Especially event-specific ones like polyphonic aftertouch.
In this sense, PEGS inherently takes a pretty low-level viewpoint:
each value change for the mod wheel is a separate event and is
graphed as such, just like in raw MIDI. You can, however, define
meta-style events which don't exist in raw MIDI, such as "ramp
modulation amount from 0 to 127 over 8 measures". You could
alternatively provide a pen callback that treats "continuous"
controllers semi-intelligently, in the manner of the line drawing
tool in Cakewalk's controller editor.
These are somewhat advanced examples of ways to customize PEGS,
and I wouldn't expect users to be able to do them without both
documentation and examples. That's a big part of the reason I've
been saying that 1.0.0 is a long way off. I can probably
(hopefully) have the actual core of PEGS completed fairly soon,
but it could take another few months after that before I can come
up with enough default callbacks for it to be at all useful for
end-users.
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST