Improving beast

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Mon, Dec 11, 2006 at 03:48:20PM +0100, Leonard paniq Ritter wrote:
> I'm not really involved in this project, so take my comments with a
> grain of salt.
> 
> 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.

Well, nice to hear that, because it means that you're saying that BEAST 
does in fact provide what we want it to provide: a nice environment for
creating synthetic music. Of course we do try to implement the features
that users are missing while working with BEAST. If Hanno can't do the
things he wants to do without new features, we try to implement them, as
time permits. Thats equally true for any other user who tries to use
beast, but finds that only a little something is missing.

> The last time I tried BEAST, it managed to crash itself in about under
> 3 minutes. 

In fact there is a known bug which causes beast to crash after a while.
When I work with beast, I don't experience this problem, because I start
BEAST using

G_SLICE=always-malloc beast

which seems to either workaround or at least make it harder to trigger
this particular bug (#340437).

Anyway, we're of course trying to make BEAST as stable as possible for
the next release. Details about all that can be found in the bug
tracker. If you're a user, and BEAST doesn't behave the way it should,
please

 - provide feedback (we can't help you if we do not know you have a
   problem)
 - if beast is not stable, try the temporary workaround

> The project structure was archaic.

Whatever this means (I have no idea).

> There was lack of support for better audio backends.

Well, JACK support is being worked on. Its a bit more tricky than it may
be in other projects. One reason is, that for multi-core CPUs for multi-CPU
machines, BEAST will support distributing the workload across
cores/CPUs. So we're definitely not putting the audio computation into
JACKs callback.

I'll only comment on a few of your suggestions: Tim already commented on
others.

> support for either rtaudio or portaudio v19 as an audio backend

I really tried writing a PortAudio V19 driver to do it "the generic
way", instead of working on a native JACK driver first. I needed to
contribute stuff to PortAudio to make it work at all. And BEAST using
PortAudio using JACK kind of worked. But in the end, there will be JACK
features such as JACK midi or transport where it will be necessary to
code against the JACK API directly. So a generic audio backend is not
good enough.

However, possibly we'll keep the PortAudio driver for the windows port.

> removing all the IDL crap

SFI + SFIDL allows us to
 - code frontends in more than one language (C, Scheme and C++ currentlv
   supported, Python planned)
 - write plugins with meta-data easily (IMHO more pretty than the LADSPA
   1 + LV2 standards)
 - do distributed stuff (like two computers controlling the same BSE
   sound engine for a live performance)

Its in the third generation, where the previous two were aRts + CORBA
and aRts + MCOP, so I am pretty convinced that its "about right" now.
You may see migration artefacts though, as BEAST can not be instantly
IDLified and ported to C++. We're working on it, one step at a time,
though.

> the code, and porting of the frontend to a scripting language such as
> python, so new feature additions and bugfixes become easy

Planned.

> I would do this myself, but instead I decided to start my own tracker
> project, and we're progressing fast.

The more people are actively working on free music software, the better.
That will allow more musicians to start using linux because there is
high quality audio software.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan