octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: Sequencers


From: David O'Toole
Subject: Re: Re[2]: Sequencers
Date: Fri Aug 30 17:41:01 2002

> I think the important idea is to view an editor as a UI element, a way to 
> access
> a sequencer, whereas the sequencer actually does the event-generating.  You
> wouldn't _have_ to make the editors platform dependent, but because of their
> UI-oriented nature, they're the element most prone to fall into that.  If you
> separate them from the sequencer conceptually, though, it doesn't screw up the
> whole design if that happens.
> 
> This is pretty well different from the typical tracker concept that Octal is 
> an
> outgrowth of, where the user interface to the sequence data is closely tied to
> its internal representation.

You've hit the nail right on the head: that's been the salient design
change. Allowing multiple editors/"sequence views" requires a more
generic concept of events and sequences. 

OX_API plugins have different parameters, right? Well a change in a
parameter is considered an event. A list of events is a sequence, etc.
(It's trivial to add a "discriminator" to the collection list, which
could for instance only enumerate events matching a certain channel
number etc. So when the user wishes to edit by channel etc.)

The sequences of events and their API exist independently of any viewing
method. Basically this is a lot more like a MIDI sequencer than a
tracker, but ultimately it will be a lot more flexible. This is part of
a little research project into musical GUI's so trust me, there'll be
some interesting developments there and I'm always open to suggestions
and experiences people have had with wide varieties of musical
gear/software. 

Anyway, the sequencer is nothing more than an object that processes a
sequence (event list) and dispatches events to a plugin at the correct
time. But it's possible (as another poster pointed out) to have
sequencers that, say, algorithmically generate their data instead of
read it from a sequence. I'm expecting this will be used more for
automatic fades/sweeps of plugin parameters than for algorithmic
composition, but it should make arpeggiators and such possible. 

Not sure yet on what the GUI will be like, but the current codebase
already has the GUI builder code separate from the plugin API, so it
should be possible (trivial?) to allow "sequencer plugins" that export
OX_API parameters and allow the same GUI builder code to do the work. 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]