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
@@@ [email protected]
@@@ www.gnu.org/software/octal