octalmachines & gearlib

[luka]

hi all

things are moving fast right now, so i'll try to explain a bit what i'm working 
on. dave asked me to become an admin at the octalmachines site 
http://octalmachines.sourceforge.net/. i accepted. this allows me to work on 
the website and more importantly - to add interested developers to the project. 
Yes, if you made a machine, this means you! Please, get a sourceforge id and 
send me a mail with 'i have id thisandthis, i want to upload my machines, i 
made this by now...' so i can add you to the team. After i do that, you will 
have read/write access to the CVS at sourceforge. 
If we all upload machines there, making big packs which users like so much will 
be no problem. 

Just to minimize on confusion: this cvs is separate from the new octal cvs at 
gnu: core -> gnu, machines -> sourceforge. The instructions for pulling stuff 
out from the sourceforge cvs are accesible from the octalmachines project page. 
Also, your machines need not be GPL - you can choose another license or even 
upload binary plugins. (what are sourceforge policies on this?)
 
With Dave we agreed on a simple scheme to make it harder for you to make a mess 
out of the octalmachines CVS - each developer will 'own' a directory (this 
could be your sf id or the nick you put in longnames if its different) and all 
their machines should go in there. This doesn't mean you can't check in fixes 
for other files, but it will establish a primary 'owner' of a machine in a 
clear way.  

the new page should come up soon - i am working already on the php 'portal' 
which will present all the info and enable web users to participate in various 
ways  - posting reviews,... this will be something like buzztrack or 
buzzmachines, of course a tad less ambitious at first.

allow me to paste from the welcome message there, it will probably clear things 
up a bit so you know what to expect - and will be able to react to it:

<BLURB>
The octalmachines project aims to unite the efforts of many developers who want 
to contribute plugins for the OCTAL free music system. We will collect 
contributed machines, documentation, and various meta-data about machines - 
versions, parameter lists, presets, CPU/RAM requirements, bugs, tips and votes. 
This is the project you should join if you want to publish your plugins, port 
plugins from other APIs, or help debug, review and document existing machines.

The infrastructure at SourceForge works to our benefit. Developers can use CVS 
to share the code and the octal-dev mailinglist to coordinate their efforts, 
and the rest of the community can download, comment and help trough this 
website. There are a million things to do before OCTAL will do what we each 
want it to the way we want it to - on any machine we might want it to. But at 
the end, we will have it. BUZZ proved the concept works - and OCTAL will try to 
make it right this time.

A subproject of octalmachines is called Gearlib - we are dreaming of a free 
library of machine "parts" like oscillators, filters, mixing, envelopes and FFT 
routines. They can be reused to make simple but powerful and consistent 
machines - other projects like csound and pd prove this is possible, and can 
serve as a base to influence the gearlib design. If you feel you can help, 
please post to the octal-dev mailinglist.
</BLURB>

> Yeah. I should really talk to luka and put together a little blurb about
> what his Gearlib idea is supposed to be. Basically a library of common
> DSP functions and stuff so that writing wavetable machines becomes
> easier. The wavetable stores instrument attributes, but the machines and
> Gearlib interpret what it means sonically.

i see gearlib as two kinds of routines, basically - general DSP algos which pop 
up in any octal-like system and second the routines which will make the octal 
API easier to use, but probably wouldn't make sense in another environment. so 
we can see that its a mixed thing of collecting tried and true code and 
implementing whatever will make machines more elegant in octal. 

in parallel, i'm trying to collect all plugins ever published on the list to 
see how many still work - and to fix the ones that don't work anymore. if 
anyone can fix the sox filters from neil nelson for the new api that'd be 
great...

ok time to sleep
more soon
very excited about all the messages today :)

LF

i'm adding this on bottom since its unrelated to sourceforge, please respond if 
you have an opinion:
if there was a way for the machine to update some of its parameters from 
ox_work() by calling an appropriate func from the package, we could finally 
have 'analizer' machines without adding to the param API. Then the user could 
tell the gui to tell the core which other parameters should mirror this one - 
set up dependencies on parameters so one machine (changing one of its own 
params) could drive other machines parameters (with a one-block delay).