[LAU] Anyone interested in JACKifying Beatrix?

Robin Gareus robin at gareus.org
Fri Apr 20 10:14:22 EDT 2007


Fredrik Kilander wrote:
> On Wed, 18 Apr 2007, Ken Restivo wrote:
>> On Wed, Apr 18, 2007 at 05:30:29PM -0700, Tim Howard wrote:
>>> Hi,
>>> I was just thinking it would be really great if someone (with
>>> programming skills several notches higher than my own) could JACKify
>>> Beatrix.  Now, I realize that Beatrix is not GPL'd software, so it
>>> doesn't have anywhere near the community interest that it COULD
>>> have... <ahem>
>>> ...
>>> Any thoughts?
>> Have a look in the archives. This was discussed recently.
> 
> Hi,

Hi Frederik,

nice of you to join in; that simplifies things a lot!
IMHO it's not so much the code but the license that blocks development.

If you consent to allow beatrix code to be modified (and modifications
to be distributed,...) it's really easy to give it a jack-audio port.
Your code is nicely structured and it might even make sense to rewrite
it as jack-midi & jack-audio client.

I understand your motivation, of keeping beatrix a Hammond-organ - and
not a DIY Organ kit. - maybe it makes sense to have the whole-synth-core
(incl. reverb & whirlProc) insinde a DSSI plugin..

I understand your concerns about version splitting or not receiving
feedback on redistribution - but watching the linuxaudio community for
the last years there have been no such experiences; rather the opposite:
good branches usually get merged back into the main-tree and the bad
code just vanishes..

the GPL even gives you protection against abuse. - i'd actually be
surprised if parts of tonegen.c are not hidden in some non-open-source
synths out there...
If the "compile yourself" is intended as hurdle to get people interested
and and involved.. it does not seem to work that way for un*x audio
dev&users folks.


> I do have an interest in making Beatrix more suited for plug-in
> environments, but it is a long road. The main issues that concern an
> adaptation are (in no particular order):
> 
>  * The system sample rate is more or less fixed at 22.05 KHz.

I wondered about that. There are a few obvious places that can be worked
around easily. Are the hardcoded derived parameters in the code?

>  * The system buffer size is set at compile-time.

is there any reason why
oscGenerateFragment(buf, nframes); preamp(), reverb() and whirlProc()
would not work with a dynamic bufsize; after
#define BUFFER_SIZE_SAMPLES some_variable.


>  * Dynamic memory is considered not to be a problem and is not released
>    when free (this is not a leak - it just remains allocated but unused).

that'll be fixed when it's under GPL.

>  * There is no support for shutdown/unloading.

trivial.

>  * The reverb FX hogs the cpu due to denormal numbers.

if you say so.. - I don't hear it ;)

>  * The rotary speaker FX has a flaw for which two fixes exist: either
>    a huge lookup table or additional cpu cycles. Which is most
>    appropriate?

if you document how to generate the lookup table: memory is cheaper than
CPU. - but then again how huge is /huge/ and how long does it take to
optimize the data structure...

>  * There is no real user interface and for portability there is no UI
>    service interface.
> 
> Further, to take full advantage of plug-in environments the overdrive,
> reverb and rotary effects should probably be broken out of the main
> chain. This creates a conflict with the current configuration mechanism
> which of course assumes that they are integrated. This is probably a
> secondary issue, since as independent FX units they need their own and
> independent control surfaces anyway.

There's for surly many details to worry about... - but it seems worth to
address and fix them..

#robin



More information about the Linux-audio-user mailing list