>> >Service discovery just covers being able to locate liblo servers
>>
>> I wonder if it's possible to use portmap for service discovery?
>I dont know, but I think you shouldn't :)
Please say why. Thanks!
>Zeroconf seems like a good fit however.
Hydrogen 0.9.0 is out! :)
Features:
__General__
* Very user-friendly, modular, fast and intuitive graphical interface based
on QT 3.
* Sample-based stereo audio engine, with import of sound samples in .wav, .au
and .aiff formats.
* Support of samples in compressed FLAC file.
__Sequencer and mixer__
* Pattern-based sequencer, with unlimited number of patterns and ability to
chain patterns into a song.
* Up to 64 ticks per pattern with individual level per event and variable
pattern length.
* 32 instrument tracks with volume, mute, solo, pan capabilities.
* Multi layer support for instruments (up to 16 samples for each instrument).
* Ability to import/export song files.
* Unique human velocity, human time and swing functions.
* Multiple patterns playing at once.
__Other__
* OSS and Jack audio drivers, with assignable Jack ports.
* ALSA MIDI input with assignable midi-in channel (1..16, ALL).
* Import/export of drumkits.
* Export song to wav file.
* Export song to midi file.
Changes:
* Multi layer support for instruments (up to 16 samples).
* Multiple patterns playing at once.
* Added FLAC files support for songs and drumkits.
* Added pitch and gain properties per instrument.
* Improved song and pattern editor (selections, copy/move, etc..).
* Added a new selectable user interface (single panel).
* Better jack-transport support.
* Ability to set the note length in pattern editor
* Export song to standard midi file
Download:
 http://hydrogen.sourceforge.net
Happy drumming! :^)
--
Alessandro <Comix> Cominu
http://hydrogen.sf.net
e-mail: comix(a)despammed.com
Icq: 116354077
Linux User # 203765
[...Codito Ergo Sum...]
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.