RE: Gearlib as a DSP Library

[Unkargherth]

> -----Mensaje original-----
> De: address@hidden [mailto:address@hidden nombre de
> Marco Ballini
> Enviado el: miércoles, 30 de mayo de 2001 19:01
> Para: address@hidden
> Asunto: Gearlib as a DSP Library
>
>

>
> 2) I'm trying to writing functions and structures that can be reused by
> other machines: something that could go in the Gearlib and
> hopefully be used
> by other machine developers. When we'll have enough code in
> Gearlib we will
> be able to write robust machines and (especially) optimized for
> Octal (or a
> similar system).
>
> 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
> pieces of code had some kind of standardization. I mean that GEARLIB (or a
> part of it) could become a DSP LIBRARY (something like STK or others, but
> thought to be used in Octal machines).
>
> Yes, you already discussed about this (in March 2001) and it seemed to me
> that many (well some, I don't know how many) of you agreed that
> Gearlib (or,
> I repeat, a part of it) could turn into a DSP Library.
> 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
> inside a machine? I think that I could write my functions and
> structure (and
> thus machines) more easily if I had to follow some standards.

As when I startted to upload code to the GEARLIB section of cvs in
octalmachines project i was the first, I used ( or tried to) my own naming
conventions and guidelines set. Obviously i'ts open for discusion, but
bassically

.- All the source files ar named Something Like GR_<Name>.xx

.- All the functions are named something Like GR_NameOfTheFunction

.- All the functions are classes something Like GR_NameOfTheFunction

.- All the public methods are named GR_ClassName::MethodName

.- All all the private/protected methods are named as you want

.- All the Attributes (supossing they are private to the class) are named as
you want

.- I'm tried to avoid satic declarations ( dto knows it well )

.- Avoid int's in calculations

.- At the risk of seeming stupid for the obviousness, but seems important.
Better don't include any code that doesn' clean compile !!!

.- I tried to make ( whenever i could figure out) a C version AND a C++
Version ( ie define structures and functions AND THEN a class wrapper to use
it from C++)

.- There's a  GR_Base.h file who make all non GearLib Includes with the
convenient #ifdef's. And it's the Only Place where we include this files.
>From GEARLIB files we imake #include GR_Base.h

.- There's a GR_All.h file that make #inlcudes of all the GR_xxx.h files
 to simplify de GEARLIB Make)

.- While we discuss and agree another way to do it, all params from CORE
OX_API shoulds be passed to the functions by value
.- The standard CORE API def's ( param, samp and so ) shouldn't be used In
GEARLIB ( to maintain the independence)

I tried to follow this Guidelines in all the source i've uploaded ( and the
parts that I didn't uploaded too) but if you check it, be prepared to find
mistakes realted to the previous list. I'll try to correct it as soon as
posible



>
> Thanks for any answer,
> marcob
>
>
>
>
> _______________________________________________
> Octal-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/octal-dev
>