RE: Linkging libraries in machines.

[David O'Toole]

My suggestion is to avoid using external libraries if you can. Otherwise
Gearlib may never have anything put into it. :-). Also, part of the
purpose of Gearlib is to prevent having to install a zillion libraries
(possibly all with fun version problems) to use a given song setup.
Reducing the "brittleness" factor of the machine repository is a
definite goal.  

But on the other hand, we shouldn't ignore when a free/gpl library is
doing great and nontrivial signal processing. I wouldn't think that
having Gearlib require FFTW is a big deal as long as everyone agrees
it's good and needed, but it is *so* easy for this to get out of hand
that we should restrain ourselves.

Several things we should avoid:

1. Users having to search for/download/build some library for their
platform every time they download a machine. ( Having the Gearlib
package depend on something else might be ok if there is common
agreement that it's needed. ) 
2. Machines depending on any nonfree/binary-only libraries (since the
machine is required to render songs made with it, using a nonfree
component would cancel out the goal of having song files that can always
be rendered compatibly with free software. a binary-only dependency can
also tie a song to a particular platform.) 
3. Users having to install several different libraries that do the same
thing. Having general discussion on what gearlib's dependencies are and
what should/shouldn't go in will prevent redundancies. 

>       I think this is the point I ask Dave "Please can we have more
> widgets?". And not just widgets for when the machine is going.  For filter
> design routines, you are going to need a relatively large set of complex
> design tools (graphs, envelop editors etc...) at startup, but once this is
> done, you'll just want to use the filter with, say, amplitude control.


That is probably a good idea for an extension, since it needs not just
new widgets but an entire new kind of parameter. Octal's API currently
deals with real-valued scalar parameters, and we've been making
everything else (waves, envelopes, etc) a "shared resource" that Octal
manages and machines can get access to. (This makes sense because we do
not want to pass a 234K wave by value :-).  To make widgets for directed
graphs (probably useful) or envelope editors, we'd need to work a bit
more. We could

1. Make graphs and envelopes "shared resources" and provide editors for
them ...... or
2. Make special control types that can accept vectors or user-defined
structures. To do this one we'd need to resolve issues like: where does
the user interface come from for these? the machine writer has to do it?
how is the current state saved and loaded? do we use plain text to store
the current filter design as a "chunk" in the song file? if so, your
format must NEVER break between versions of a machine.

#2 has some issues but it's doable. When the time comes we should talk
about implementing some solution.  

>       Does/Will Octal have the ability to do offline rendering? That
> would make it really cooooool. A tracker, and with the right
> machines/generators you get a sound editor for free.

That could work, but a music arranger/sequencer/mixer and a digital
audio editor have completely different interfaces. So it would probably
be not "free" but a lot of additional work to implement the 2nd
interface. Also, the two types of program aren't used in the same way:
Octal is designed around generating a stream of audio over time and
dealing with sequenced events, generating everything on the fly; audio
editors have completely different requirements related to precaching
data from disk and jumping around random-access with transport controls.
They typically use editing-decision lists to keep track of what's been
applied to the audio and on what ranges (either that or they just make
destructive changes and keep an undo history.) This is a LOT of stuff
that would probably be better done in an app made just for digital audio
editing. 

I think a much more likely scenario is being able to use Octal effects
in an audio editor. Turning Octal into one would make it much more
complicated (and probably still not as good as a dedicated audio editor
program.) 


> > for your machine, use it! those users who can't compile or install a
> > library will get your machine anyway trough binary releases. a bigger
> > problem is portability - some libraries are not available on a lot of

Luka, I don't see binary releases of plugins being a viable way of
distributing machines. It will likely be quite awhile before we can make
any guarantee that there will be binary-level compatibility between two
particular builds of Octal, if ever. Compiling them can be automated
after download with a trivial "install machine" script, and they're tiny
enough that downloading even a large machine's source would be pretty
short. 

> > i think not. we want to collect good (best) solutions particularly for
> > our problem, ie generating or processing sound buffers fast (and
> > reasonably accurately), plus dealing with the octal api and other
> > issues specific to unit generators. we also want scenarios where
> > adding some code to gearlib would expand the capabilities or increase
> > performance of all conforming machines. we want to work as closely as
> > possible with machine developers and core developers, but as these

I tend to agree with Jared.... if we are reluctant to depend on outside
code snippets, then I think good stuff will tend to fall into Gearlib.
Which is great, because then gearlib can become a library in its own
right. Maybe other people will want to depend on gearlib someday instead
of vice versa :-)

>       Maybe we should put together a list of basic machines/routines
to
> kick gearlib off?  Maybe using the sourceforge set up, people could
ask
> for or be assigned tasks?

Sounds like a good idea. If we have people discuss API's first then the
best ideas will tend to float to the top. This is especially important
if gearlib is to provide services for a lot of machines... the API has
to be clean. 


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