ADSR (DaHdsr)

[Hanno-2]

A week ago or so we talked about a DELAY in the ADSR-Module. After studying
the LAC2006 I would appreciate if we could have another factor: the HOLD

The ADSR should be therefore expanded by a sixth parameter. Just after
DELAY,ATTACK the HOLD tells how long the maximum value should be hold before
it DECAYS to the SUSTAIN and RELEASE.

At the moment I have no sound in mind that uses this feature but with slow
coming, soft or deep sounds this would be nessecary I think and after I read
that Pons Adriansen is doing his Swami with this kind of expanded ADSR I
think we should too. Because with this in it we can build any Wave-Sound that
can be done in Swami. Simple trick and cheap to have, I think.

Hanno
_______________________________________________
beast mailing list
beast@...
http://mail.gnome.org/mailman/listinfo/beast

[Leonard "paniq" Ritter]

Hi Hanno,

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. The last
time I tried BEAST, it managed to crash itself in about under 3 minutes.
The project structure was archaic. There was lack of support for better
audio backends.

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.

On development side, an upgrade of the project structure is required,
adding a proper lightweight build system (scons), support for either
rtaudio or portaudio v19 as an audio backend, and some serious
refactoring, which involves mainly: removing all the IDL crap, thinning
the code, and porting of the frontend to a scripting language such as
python, so new feature additions and bugfixes become easy, 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.

On Mon, 2006-12-11 at 10:01 +0100, Hanno wrote:

> A week ago or so we talked about a DELAY in the ADSR-Module. After studying
> the LAC2006 I would appreciate if we could have another factor: the HOLD
>
> The ADSR should be therefore expanded by a sixth parameter. Just after
> DELAY,ATTACK the HOLD tells how long the maximum value should be hold before
> it DECAYS to the SUSTAIN and RELEASE.
>
> At the moment I have no sound in mind that uses this feature but with slow
> coming, soft or deep sounds this would be nessecary I think and after I read
> that Pons Adriansen is doing his Swami with this kind of expanded ADSR I
> think we should too. Because with this in it we can build any Wave-Sound that
> can be done in Swami. Simple trick and cheap to have, I think.
>
> Hanno
> _______________________________________________
> beast mailing list
> beast@...
> http://mail.gnome.org/mailman/listinfo/beast

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


_______________________________________________
beast mailing list
beast@...
http://mail.gnome.org/mailman/listinfo/beast

[Tim Janik]

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

[Stefan Westerfeld]

   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
beast@...
http://mail.gnome.org/mailman/listinfo/beast