Gearlib (Was Linking Machinces)

[Jared]

> 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.  

        This may entail a lot of porting of different things to fit the
octal architecture.  I don't see this being a problem, other than a lot of
hard work, and the benefits should make themselves clear, as I am going to
attempt to describe later.

> 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. ) 

        Having to build find/build/things sucks if you just want it to go
then, I think we all agree on that.  I also think we all agree that we
want Gearlib to be as stand alone as possible.  Again this means that if
you want to use some other library you are probably going to have to port
it to the Gearlib/Octal architecture and include it in Gearlib/Octal
itself.  The benefit that I am hinting to is that in the end, we are going
to end up with a bunch of tools with the same handle, which is going to
make things easier in the long run.

> 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.)

        Don't let RMS hear you talking about nonfree/bin-only, he'll kick
you off Gnu ;)
 
> 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. 

        This problem is similar to the first one.  If we do restrict
Gearlib to be stand alone, and two people do the same thing different
ways, and there are some people calling the shots (with group discussion
of course) to what gets included in Gearlib we *should* end up with the
*best* solution to the problem being included.

> 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

<snip>

        I think we have to be brave and separate machines building from
Octal and move it to Gearlib.  From my understanding (and apologies if I
hurt anyones feelings in saying this) Octal is to be the real time sound
processing framework.  It is also the machine control framework.  I am
unsure if it was ever to be a machine development framework.  

        Now, we are all talking about Gearlib and extra widgets for
machines and envelop editors and all sorts of good stuff, which we are
going to need some day or other, but as I see it, this isn't the real time
sound processing and machine control that Octal is.  This is more machine
building and I believe the domain of Gearlib.  Perhaps what we need to do
is make Gearlib incharge of the machines and the machine building
widgets.  Gearlib will produce machines that are ready to interface simply
and easy with octal (this will be the main duty of Gearlib. If you build
it with Gearlib it will be guaranteed to work with Octal).

        You initialise a machine, and with heaps of Gearlib calls you edit
waves, tweak filters, make weird bleeping sounds, you are only limited by
your imagination (and how hard the Gearlib folks work).  When you have
finished you click a button and your machine is ready and willing to be
dominated and controlled by Octal.

        Maybe my ideas on this are weird and distorted, and if the
decision to ever do this go ahead a lot of things need to be discussed
before proceding.  Things I can think of off the top of my head include:
        
        * File Format for your machines, once they are created and
initialised, where does the config info go?
        * Widget design and use, what do we need?
        * API issues, what front end are we going to impose on machine
creation and Gearlib use?
        * Many other things I am too lame to think of.
> 
> 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:
<snip>
> 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.)

        I agree totally. As I mentioned before Octal is the realtime
machine use and control framework, and I think it should stay that way.
(This addresses some of the concerns voiced earlier about having to change
parameter specifications.)

        Gearlib is a collection of machine building tools (lots of good
DSP things + the controls to use them).

        Any editor that came out of this would depend on Gearlib and have
nothing to do with Octal... (apart from the fact that Gearlib would owe
its existence to Octal).

> 
> > > 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 :-)

        I think the credit for that Idea goes to Luka, not me :)
> 
> >       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. 

        Most definitely.  I know I have said a lot of things that aren't
in the end really going to be up to me, however if we do decide to branch
off and make Gearlib somewhat separate, we are going to have to talk about
it lots and lots and lots, instead of racing off and ending up with a big
heap of kludgy code that's no use to anyone in particular.  Comments on
anything I have said most definitely welcome!

J