octal-dev
[Top][All Lists]
Advanced

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

[Octal-dev] new octal "user"


From: Luca Padovani
Subject: [Octal-dev] new octal "user"
Date: Wed, 7 Jun 2000 08:29:06 +0200

Hi to all,
I'm a new entry in the OCTAL mailing-list. I'm really, interested in the
project and I'd be happy to contribute. Actually, I planned to write a
similar tracking software for Unix/Linux a few months ago, then I gave
up due to lack of time.
I'm quite experienced with fasttracker only, I don't know very much about
buzz (which I find difficult to use), so sorry if I write about obvious
things.

In the archived mail I've seen that most of the discussion is
on the "backend" of the tracker, i.e. machines, sample generation and
effects. I think that a great traking-software is also made of a flexible
front-end, with advanced editing capabilities. In particular, in my previous
project I decided to use GUILE as the extensible language for editing
and interacting with the tracker. Although a user interface is mandatory
for such kind of applications, one has to recognize that as operations and
editing features get more and more complex, the user interface becomes a
kind
of bottleneck for the experienced user. Moreover, some iterative and boring
operations are more easily described by a little command rather than by
a FINITE and PREDEFINED set of toggle/check buttons.
The use of a real programming language (as GUILE) allows automatic
transformations on the tracks to be done in a flexible way. Moreover, one
can think of building little libraries of useful editing functions. Under
these
assumptions, the graphical user interface is just used as a higher level
abstraction to activate such chunks of code (much like GIMP).
An embedded language is also useful for the automatic configuration of
complex machines, and in general for the proper setting up of the
environment
needed by a given song.
The other advantage is that the embeddable language needs very little work
to be integrated succesfully, while the developing of a suitable GUI
usually takes a lot of time. In this way one has a usable system even if the
system is not yet complete.

Another aspect I've never seen in tracking software, is a flexible
mechanism of sharing common blocks of events/notes. In common tracking
software (I refer to fasttracker II, sorry if I don't know much about
others)
the smallest sharable block is the pattern.
In my view, a song is made of patterns, and patterns are made of tracks,
tracks are made of sequences of notes.
Such modular architecture is probabily too fine-grained, but I think that
track sharing is a feasible and useful compromise.

Finally, it could be nice if patterns of note could be saved in a neutral
format: I think that today XML is a good choice, because of its
standardization, platform independence, automatic transformation
capabilities
and so on. BTW, libxml from GNOME is a great XML parsing library.

Regards,

 luca





reply via email to

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