20 Jun
2005
20 Jun
'05
12:26 a.m.
As I said many times It's not that I hate Linux
Audio, but mainly that I
mmh, i love it,
believe that it is too poor
in features/API for my taste. I tried very hard for several years to
make my apps play together
with jack/alsa, but I find myself very limited in many areas as a
programmer and user:
-Alsa/Jack integration in timestamping is poor, syncronizing audio to
midi is a pain
so use Jack MIDI
-I have no way to ask from a sequencer, the patch
names available in a
softsynth to list them
i do this all the time, grabbing lists of automatable params and patches from my
sequencer, using OSC aware apps like PD, Om etc as the LADSPA/DSSI hosts. sounds like a
sequencer limitation if it's not exposing these things programatticaly for you..
-Jack lack of midi
false..
-Jack lack of OSC or any way to do parameter
automation from the sequencer
im glad jack concentrates on audio and not "OSC parameter automation". its the
UNIX way, a utility doing one thing and doing it well, but if Jack could deliver
sample-accurate OSC messages in a more convenient manner than UDP, im all for it, but the
UI thing you speak of is a level above that.
-It is Impossible to do any sort of offline render, or
high quality
render of a song (like, in 32/192khz) using JACK/Alsa
so you want to be able to run the JACK samplerate at 'infinite' or at least a high
as possible until processing finishes. an interesting idea, to have offline render across
the entire chain.. but last i asked about even so much as multiple samplerates or
vari-speed scrub across all jack spps, they had reasons, not the least of which was it
would be useless without everyone supporting it..
-Saving/Restoring your project is just painfully hard.
LASH doesnt help,
and even when I came up with the idea of it in the first place.
this could be improved, but monolithic Cubase-esque hosts is not the way id prefer it to
be done. personally i just have my sequencer spawn off a few shell processes coupled with
rohan drape's excellent patching utils to handle app launches, while storing all the
params&patches id want to recall in the sequence database..
-Adding/Removing softsynths, linking connections, etc
takes a while
having to use qjackctl, etc
''
-Lack of send%.. I just cant have a jack client doing
a very high
quality reverb, only as wet processing and have clients send different
amounts of the signal to it, thus saving CPU
so you want jack to do mixing + connections, instead of just connections. take it up with
them, but variable wet/dry requires a 100% connection, so im not sure thats not a UI issue
a level above jack too..
-Lack of tempo-map based transport, I cant adapt my
midi-only sequencer
, which works in bars,
beats, etc to a frame-based transport. Say I want to run my sequencer,
then go thru softsynths
and record/edit in ardour.. no go.
confused here.. as to why it wouldnt work, other than your unwillingless to make a simple
function to cnovert between beats/bars to samples..
But overall, what mostly annoys me of linux audio is that most API
programmers just implement
the features THEY use and need, and not what others may need. And since
they mantain the thing,
is this not what the economics dictate? if someone sat down with major backing to
implement a 'grand vision' API, wouldnt we be talking about Apple?
even adding them yourself is pointless, as they will
most certainly not
accept patches. Ok, that's
not true, even my small trivial bugfix and usability patches have been incorporated into
various projects.. if youre talking about something enormous, maybe a branch is better at
least until its utility/superiority/whatever is proven..
fine, they are on their right to do it, after all
i'm not paying them to
do it, they work for themselves.
All this has simply led me to decide to not use such APIs anymore and
integrate everything I do
in big, and monolithic apps, such as reason, cubase, etc and not care
have fun, im personally glad to get away from that..
about the outside world anymore.
After all, it takes me less time to write the features I need for
myself, and into my own than dealing with people's religious software
views to get them integrated into other projects.
wish i could code that fast!
Cheers!
cheers,
carmen
Juan