Greetings:
The subject says it all.
My own "Linux audio sucks" hobbyhorse:
No way to recall a complex configuration of apps and plugins with
all settings intact. If I use a complicated setup with multiple synths
and plugins I have no way to recall these applications to their previous
settings. LASH/LADCCA was supposed to address this situation but I don't
know where that project stands at this point.
And your favorite is... ?
Best,
dp
Hi, I started last year the project of an small framework for audio apps
based on JACK and LADSPA. I published it quite a while ago on :
http://lamarmite.poivron.org
But I'm now really doubting of the interest of this project and this
should be THE place to find answers ...
--*/--*/--*/--*/ Here is a short intro
La Marmite is a C++ framework cooked for the development of audio
applications for GNU/Linux which is based on the will of simplifying the
combined use of the standard tools JACK and LADSPA. La Marmite is free
software and published under the GNU Public License.
JACK and LADSPA are two major ingredients from the Linux audio world but
mixing them together often bury me in long hours of C coding which
rapidly oxidize my placid humour...
My idea was to construct a object-oriented environment providing a
higher level of abstraction and which allows me to concentrate on the
logic of the application and to achieve my goal faster without having
neither to bury myself in the inmost depths of the interfaces nor to
recode over and over the same routines.
Do you feel like ?
La Marmite was designed in order to create same applications, audio
toys, or autonomous audio modules which be further mixed or combined
through JACK. But only few things have been realised so far. And it
might not be well suited for larger scale applications.
Hi all,
I am quite flabbergasted by this particular problem as it never was a
problem before. Therefore, I would greatly appreciate any help I can get in
this matter.
I've installed Ubuntu Hoary and then installed realtime-lsm module from the
Hoary deb repository. The realtime-lsm definitely works without a problem
and has been thoroughly tested.
If I install any audio jackd-capable app from Ubuntu Hoary deb repository,
it works just fine with jackd (which was also installed from the repository)
both real-time and non-realtime, except for the Supercollider. Jackd uses in
/tmp folder which has been mounted as tmpfs to improve performance.
I tried installing Supercollider from source and it exhibits the same
behavior as the .deb.
I did install Alsa 1.0.9 as 1.0.8 that ships with Ubuntu has some bugs in
respect to hdsp driver (although Ubuntu may have patched these, haven't
bothered to check).
When trying to connect to non-rt jackd, Supercollider works, but when
connecting to real-time enabled jackd it connects and immediately gets
disconnected reporting error that it has been "zombified" by jackd.
I tried even enabling realtime-lsm for all apps and that did not help.
Starting jackd in softmode does not help.
Now, I know that it worked just fine on Mandrake with realtime-lsm module so
I have no idea why jackd is being so picky.
Considering all the problems, I tried installing jackd from source (Hoary
has 0.99.0, so I downloaded the same) and now here is where the rub starts.
Once I install the same version jackd from source, no app from Hoary's .deb
repository works any more with it, including qjackctl. Error reported is
"could not tie an input port" or something along those lines. So, the only
thing I can do is then install all the audio apps from source to make them
work with the jackd. So here are my questions which I would greatly
appreciate your help in answering:
1. Why is this happening when both the .deb and source versions of jackd are
the same?
2. So what can I do at this point and why some apps (pd sometimes also gets
zombified) get so easily kicked from jackd while others don't?
3. Is there anything I can do to retain compatibility with the jackd-enabled
apps from .deb repository when compiling newer version of jack from the
source?
4. What actual version of jackd is Ubuntu using? How is it altered?
5. What can I do to make jackd tolerate initial start-up delays (ironically
this has not been the problem in the past with supercollider, so at this
point I am not sure whether it is a problem with supercollider, jackd, or
Ubuntu)?
6. Should recompiling kernel with low-lat and realtime patches (i.e. ck)
help solve some of these problems?
7. Any other advice that may help solve these problems would be most
appreciated!
Sorry for cross-posting, I am hoping that Ubuntu devs/users may be able to
answer some of these.
Many thanks!
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
Hello altogether,
the German language Linux-Magazin is going to produce
an issue on audio. Therefore we are looking for
someone who is willing and able to write on LADSPA
and/or DSSI, possibly focusing on just one of both
technologies. If you are interested please contact me.
Thanks
Oliver
--
Linux New Media AG
Süskindstraße 4
D-81929 München
Tel: +49 (89) 99 34 11 42
Fax: +49 (89) 99 34 11 99
Andrew Morton and others want to change the default value of HZ to ~250
for kernel 2.6.13, "to save power on laptops".
I think this is absolutely insane, I should not even have to explain
why.
If you feel the same way, *please* complain about it on LKML. The
thread is called "-mm -> 2.6.13 merge status".
They at least need to merge the high-res timers patch at the same time,
so that users will not see a regression in the sleep() resolution from
1ms to 3ms.
Lee
Hi all,
I posted some questions a while back about signals that could potentially
damage PA speakers, or equipment after amplification. I'm starting to look
at using a genetic programming synthesiser I'm writing for live
performance:
http://www.pawfal.org/index.php?page=WigWamJam
This synthesiser can create arbitary functions for rendering samples,
these functions are then randomly mutated and guided by the user by
aesthetic choice. As you can imagine, during this process rather nasty
sounds can be generated (this may not prove to be a useable system for
live use without people getting annoyed and throwing things at me, but,
erm, bear with me here :)
Other than user driven selection based on the audible results, some
automatic removal of functions is going to have to happen. From people's
feedback on LAD these would include rendered sounds that have the
following features:
* high dc offset
* very low frequency
* very high frequency
I'd like to avoid filtering the sounds as a post process ideally, but I
guess some enveloping would be needed to prevent sudden jumps in dc at the
beginning and end of the samples. I'd also automatically remove functions
that result in silent samples.
Any thoughts?
cheers,
dave
www.pawfal.org/nebogeo
Hi!
There has been some discussion lately involving keywords such as
"amateuer" and "professional".
An "amateur" works for the love of it (as in 'amore'.)
A "professional" works to earn his/her daily bread (as in
'proffezione'.)
Those two concepts are not mutuallally exclusive per se. It is not
unsual though, for "pros" to get fed up with their chosen line and still
do their thing for the love of money, or lack of alternatives.
Whatever ..
We also have touched the words 'consumer' as well as 'producer'.
Playing an mp3 (or ogg?) is a typical consumer behaviour. Creating an
mp3 (or ogg) from scratch as in you, recording your grandma singing
"Happy Billday", is a production.
So?!
When we say 'pro', it would make much more sense if we could agree on
that this means "produzione" rather than "profezionale".
Mvh // Jens M Andreasen
(My appologies to Benno for the mindless ad hoc Italian/Latin lingo.)
--
On Mon, 2005-06-20 at 15:48 +0200, Alfons Adriaensen wrote:
> [Tim Orford]
>
> > although "pros" have some valuable knowledge, one of the funny
> > things about them (and i am guilty of this) is that they all
> > think other pros are like them, which is not remotely true.
> > There are big differences between pros in different professions,
> > and even within the same discipline. The differences are not
> > overcomable, and i think you would be better off trying to analyse
> > and accomodate the differences rather than underplaying their
> > existance.
>
>
> Wise Words (but I suspect you wanted to write 'not *un*overcomable')
>
>
"Insurmountable" would be even better.
Jan