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 Slomin (dgslomin_AT_alumni.princeton.edu)
Date: su tammi  16 2000 - 13:27:46 EST


David Olofson wrote:
>
> Anyway, I think the most interesting of one of those old ideas was to
> remove the track concept, and use the Y axis in the arrange view only
> for layout. That should make the arrange window more "readable",
> lessy tricky to use (no "what track is this, really" situations on
> big screens) and smaller. Why 70 tracks (yes, some of my songs get
> that big when mixing everything down in the digital audio domain!)
> when you only need them to say "this clip should use that set
> of output, paramaters and effects"? Have a separate window with
> named, color coded,... "output contexts" that you can select for each
> clip.

I agree, the track paradigm is not very useful in audio clip
sequencing, and sometimes breaks down even for simple MIDI
sequencing. In PEGS (my current sequencer project), there is nothing
inherent about the concept of a track... "track number" is just one
of an infinite number of arbitrary properties you can define for an
event. When you as the user provide a display callback (which tells
PEGS how to link up display primitives with event data), you decide
whether or not to look at/for a "track number" property. You can
even decide whether to render it in terms of color, vertical offset,
or something else. If you want to call the property "output context"
instead, be my guest... load/save and record/playback are provided
by callbacks too, so you can use the property however you want.
 
> A clip should be more than a graphic grouping of events. It is a
> logical UI object, and should have all the *useful* functions you
> expect! Who cares for a dodgy mouse selection scheme that they have
> worked around to get back the few advantages of the old "one dot per
> bar" scheme, and that doesn't do ANYTHING but try to make selections
> easier, and put nice colors in your arrange view? It seems almost
> ridiculous to me when I think about it...
>
> Further, there are times when you wish you could move things around
> inside a clip. Now, what you get is the piano roll, the staff view,
> or the event list. And in CW, you can't even see which clip's events
> you are moving around! It's just the plain old, useless (in most
> situations) full single track edit mode. :-( Even pattern based
> trackers are more structured than that - they have a way of dividing
> the timeline into logically relevant parts.

When I use Cakewalk, I don't often use clips, as I prefer to copy
and paste in the tracks and then doctor each copy. To me, the music
can sound a little too repetitive if it's just cookie-cutter links
throughout. However, I understand that clips are useful for
certain purposes. There are, after all, many people who are
perfectly satisfied with trackers and other pattern sequencers.

In any event, PEGS doesn't have an overview/"track view" window
at all, just its unique display window (an extremely distant cousin
of Cakewalk's piano roll).

> My idea: Clips inside clips. (Allow any number of levels if you dare,
> but it might be too much for some users to sort out... ;-)

I had to think long and hard about this one and how it maps into
the PEGS paradigm. I think the most straightforward (?) way to do
it would be to define an "event list pointer" event type (event type
is just another user-provided property). You would then provide a
pen callback (which is used when you click on the event in the
display window) that opens a new display window with the event list
it points to. Because it's a pointer, you then get "clip linking"
for free (although you have to provide explicit create, delete, and
duplicate commands somewhere). Loading and saving would be tricky,
since SMF (MIDI files) doesn't support this, but PEGS allows you to
plug in your own file formats if you want (yes, every single thing
in the damn program is a callback). How's that sound?
 
> Yes, I think Cakewalk is a very, very limited application with a
> stone age design! *argh!* It just has lots of functions in a huge
> pile, and they are getting hard to access in any useful way these
> days.

I think Cakewalk was a nice, solid, track-based MIDI sequencer.
It's been going downhill ever since it abandoned that narrow goal.
(And that goal in and of itself was definitely insufficient for
most types of music.)

Div.


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