sorry...
no 'reply' butttons (thunderbird) or any other link (list archives) i
tried has worked so far, so i give up.
i don't have the patience for these things...
at least i tried..
i just wanted to let you know that there's something new out there, that
some of you might find interesting, that's all...
if there's any questions, ask in our discussion group instead
(http://groups.google.com/group/axonlib), or email me directly...
or in the discussion thread over at kvr-audio
(http://www.kvraudio.com/forum/viewtopic.php?t=288888)
- ccernn
hello,
to clarify the current format capabilities of the library:
the library for now can be used to create:
- vst plugins for linux and windows (so / dll)
- standalone executables for linux and windows ('elf' exe/ 'pe' exe).
the standalone executables are not plugin host containers, but they can use
most of the library features such as gui widgets, drawing capabilities,
image decoding, file i/o etc. such executables can be useful for debugging a
plugin gui for example so that no host is needed to load into.
also the standalone executable can be created with no plugin ideas in mind
at all. an example for that would be a gui plotting program that can write
the resulted data from a buffer to the hard-drive.
standalone exacutables may eventually have some sound processing
cababilities, for example: reading a wavetable from disk and sending the
signal to the sound interface. also some primitive host capabilities for
plugins (i personally do not see much use for that).
on the plugin side there are a lot of possibilities and we are eventually
going to expand to more plugin formats like ladspa, other linux formats and
possibly au (while adding some osx platform code).
the general idea for the plugin formats is to have *unified plugin syntax
that can be compiled easily for different formats by simply switching a
compiler flag e.g. -DAX_FORMAT_VST / -DAX_FORMAT_LADSPA.
*or a least unified as much as possible ;)
of course any suggestions and comments are welcome and appreciated in the
same notion.
lubomir
i'm new to lists like this, and don't know how to reply to specific
posts in a discussion.. (teach me?)
some clarification is needed for axonlib (earlier post), i guess...
yes, axonlib is:
>> "standalone/vst-plugin library for linux/win32"
but the plan/idea is to expand the 'vst' part to other plugin formats
too, linux things like ladspa, dssi, (lv2), and a future mac port is
possible. support for the various plugin/binary formats of course
depends on the platform you compile for. there's no point in compiling a
lv2 for windows, for example... vst and standalone binary (exe) is
probably the most 'universal', since they exists for all three major
platforms..
and it's also good to be able to compile in one batch, (from a script)
to all supported formats and platforms, with no changes to the source
code...
and
>> " But the standalone part doesn't quite make sense"
some things can be nice to have available as a standalone binary on
linux, for example to use with jack.. ( but we're missing some parts for
standalones yet, audio and midi i/o being some of them :-/ haven't
decided on which lib/backend yet, possibly portaudio/midi )
and, it helps development a lot, when you can compile to an exe/binary
and run it from within an ide or something, and test various small
changes almost instantly, than needing to go through the often lengthy
process of starting up a host, and load the plugin there,
- ccernn
aarg, answering in the list is confusing!
thunderbird gives me just errors when trying to click on any "reply"
links in the emails or the list archives.
please, someone tell me how this is supposed to work...
---
I think it is a library for building audio processors - you write your
code to do whatever you want with audio and/or MIDI, and make GUI using
library functions. After that, with one parameter, you choose if you
want to compile it as a VST plugin or as a standalone app for Linux or
Windows.
Cheers!
Igor
---
yeah, that is more or less correct..
audio processor, plugin, diffferent names for kind of the same thing...
and if everything goes as planned, you can later compile to a dssi or
ladspa or whatever, if we manage to put the various (plugin-)format
abstractions in place. i've never done any code for these formats,
except for some ladspa testing, and doesn't use any audio-host that
support these plugin formats, ... so we might need some help with this
part, or it might take some time to get done (and bugfixed)..
same thing with the mac support...
everything has been abstracted into seperate layers for both the
plugin/processor format (standalone binary is considered as just one of
these formats), and platformst (currently windows/linux). there's a
bunch of #ifdef AX_FORMAT_VST and #ifdef AX_LINUX, etc, inside the code,
so you just have to define a couple of these for the format and platform
you want to compile to (probably in a makefile, or in a compile script),
and most things is 'automagically' handled for you...
you write your plugin (or whatever) with a specific set of
functions/methods from the base classses, and via some #ifdefs, etc, the
correct implementations for your platform/format of choice is being
'dragged in' and compiled into the resulting binary or shared library..
and sorry if my english isn't too perfect (i'm norwegian... if something
sounds confusing, just (continue to) ask..
- ccernn
[forwarding here, hope this is not too off topic or unwelcome]
==
Software Developer: Audio and Digital Music
Centre for Digital Music
Queen Mary, University of London
School of Electronic Engineering and Computer Science
The Centre for Digital Music (C4DM) at Queen Mary, University of
London, is seeking an experienced Software Developer with a background
and knowledge in Audio and Digital Music, to work on a new
EPSRC-funded project "Sustainable Software for Digital Music and
Audio Research". The aim of this project is to provide a Service to
support the development and use of software, data and metadata to
enable high quality research in the Audio and Digital Music research
community.
The postholder will undertake a range of software development
activities in this project, including: developing cross-platform
robust engineered software from research prototype software; tailoring
or adapting existing research software to make it usable by other
researchers; creating and maintaining software and data repositories;
providing documentation, training and advice on the use of developed
software; and engagement and outreach to the research community and
beyond.
The C4DM, part of the School of Electronic Engineering and Computer
Science, is a world-leading multidisciplinary research group in the
field of Digital Music & Audio Technology. C4DM already develops
robust software and technologies for music and audio research,
including Sonic Visualiser (SV), a popular open source cross-platform
framework for analysis of music and audio. Details about the School
can be found at www.eecs.qmul.ac.uk and about the Centre for Digital
Music at www.elec.qmul.ac.uk/digitalmusic
The post is full time and for 40 months (starting in July 2010 or as
soon as possible thereafter). Starting salary will be in the range
£27,913 - £33,659 per annum inclusive of London Allowance. Benefits
include 30 days annual leave, final salary pension scheme and
interest-free season ticket loan.
Candidates must be able to demonstrate their eligibility to work in
the UK in accordance with the Immigration, Asylum and Nationality Act
2006. Where required this may include entry clearance or continued
leave to remain under the Points Based Immigration Scheme.
Informal enquiries should be addressed to the Principal Investigator,
Prof Mark Plumbley at mark.plumbley(a)elec.qmul.ac.uk
Further details and an application form can be found at:
www.hr.qmul.ac.uk/vacancies
(http://webapps.qmul.ac.uk/hr/vacancies/jobs.php?id=1815)
To apply for the Software Developer position, please email the
following documents to Ms Julie Macdonald at
applications(a)eecs.qmul.ac.uk: Completed application form quoting
10212/CE; a CV listing any publications and a statement describing
your previous software development experience, outlining the relevance
to this project. Postal applications should be sent to Ms Julie
Macdonald, School of EECS, Queen Mary University of London, Mile End
Road, London, E1 4NS
The closing date for applications is 12 noon on 25 June 2010.
Interviews are expected to be held on 7 July 2010.
If you have not heard from us by 12 July 2010 then you should assume
that you have not been shortlisted on this occasion.
Valuing Diversity & Committed to Equality
Guys!
There has been some talk about Jack Session, but no big official
announcements. In fact, not even a clear concept.
I understand that it is all in very early development, but can someone
please clearly describe the concept, how it is planned to work, etc.
Louigi.
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.
"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..]
http://dl.dropbox.com/u/249632/axonlib/0.1.0/screenshot010.png
screenshot with:
- jost (linux) + axDemo/fx_grains
- reaper (win32, via wine) + axDemo/fx_grains
- standalone axDemo
test binaries:
-
http://dl.dropbox.com/u/249632/axonlib/0.1.0/bin/linux.tar.gz]linux.tar.gz
(686k)
- http://dl.dropbox.com/u/249632/axonlib/0.1.0/bin/win32.zip]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):
- http://sites.google.com/site/ccernnaudio/vst-plugins
we would appreciate:
- bug reports
- questions
- ideas
- comments
- contributions !
- discussions
- ...
subversion (latest sources): http://axonlib.googlecode.com/
svn snapshot (always a little outdated): axonlib-v0.1.0.zip (r379,
07.jun.2010)
- ccernn & neolit123
.....
Hi,
I have a young bright-eyed, bright-eared 12-year old composition student
working on a ASUS EEE-PC netbook. On my advice he switched over to Ubuntu
from Windows to do our work. I figured since I'm a veteran Linux user (since
1997!!!) I could help him if he had issues.
He's trying to compose some "musique concrete" style things right now using
Ardour, and of course, jack. Mostly it goes smoothly, but he does run into
crippling issues more frequently. Two things I want to mention:
1) Ardour works fine as it should 90% of the time, except on a netbook, the
windows fail to maximize correctly to available screen real estate (1024x600
I think), e.g., when you scroll down, you get the lowest ardour track
leaving video trails, and basically it looks like a huge GTK bug of some
sort---the interaction with the pointer of course becomes impossible. On my
EEE-PC Arch Linux system I can confirm the same behavior. I know 600 pixels
is not a lot to work with when you have all those tracks, but there
shouldn't be video freezes and trails of graphical widgets. Seems to me to
be a really obvious bug.
2) My student is reporting that at least on his Ubuntu machine, he's having
a problem getting sound consistently out of Ardour: sometimes, he says, the
mixer seems to randomly disconnect the tracks from the "Master Out" bus, and
sometimes he reports that jack misbehaves and that he cannot reconnect to
it. I'm going to try to get to the bottom of it, but I can report that I've
experienced similar things on rare occasions (Ardour 2.8.7, and jack 0.118.0
on Arch, maybe Ubuntu has other destructive aspects?), although I'm much
more able to hack around it, as a Linux beginner, and without my tech
support, unfortunately he's had to open Windows and finish his assignments
in Cakewalk. Which is of course MOST unfortunate for the cause of great
Linux audio software advocacy!
In talking to his Dad today, apparently, taking my advice and doing a 'sudo
killall jackd' and restarting jackd and ardour may have worked--I have to
confirm this w/Patrick. But this is not an ideal way of working......
Has anyone experienced similar things?
Best,
Aaron Krister Johnson
http://www.akjmusic.comhttp://www.untwelve.org
On Monday 07 June 2010 11:03:06 you wrote:
> Or it sees a jack running
> when
>
> > it starts and asks if you want to connect to it or not.
>
> and for what purpose? qjackctl sole function is being attached to a
> running jack server. why do you want to make it an option ?
Because perhaps you want it to start up another jack server rather than
connecting to this one?
Can someone from the jack side speak to the future possibility of determining
all running jack servers?
if we settle on a naming scheme could this be done via a simple ps -ax?
(Not ignoring the hairiness spoken of later in your post.)
all the best,
drew
On Monday 07 June 2010 08:59:09 you wrote:
> On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts <zotz(a)100jamz.com> wrote:
> >>>> JACK_DEFAULT_SERVER environment variable might be your (only) friend
> >>>> here :)
>
> <snip>
>
> > Hold on a second. Let me try walking through this.
> >
> > We start qjackctl. Does it connect to a jack server at this point? If
>
> so,
>
> > always or only if jack is currently running.
>
> it connects only if jackd is currently running.
That's what I thought.
>
> > In cases where it might connect on startup, must it?
>
> no. again it only connects automatically iif a (default) server is found
> responsive to open qjackctl as one of its clients.
Right, but does it *have* to do this? Is there no way to make this behavior a
config option? Or a query on start option?
Config file is set to not attach on startup and so it doesn't. Config file is
set to attach on startup and so it does. Or it sees a jack running when it
starts and asks if you want to connect to it or not.
>
> > Let's say no jack is running and we start qjackctl.
> > Let's say it doesn't connect to jack at this point.
>
> i does not.
>
> > Could there not be a setup option to indicate what -n indicated now?
>
> qjackctl -n command line option is just convenient for you to start jackd
> server with that precise server name and let qjackctl connect immediately
> to it as client to that same server.
>
> > Let's say multiple jacks are running and we start qjackctl.
> > Is it possible to discover that multiple jacks are running?
>
> nope. qjackctl will only "see" the default jack server or the one named by
> JACK_DEFAULT_SERVER environment variable at the time qjackctl is launched.
Sure. it will only see it as things stand now, but is it impossible for it to
see the others? If so, where does this impossibility arise?
>
> > If so, would it be possible to allow a choice from within the gui as to
> > which one to connect to?
>
> none atm. each qjackctl instance may only attach to one server at a time.
I think we may be having language issues here. I am not asking here how things
stand atm. Rather could qjackctl be modified to start, see multiple jacks
running and list them and ask which you want to connect to and control?
Thanks for your time and responses.
>
>
> cheers
all the best,
drew
