Hi all,
the Aqualung project (http://aqualung.sf.net) opened a mailing list
for development as well as user discussion. I would kindly invite
everyone interested to join the list. I would also like to thank LA
list members for their patience.
Our list is called aqualung-friends. To subscribe, go to:
https://lists.sourceforge.net/lists/listinfo/aqualung-friends
The list is members-only. After subscribing, post messages to:
aqualung-friends(a)lists.sourceforge.net
We are planning to keep the list relatively low-traffic (no cvs diffs,
no daily releases), but we would like to have a separate place for
discussion so as not to flood the general LA lists with our own
troublesome issues.
We now also have a Mantis bugtracker available at:
http://aqualung.sf.net/mantis
I encourage everyone to add bugs, feature requests or whatever.
Thanks for all your support,
Tom
>From: Jens M Andreasen <jens.andreasen(a)chello.se>
>>
>> http://www.tomshardware.com/hardnews/20040902_135943.html
>
>As of lately, GPUs have turned into very flexible massive
>vectorprocessors. Precision is 32bit floats (but you can trade it down
>to get more work done)
Yes, it could be that the "invention" implements the algorithms
trivially in GPU -- like anyone would implement when getting started
in to GPU programming.
It is like Nokia mobile connected to the wall power outlet.
The Nokia mobile does not take power directly from the wall because
that "invention" is patented. Nokia mobile is forced to take
power from the battery (which could be next to dead). All this
even devices have taken power directly from the wall for decades.
GPU is yet another new gear to play with, just like mobiles.
Anything can be patented, I'm afraid.
>PS: You need not worry about patents for performing an algorithm on a
>processor. Especially not when the vendor supplies you with a C-like
>languge for doing exactly that.
The article says quite clearly that the invention is patented.
They would be fools not to try to patent it because the market
is huge.
>Neat idea, been meaning to try it since the OpenGL2 shader compilers
>were released.
I have had years this idea of using graphics texture functions to
generate audio noises and signals. This app runs naturally on GPU.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Hi All,
I'm trying to develop a custom wav player app using libao - I need to
keep the audio latency as small as possible in this project. I was
wondering if anybody has done any tests to see how latent libao is for
this, or whether I should just throw in the towel now, and move to
jack/libalsa?
Also I was wondering whether reading each sample at a time from a file
is likely to be dropping the real-time ness, or whether people have
found that this isn't really such a limiting factor.
At the moment it seems quite slow, but then I am developing in vmware-
so I guess that adds quite alot of latency!?
Tom
Hi all,
Ok, so I'm playing with osc (currently doing gui->app communication with it)
but all my individual apps still talk midi between them. This is quite
cumbersome, as I want to start having lots of controls that midi doesn't
support - and I don't really "think" in midi these days anyway.
Is there a case now to ditch midi support and go with osc for everything? I
see midi messages are a type within osc anyway - is it fairly straight forward
to be backwards compatible this way?
cheers,
dave
>I have two Audio related projects that need updating.
>Both have existing /dev/dsp style backends at present, which have been working
>fine. But recently (SuSE 9.0 install?) when run under ALSA emulation of
>/dev/dsp they both started producing segfaults - "after program had exited",
>(neither valgrind nor gdb can give any info on the fault).
>So I decided it was time to do a native ALSA backend(s).
>I have rsynth backend working, and perl Audio:: one almost working.
>But before going forward I would like to solicit opinions on what
>is the "right" API to use.
>(please tell me if I missed any):
Portaudio, which gives you macos and windows for free (but of course
you must also port the gui stuff...)
>2. ALSA
>3. JACK
Do the callbacks once and it's trivial to port to all three of the above
in my experience.
Hi everybody,
After the holiday season, and late for the 1st anniversary, here comes
another dot release for QjackCtl, the Qt GUI for the JACK Audio Connection
Kit:
Qjackctl 0.2.10 is out, with some minor enhancements and fixes.
>From the change log:
- New pre-shutdown script setup option, allowing to specify a shell-script
to be run before the JACK server daemon is shutted-down. This overrides
any previous shutdown script setting, which should be now moved onto the
existing post-shutdown script option, as to keep old procedural behaviour.
- Avoid stopping JACK prematurely with QProcess::kill() (oneliner fix);
stopping JACK will now take a little bit longer, but hopefully will take
the time to cleanup properly (thanks to Kjetil Matheussen).
- ALSA driver Duplex mode accepts alternate Input or Output device name.
- Context menu reset option is now always enabled (yet another suggestion
from Sampo Savolainen).
- Main display background gets shinny effect; adjusted system tray
background palette color mode.
- Priority and setup control is now a spinbox ranging from 0..89 (as
suggested by Florian Schmidt). Same for Periods/Buffer.
- Patchbay connection lines are now drawn correctly when items are
scrolled out of view. Additionally, the connection lines can now be
optionally drawn as bezier spline curves (big thanks to Wilfried Huss).
Just head to the homepage:
http://qjackctl.sourceforge.net
or, in case that's not up-to-date yet, to sourceforge's project page:
http://sourceforge.net/projects/qjackctl
Hope you enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
hi...
i just wanted to announce this bugfix release of galan-0.3.0
this one was a real show-stopper with complex signal routings.
get it at http://www.sf.net/projects/galan
for those who dont know:
gAlan is a powerful modular synth and effects engine, which allows the
user to build a custom UI for a synth mesh he has created.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Greetings:
I wrote to Joerg Anders, the author of NoteEdit, and he confirmed that
he is leaving off development of NoteEdit. Though I disagree with his
assessment of a possible Linux Finale, it's certainly his right to stay
with or go away from the helm of NoteEdit development, and he can use
any reason he prefers.
I have *no* confirmation regarding any Linux development at all from
Coda Music, the manufacturers of Finale. Unless someone knows more, I'd
say it's an unfounded rumor. I've read that some users have run Finale
under Wine: I can get it to open but it doesn't work after that.
There's some discussion whether to keep it in AGNULA and whether
AGNULA members might want to take over the development of NE. I realize
that NE has some possibly irritating dependencies, but I must add that
it is a unique Linux music notation editor with a well-evolved set of
features and an active user base.
I'm uneasy about the implications that mere rumor compelled Joerg to
abandon NE, though as I said, I respect Joerg's wishes and his
accomplishments with regard to NE. I'm confused as to why Finale's
presence might force a developer to consider his own work a closed case.
After all, Finale is expensive, closed-source, and not necessarily
suited to everyone's work methods. NE is free software, open-source, and
works nicely for me. I would hate to see it disappear.
Joerg said that since sources are available anyone can continue with
NE development. I hope that happens.
Best regards,
dp
Hi All,
I am pleased to announce that I finally have an alpha release of a louderbox
that is (hopefully) reasonably fit to show its face in daylight....
What I have is an 8 band compressor/limiter/clipper/pre em thing written as a
jack client. It borrows very heavily from jamin but as fits its intended use
butchers far more of the dynamics then would be acceptable in a mastering
processor.
Excuse the autotools mess, I am still trying to get by head around the horrid
things. I Think the dependency list is correct, but do not depend on it.
The default startup config needs a lot of work and not all the GUI controls
are connected to the DSP core yet.
You can see the screenshots (which for some reason seem to matter more then
what it sounds like to some people!) and get the code here:
http://www.spamblock.demon.co.uk
Ps: Sorry Fred, I decided in the end to go with GTK and OSC for remote
control. Writing a RML to OSC bridge should be almost trivial however.
Like JAMIN (from which it borrows lots of code) this makes heavy use of LADSPA
plugins to do most of the real work.
Comments, Flames, Patches?
Regards, Dan.
--
** The email address *IS* valid, do NOT remove the spamblock
And on the evening of the first day the lord said...........
.... LX 1, GO!; and there was light.