octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Spam, Gearlib, and C++ issues [Was Re: Gearlib as a DSP Library]


From: David O'Toole
Subject: Spam, Gearlib, and C++ issues [Was Re: Gearlib as a DSP Library]
Date: Fri Jun 8 18:45:09 2001

First of all, I have changed the list configuration so that only list
members may post. That should stop the strange flood of Korean
advertisements we have been getting lately.

If anyone starts getting their posts bounced because they post using a
different address than they subscribe with, please contact me directly
at address@hidden and I will fix your case individually. I'm sorry for any
inconvenience this may cause, but it's either that or spam...

> Hello everybody!
> I'm writing new filter machines. Some of them will provide IIR filtering

Hey!

> hope one day we'll find in Gearlib site lots of tips, articles, code
> snippets, web links, etc. especially related to writing good machines for
> Octal.

Cool :-). I think setting up a mini-slashdot article type of site would
help with that... perhaps something based on a prebuilt program like
PHPNuke. We'd been planning to set up something at the sourceforge site,
but I think it might be much quicker to use a pre-existing program at this
point.

> Suppose I'll want to write a new synthesizer: I'll simply have to grab an
> oscillator and a filter, or something else, from Gearlib and put these
> functions in my machine code. Now, I think that it would be better if these

> Now, that's the point. How should be this library? For example: Should we
> adopt a naming convention ? For example similar to that of GTK+ (this is
> what I'm doing with my machine's C code)? How should happen signal routing

I guess we should talk about guidelines. The main ones I'm going to focus
on for now are the guidelines that will help ensure that everything goes
smoothly when using code from gearlib (both for the user and for the
developer.) The machine dev community will probably have additional
concerns.

GEARLIB GUIDELINE OPINIONS FROM DAVE
------------------------------------

The main purpose of gearlib, as I see it, is to provide a common set of
DSP functions that are often used in different octal machines. The
machines will link with the gearlib shared library at runtime (i.e.
no static linking or copy-and-tweak at the source level.) This brings up
some issues.

1. GENERALITY. We should be careful that only generally useful things go
into Gearlib, not things that are just relevant to one machine or a
narrow class of machines. From the user's perspective, having to update
your copy of Gearlib every time you download a machine isn't good.

2. AVOID REDUNDANCY. It's best to avoid having several API's with the
same function in Gearlib. One of them will inevitably become more
maintained and the others will fall into disuse, causing maintenance
problems for machines as well as wasted space.

3. STABILITY. Obviously we don't want stuff in gearlib to segfault,
because then everything will :-). Stability is extremely important if
gearlib parts are going to be linked to many machines, because if you're
in a live setting you do NOT want any problems, believe me---Buzz recently
crashed on me during a set in NYC, and it sucks. (There are clips at

http://dto.qwsi.net/mp3/levelx-live-clips

but obviously I did not include the crash part in these excerpts. These
are kind of experimental, I am now working with a female vocalist and this
was only our 2nd live show.)

So how do I propose we achieve goals 1, 2, and 3? By building the library
with a gradual process. The first phase involves people writing machines,
discussing them, testing them, and seeing what common functions pop up.
If several people have implemented different versions of a function in
different machines (perhaps without knowing it) or if several people
design a reusable component they'd like to write together, then that's a
candidate for putting something in Gearlib. Since several people agree
that it's a good idea, that satisfies #1.

Second: merge code, prune API's, argue, fistfight :-) until a single
interface/function name/implementation has been decided on and bug-tested,
and check it into Gearlib and add a section to the manual (more on this
later.) Deciding on one copy and bug-testing it should satisfy #2 and #3.

CODING STANDARDS IDEAS
----------------------

These are mostly aimed at keeping things consistent with the Octal
codebase and the larger gtk/gnome/unix world.

1. no_uppercase_letters, in a style similar to Octal and GTK+
2. Standard "prefixes" for different parts of the library, i.e. filter
related functions could start with flt_*
3. An "abstract C" style like most things in the gtk/gnome world, i.e.
abstract data types but not a lot of inheritance
4. Everything should work from C-based machines... don't require C++. Some
recent problems that have been popping up with C++ based machines have
given me pause, and at this point I consider ox_wrappers and C++ machine
writing to be "experimental." Basically it's linking problems---the C++
based machines can fail to load properly if they link against external
libraries, so obviously gearlib could be a problem. Using any of the
interesting features of C++ seems to mess it up (i.e. code will not get
emitted for out-lined copies of virtual functions so the link will fail
for virtual calls). I think we need some more time to see if this can be
ironed out---getting a machine to work shouldn't require the end-user to
fool around with binutils like I had to.

I guess the main idea is this: balance the need to share common code with
the need to keep the library focused, sane, and high-quality... while
simultaneously avoiding anything that could cause headaches for the user
trying to download and install machines.

More on this later... I will be around coding, feel free to join me in
irc.gimp.org channel #octal if you want to hang out or chat...

-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]