beast, aldrin, buzztard (Re: ADSR (DaHdsr))

[Tim Janik <timj gtk org>]

On Mon, 11 Dec 2006, Leonard "paniq" Ritter wrote:

> Hi Hanno,
>
> I'm not really involved in this project, so take my comments with a
> grain of salt.

ok ;)

> after watching your huge batch of mails in the past weeks, full of new
> suggestions, I wonder if your invitation to feature creep is really the
> way to go. The problem is not really BEASTS lack in features. The last
> time I tried BEAST, it managed to crash itself in about under 3 minutes.

we have one crasher bug that seems to be hard to come by:
  http://bugzilla.gnome.org/show_bug.cgi?id=340437
we apprechiate any further input or test cases you might have.

> The project structure was archaic.

can you be more specific here please? we're constantly developing and 
refactoring beast, also adapting it to new development models, so i
fail to see where the project is archaic.

> There was lack of support for better
> audio backends.

audio backends are pluggable, so you can easily implement new ones.
we currently support OSS and via a seperate package ALSA.
an experimental portaudio has been written but had to be abandoned because
portaudio simply isn't properly maintained and doesn't cover a reasonable
feature set required for serious synthesis applications. also, a jack driver
is in development.

so i'm also not seeing your point here, except maybe that you're too 
impatient to wait for the jack driver to be completed ;)

> So I suppose what would really help development would be tracking down
> the benevolent dictator in this project and bugging him about the bugs -
> thus, doing some serious QA.

well, that'd be me i guess. and to some extend Stefan Westerfeld.
if you have any input on bugs, please provide it here:
  http://bugzilla.gnome.org/buglist.cgi?query=product:beast
or file a new one:
  http://bugzilla.gnome.org/simple-bug-guide.cgi?product=beast
i can assure you, we pay attention to the bug tracker.

> On development side, an upgrade of the project structure is required,

upgrade structure in what terms?

> adding a proper lightweight build system (scons), support for either

why should we replace GNU make and automake+autoconf?
i.e. what would be the benefit from doing that, given that the build
requirements of beast are already quite complex and could be made to
work with the current choice of tools.

> rtaudio or portaudio v19 as an audio backend, and some serious

i've adressed portaudio above already.

> refactoring, which involves mainly: removing all the IDL crap, thinning
> the code,

i think you simply fail to see the point of having an IDL compiler here.
being able to generate lots amounts of code *because* we have an IDL
complier gets rid of a lot of boilerplate code that programmers usually
have to write, and ("thinning") the amount of code maintainer by programmers
a *lot*.
there's documentation on the idl compiler and plugin writing online btw:
  http://beast.gtk.org/plugin-devel
  http://beast.gtk.org/sfidl-manual

> and porting of the frontend to a scripting language such as
> python,

that is in the works, along with a new canvas toolkit approach that's
supposed to reduce GUI code complexity a lot and alow us to be more
themable/skinnable similar to other proprietary music apps.
that approach is called Rapicorn btw:
  http://rapicorn.org/
  http://blogs.gnome.org/view/timj/2005/07/31/0

it'll just also take to time to complete if done correctly.

> so new feature additions and bugfixes become easy,

depending on the features, they are already easy to add.
that's what our flexible module/plugin system is for.

> and people
> stop worrying about e.g. 3 different types of complex types in the
> code ;)
>
> I would do this myself, but instead I decided to start my own tracker
> project, and we're progressing fast.

once your project comes along, you'll figure that issues like the Complex
type discussion we've had here recently (and successfully resolved btw)
are simply normal in a heterogenous programming environment.
and unless you opt to reimplement *everything* from scratch (including your
own language interpreter or compiler), you'll unavoidably end up with a
heterogenous environment. only experience tells such stories though ;)

looking around a bit, your project seems to be:
  http://trac.zeitherrschaft.org/zzub/wiki/Aldrin
described as a "successor to Jeskola Buzz", which is not exactly the
scope of beast. there are other projects out there that also aim in that
direction though, which you might want to contact about joining efforts
in some areas:
  http://www.buzztard.org/index.php/Main_Page
Buzztard also has a very active and interesting wiki btw, and it also has
active maintainers (which can not be said of most sound program projects).

> -- Leonard Ritter
> -- http://www.leonard-ritter.com
> -- http://www.paniq.org

---
ciaoTJ