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 _______________________________________________ beast mailing list [email protected] http://mail.gnome.org/mailman/listinfo/beast
