axonlib :: v0.1.0

[ccernn]

interested in making vst plugins for linux (or win32)?

-- (copy/paste) --

axonlib v0.1.0

back on track (and beyond),
completely rewritten from scratch,
plug-devel 'api' is solidifying, coagulating,
lots of new features, lots of squashed bugs,
basis is (hopefully) more stable than ever,
and if we're lucky, more 'future proof',
so, we bumped up the version number.

"..a single axon, with all its branches taken together, can innervate multiple parts of the brain and generate thousands of synaptic terminals.." (...)

"selling points":

OVERVIEW:
* opensource, c++
* binary format abstraction for vst plugins and excutables on linux and windows
* common look, feel, functionality among platforms
* few external dependencies
* compile scripts with simplified command lines for the gnu gcc compiler
* tiny and compact binaries with no big, external libraries needed
* cpu efficient, code prepared for compiler analysis and optimization
* options to disable code or functionality that is not needed
* flexible axl license, (generally gpl w/ exception for proprietary use)

CORE:
* builtin fast memory allocator routines (and leak detection functionality)
* builtin routines for low-level string and memory manipulation
* heavily optimized mathematical functions and approximations
* intuitive debugging functionality & helpers
* static and runtime assertion

GUI:
* hierarchial gui, flexible, skinnable, auto-layout, sizeable, moveable etc
* resizeable window/editor (in plugin hosts as well)
* mouse cursor shapes, hovering hints, mouse capture, modal widgets
* low level gfx (gdi/xlib) canvas, surface, bitmap etc
* support decoding 32bit pngs from memory or from an external file
* scalable, alpha blended bitmaps
* partial support for antialiased, transparent lines & textured polygons

DSP:
* polyphonic voice manager and event scheduler
* modular audio graph with connectable dsp modules
* rbj filter bank
* basic oversampling container
* chamberlin state variable filter
* rms approximation
* envelope follower
* basic waveform generators

PLUGINS:
* lots of included example vst plugins
* simplified creation and use of parameters
* easy host tempo/sync handling for audio and midi
* can load external files directly from plugin
folder on both linux and windows

OTHER:
* basic read/write access for external files
* utility methods for bit manipulation and conversations
* scripts, stack-based, 4th inspired, rudimentary compilation (bytecode)
* builtin, random number generators
* mersenne twister implementation, customized for small binary size impact
* fft implementation
* more...

[..and this is probably already outdated..]



screenshot with:
- jost (linux) + axDemo/fx_grains
- reaper (win32, via wine) + axDemo/fx_grains
- standalone axDemo

test binaries:
- linux.tar.gz (686k)
- win32.zip (973k)

contains:
- vst plugins: axDemo, fx_blur, fx_distortion, fx_freeze, fx_grains, fx_svf, fx_tepodelay, fx_wgtavg, midi_transpose, syn_poly, test_gain_gui, test_gain_gui_skin, test_gain_gui_nogui
- executables: axDemo, fx_grains, fx_tempodelay, test_gain_gui, test_gain_gui_skin

various levels of buggginess...
these, and lots more will be bugfixed, tweaked and developed further as the library progresses.

still available (for a limited time):
some plugins made with an older version of axonlib (pre r151):
- ccernn.audio/vst

we would appreciate:
- bug reports
- questions
- ideas
- comments
- contributions !
- discussions
- ...

subversion (latest sources): axonlib
svn snapshot (always a little outdated): axonlib-v0.1.0.zip (r379, 07.jun.2010)

- ccernn & neolit123

"..axons often follow very precise paths in the nervous system, and how they manage to find their way so accurately is being researched.." (...)

.....

[ccernn]

and...
ladspa support is now basically in place!
now you can compile your plugins (unmodified) to:
windows exe, windows vst, linux exe (binary), linux vst, linux ladspa
should we add lv2 format next?
or dssi? or pd-externals...
[or properly 'finalize' what's already in there?]
time will tell..
our personal needs and motivation will decide,
unless there's any incoming requests or responses.
- ccernn

[brummer]

should we add lv2 format next?

The possibility to build a stand alone binary and a LV2 plugin will surly a big plus, . . .

So aixonlib is written in C++, with languages are supported by axonlib to write the plugins ?
Is axionlib a bit like a IDE ? or did it just comes as lib to included in my projects ? ??

greats brummer

[ccernn]

The possibility to build a stand alone binary and a LV2 plugin will surly a big plus, . . .

i've just had a quick peek at the lv2 specs, and it looks kind of like a nightmare, with all the extensions, and stuff... but will look more properly at it in a while... i think i will add the dssi things first, as that looks a bit simpler to do..

So aixonlib is written in C++, with languages are supported by axonlib to write the plugins ?
Is axionlib a bit like a IDE ? or did it just comes as lib to included in my projects ? ??

it's a library, or perhaps, more a framework. it's c++ only, consisting of .h files only (so it's also a bit like a templates). you make a sub-class of the axFormat class, and inherit/implement the virtual methods you need/want. and the low-level layers take care of everything else, like platform and format abstraction, and calling your plugin class methods when needed..

this way, your main .cpp file doesn't need to be modified when you want to compile your plugin to another platform (linux or windows), or for another format (exe/vst/ladspa/..), the lower layer classes take care of the differences...

as an example, here's the axonlib variant of the (infamous?) AGain example from the vst sdk:

Code: Select all

#include "format/axFormat.h"
class myPlugin : public axFormat
{
  private:
    float m_Gain;
  public:
    myPlugin(axContext* aContext)
    : axFormat(aContext)
      {
        describe("test_gain_nogui","ccernn","axonlib example",1,AX_MAGIC+0x0001);
        setupAudio(2,2);
        appendParameter( new axParameter(this,"gain","",0.5) );
        setupParameters();
      }
    virtual void  doSetParameter(axParameter* aParameter)
      {
        if (aParameter->getIndex()==0) m_Gain = aParameter->getValue();
      }
    virtual void  doProcessSample(SPL** aInputs, SPL** aOutputs)
      {
        *aOutputs[0] = *aInputs[0] * m_Gain;
        *aOutputs[1] = *aInputs[1] * m_Gain;
      }
};
AX_ENTRYPOINT(myPlugin)

and this can be compiled with the included compiler scripts:

Code: Select all

./compile test_gain_nogui.cpp

to have a linux vst plugin (.so)
various arguments to the compiler scripts (-win32, -exe, -ladspa, ...) allows selection of resulting format, platform, etc..

- ccernn

[ccernn]

a little update:

axonlib is almost back on track.. exe and vst is working nicely, ladspa is a pain in the ass, instantiation and parameter handling is very different from vst in lots of ways, so several times i were close to just say "f**k this", and throw out ladspa support completely... but we found ways to get around the limitations and differences, so they could fit into the axonlib concept, without the dirty hacks/cheating we did with the previous version.. quite a lot of the low-level base stuff had to be fixed and changed to make it work how we wanted.. hopefully dssi and lv2 will be a little more 'sane' :-/

after all those "argh!" and "wtf", i'm not sure if i really want to torture myself by adding in generic plugin hosting support too... but we'll see..

so, if everything goes according to schedule, in a while, there will be quite a few new ladspa plugins (and vst) to play around with... cross-porting from vst to ladspa, and opposite.. (already ported autotalent to vst, and mverb to ladspa)

- ccernn

[studio32]

Good job!

Maybe you're used to VST and have to get used to other formats? AFAIK devs are pretty positive about making LADSPA in general and also DSSI seems to be ok. LV2 is also ok, but theres eems to exists some hot debates about this, a lot of the confusing seems to be lack of knowledge most of the time though...

I suggest to contact the core devs (drobilla (?)) for it. Also the Linux DSP author has some good LV2 plugins working with Ardour and Qtractor.

Success!

[ccernn]

in case anybody is (still) interested:

the axonlib has been (more or less) put to rest, and our focus is now entirely
on the holos library.

we needed to do a complete rewrite, from scratch, to fix some initial
design flaws deep down at the core levels, to make it all more 64-bit safe,
better prepare for additional plugin formats (dssi/lv2) and platforms (mac?),
and because of a license change (you can no longer make proprietary (closed
source) plugins or apps with the library)..

lots of prototyping, testing and benchmarking have been done during the axonlib
development, and most of this is directly transfer-able to holos, but since i'm
doing all the platform and format specific code myself, and i'm absolutely not
an expert in these fields, it would be nice to have somebody looking over the
code, point out any possible flaws and problems, etc, as early as possible.

so...
anybody interested in having a look at it?

currently, most of the low level stuff is in place, and we can compile a
do-nothing vst, ladspa and exe/standalone versions, for both linux and win32.
(from the same, unmodified source code).. i'm now starting to add back the next
layers, the unified api and the gui.. from now on, things will be progressing
a lot faster!

but i'm always worried that there might be some things i've forgotten, or done
wrong, that will come back and bite me in the ass at some later point...

don't know what more to say, don't know what people might be interested in
hearing... so, i'll be happy to answer any questions.. or if you have any
comments, or whatever..

source code: http://code.google.com/p/holos/
blog: http://holoslib.blogspot.com/
discussions: http://groups.google.com/group/holoslib

and the previous axonlib is here:
http://code.google.com/p/axonlib/

- ccernn

[studio32]

You may get more feedback on the LAD mailinglist.

[StudioDave]

Unfortunately I've had no chance to work with your code. However, I encourage you to continue your effort, I think it's valuable and can certainly help expand the available selection of audio plugins for Linux.

Thanks for your work, I hope you're planning to continue it.

Best,

dp

[ccernn]

You may get more feedback on the LAD mailinglist.

i tried that earlier (for axonlib), but there were so much trouble with it, so i won't bother with that again... too bad..

- ccernn

[ccernn]

Unfortunately I've had no chance to work with your code. However, I encourage you to continue your effort, I think it's valuable and can certainly help expand the available selection of audio plugins for Linux.
Thanks for your work, I hope you're planning to continue it.
Best,
dp

thanx,
i will absolutely continue, since i do this for making plugins for my own personal use..
if it helps anybody else (code or plugins), even better!
and i will port as many plugins to linux as possible.
- ccernn

[autostatic]

I'm with Dave too. I think your library and your plugins are a valuable addition to the ones that are already available.

Best,

Jeremy

[ccernn]

yet another little (holos) update:

gui stuff is on its way back in..
mostly a copy/paste job from the older sources (axonlib),
with a few tweaks because of the modified class hierarchy, etc..
in addition to the already existing xlib and xrender stuff,
i added opengl (glx) support in there too.
(gdi/wgl for windows)
so it should be pretty flexible...

soon i will start my main objective, the (re-)making of some plugins..
i think the mverb port can be compiled to ladspa and gui-less vst already,
even if not all the features are in place...

- ccernn