RE: Sequencer / Tracker

[Unkargherth]

I completely agree with you as about trackers sequencing. It's simple for
many things ,but terrible for others
By the way. Piano roll it's not the perfect way (I consider nobody created a
good way of sequencing plucked/bowed string instruments)

I prefer to consider it the following way

A sequencer is basically a syncronized evnt sender right. so, why not write
an general "event sender" ( not a end user machine only a core engine, ie an
API) and let the editing/User Interface of that be controlled by a whole new
Familiy of plugins: pattern editors, piano roll editors ( and others that
could appear) ?

This aproximation for example , permits easy creation of auto sequencers
like arpegiators, dynamic pad sequencers,etc

Graphically would be that way ( aprox)


|EVENT GENERATOR |
|( Patt Ed.,     |
|  Piano Roll Ed.|---> SOUND GENERATOR ---> EFFECT ---> MASTER
|  Arpegiattor,  |
|  etc)          |


The event Genrator would be a plugin thta Uses the Sequencer Engine API to
Send/Manage the events but every one of them culd have completely diferent
( or none at all) user interface/sequencing style. The only requirement
should be that it sends the events in a common, consistent way that the rest
of machines can understand


-----Mensaje original-----
De: address@hidden [mailto:address@hidden nombre de
David O'Toole
Enviado el: domingo, 28 de julio de 2002 23:24
Para: address@hidden
Asunto: RE: Sequencer / Tracker



> I expect should be usefult to you to start the seq/tracker thingy
...
> By the way, source code didn't chenged in last 12 Months. Has dto
abandoned
> the project ?

Hey folks---

The main reason code progress is slow is because I've had several
realizations about where the design needs to go; that's why some sections
of the codebase have been marked with comments about where things need to
go. (A secondary reason was "life events" :-) such as moving, graduate
school, etc but things are different now. )

Basically:

1. "Object-oriented C" is a pain in the ass. In my experience on this
project, I found that the time saved in creating flexible OO code that's
easier to change is largely eaten up by the "signal to noise ratio" (i.e.
explicit dereference of every data member) and the endless pointer
bookkeeping. I can only think of one significant "segfault" bug that did
_not_ involve some silly problem with untyped pointers/callbacks.

It is not so bad when simply *using* a class library like
GTK+, though it could be better. But the Octal interface requires
creating a lot of custom controls (i.e. the network editor in the
screenshots, the control boxes for parameters) and getting into the guts
of things. After working for a whole semester in Standard ML this makes me
want to scream.

The planned solution is to use GCC's support for object-oriented variants
of C in the core program and especially the GUI component. Nothing will
have to change for plugins which can still be plain C.


2. A tracker-style interface requires step-sequencing. I've been working
with musician friends in the studio and in live situations, and what I've
found is that step-sequencing is inflexible by itself. It can be an
enormous impediment to certain tasks.

Music software now is using piano-roll, MIDI-style sequencing, with the
option of step-sequencers for drum patterns in some applications, and event
lists. MIDI style channels can eliminate another "Buzz tracking
annoyance", which is the inability to treat voices within a machine as a
group
for the purposes of parameter editing.

After looking at this problem I realized it would be much simpler to
implement a general sequencer, which would allow placing events in pretty
much arbitrary positions (subject to PPQN as with MIDI sequencers) and
then work from there. I still believe that tracker sequencing, despite its
limitations, is one among several useful views of the data. I'd love to
implement a tracker view as one option.

To sum up: no, the project is not abandoned, it's just going through
growing pains. :-)

--
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal


_______________________________________________
Octal-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/octal-dev