ADSR (DaHdsr)

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
beastgnome.org
http://m
ail.gnome.org/mailman/listinfo/beast

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
> beastgnome.org
> http://m
ail.gnome.org/mailman/listinfo/beast
-- 
-- Leonard Ritter
-- http://www.leonard-ritt
er.com
-- http://www.paniq.org


_______________________________________________
beast mailing list
beastgnome.org
http://m
ail.gnome.org/mailman/listinfo/beast

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:bea
st
or file a new one:
   http://bugzilla.gnome.org/simple-bug-guide.cgi?produ
ct=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.or
g/plugin-devel
   http://beast.gtk.or
g/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://ww
w.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-ritt
er.com
> -- http://www.paniq.org

---
ciaoTJ
_______________________________________________
beast mailing list
beastgnome.org
http://m
ail.gnome.org/mailman/listinfo/beast

   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/~stef
an
_______________________________________________
beast mailing list
beastgnome.org
http://m
ail.gnome.org/mailman/listinfo/beast