re: New in CVS

[David O'Toole]

---------------------
---They are a collection of conversion functions. Most of the extracted
---from OCTAL Package.c so it can be called without the machine object
---being intantiated. primarilly from Initialize and describe methods.
---------------------

Well, you said this is a request for comments version :-) So here are my
comments. 

This won't work. If you keep your own copy of the frequency table you'll
break the system-tune feature. 

The user /must/ be able to re-tune the note table for all machines
globally, otherwise Octal would be useless for integrating synthetic
instruments with live/impromptu recordings, where very often you will
not get everything recorded with a perfect 440.0 Hz base.    
 
I guess this is a good example of figuring out what should go in gearlib
and what should go in the host package---the pitch table needs to be
configurable on a global basis, and machines delegate to the host (and
therefore the user) the task of determining what pitch goes with a note.

Your comment about making them "ox_api independent" sounds like a decent
rule for deciding where something should go. If making it ox_api
independent would break a feature in the host, don't do it :-)

(Of course machines like filters may still use raw frequencies. The rule
is, if you're going to present a choice to the user as a "note", then
the actual pitch data should come from the package functions. Otherwise,
do whatever you like.)

------------------------
---David: What's the reason fro this two 
---methods beign deeclared as static? 
------------------------

Initialize (also ox_init) /has/ to be static because it will only be
called when it's impossible for any machine instances to exist. The init
function is where you tell Octal about your machine type (by filling in
that machine_type structure.) Octal needs this information to create an
instance of your machine, and since it doesn't get the information till
Initialize is called, there is no way to call "object.Initialize" since
no objects can exist before then. 

Describe (ox_desc) is just your machine library's function for making
its own parameter values into human-readable text in a consistent way.
It has nothing to do with machine instances, and because of this, there
are places in the host where there's not going to be any machine
instances handy to pass to it if it weren't static.

Furthermore, because ox_desc is a GUI-related function, I cannot
guarantee that it's going to get executed in the same thread as all your
other Work and Event stuff. (In fact, right now, it does happen in 2
different threads.) So unless you want to put mutexes on every machine
instance .... :-)  

It may be important to be able to call package functions from Initalize
(ox_init.) Like the sampling-rate function. I guess this could be done
by adding a pointer to the oxapi_package to the machine_type structure.
I will look at what's the best way to make this work.  

---------------------------
---On the chat at IRC. Any way to statically allocate the Oscillator
---object in pwgen without knowing in advance the number of Oscillator
---tables we have they are in an unkwown number of external files) ?
---------------------------

Count them in initalize() and set up your table then. You can still
allocate the arrays dynamically (i.e. with malloc), I meant "static" as
in "the class has just one copy of this table, and you set it up at
initalize() time." 

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