On Sunday, 18 June 2006, Stephen Cameron wrote:
> > Hi,
> >
> > I'm trying to figure out how to use the ALSA sequencer
> > with my app. Â (to date, I've been just using raw midi).
[..]
> But if I take out this line
>
> Â Â Â Â snd_seq_ev_set_dest(&ev, 128, 0);
>
> And replace it with:
>
> Â Â Â Â Â snd_seq_ev_set_dest(&ev, SND_SEQ_EVENT_PORT_SUBSCRIBED, 0);
>
> And try to use aconnect to connect things together, it doesn't
> seem to work.
>
> So, there's some piece of the puzzle regarding how aconnect
> works that I'm missing.
snd_seq_ev_set_subs(&ev);
I guess you may want to generate the ALSA library documentation from the
sources with doxygen. It is also available online:
http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html
Regards,
Pedro
Why do you say sndlib is "poorly maintained"? I did not get any
bug reports that I remember.
Also, it can be used with LADSPA, but I prefer a higher level approach.
Hi there.
Thanks to everyone who responded to the request about high level
languages for audio work.
I made a wikipage to order your input and my findings.
http://tinyurl.com/p4zqo
It definitely looks like Faust is the most serious contender for
writing LADSPA plugins. It seems to be actively maintained and well
documented. It claims to be able to generate different types of
plugins/applications from the same code. I'll print the tutorial and
read it over the weekend.
My first project will be a winner-takes-it-all-gain filter that takes
n number of inputs and lowers the gain on all but the loudest signal.
I want to use this on recordings of conversations where each speaker
has a separate microphone. First I tried sidechain ducking which
didn't really work for me. Then I tried expanding each channel, so as
to mute it when it fell under the threshold. That works pretty well
but it's not perfect. This winner-takes-it-all thingy should be dead
simple to implement and I expect it work pretty well.
alex
--
Alex Polite
http://flosspick.org - finding the right open source
"Alex Polite":
>Hi there.
>
>Thanks to everyone who responded to the request about high level
>languages for audio work.
>I made a wikipage to order your input and my findings.
>
>http://tinyurl.com/p4zqo
>
>It definitely looks like Faust is the most serious contender for
>writing LADSPA plugins. It seems to be actively maintained and well
>documented. It claims to be able to generate different types of
>plugins/applications from the same code. I'll print the tutorial and
>read it over the weekend.
>
I suggest that you rewrite the comment about snd. Writing "lispish, yuck"
doesn't give you much credit as someone worth listening to.
Also, for many other really good alternatives, like csound and
supercollider, you have just written "naa". I suggest that you do some
more research as well...
Steve Harris:
>Hum. It's maybe not tactfuly expressed, but the s-expression syntax has a
>number of objectors with informed positions.
>
>It is near one end of a broad spectrum of languages so inevitably not to
>everyones taste.
Sure. Syntax can be more compact without s-expressions, and the syntax can
also be more formed towards specific purposes without s-expressions as
well, like smalltalk that use {...} instead of (lambda ()...), and C that
use {...} instead of (begin ...), and things like accessing array values
or setting values requires more characters with s-expression since you
can't use special characters for common tasks. But the fact that you have
complete control over the language in a way that a non-lisper is probably
not able to understand without ever using lisp macros weights up for all
those things.
However, when people normally bash lisp, its probably because of the
following reason:
All the paranthesis looks ugly and are confusing.
For example, I actually spent almost two years programming lisp before I
started to like lisp very much. The paranthesis confusion dissapeared
quickly, but thinking lispish was harder. Before that, I thought python
was the most beautiful language of them all. (I knew about 20 programming
languages at that time.)
CLAM 0.91.0 Release Announcement
´Spectral transformations, annotator, packaging, and
desktop integration release'
We are glad to announce the 0.91.0 CLAM release which
comes by the hand with Music Annotator 0.3.2, Network
Editor 0.3.1 and SMSTools 0.4.1. They are available
for download as source tarballs and also as binary
packages for Windows, Ubuntu dapper, Debian sid and
Fedora Core 5. MacOsX binaries are not available for
this release, but we promise they will be back soon.
This release is the first official one which
incorporates the new CLAM Music Annotator featuring
chord extraction.
Almost 30 new spectral transformations have been
incorporated into the processing repository. Some of
them are already available from the NetworkEditor.
Application usage has received some extra stress on this
release. Applications are better integrated on Windows
and Linux desktops. Step by step application tutorials
are available on the clam wiki for Music Annotator [1],
SMSTools [2], Network Editor and Prototyper [3]. And,
all of them all provide examples to start with.
Please read these and other improvements in the
changelog [4] or visit our website [5] for further
details. We expect as much feedback as possible from
all our users. Besides the mailing list, you can likely
find us at #clam channel on FreeNode (IRC network).
The CLAM team
[1]
http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator_tutorial
[2] http://iua-share.upf.es/wikis/clam/index.php/SMSTools_tutorial
[3]
http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial
[4] http://clam.iua.upf.edu/ChangeLog.html
[5] http://clam.iua.upf.edu
Phil Frost:
> Subject: Re: [linux-audio-dev] Writing LADSPA plugins in high level
> language?
> To: The Linux Audio Developers' Mailing List
> <linux-audio-dev(a)music.columbia.edu>
> Message-ID: <20060614132522.GA3483(a)unununium.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote:
>> Hi there.
>>
>> Is it possible to write LADSPA plugins in anything but C/C++? I prefer
>> perl, ruby or python.
>>
>> alex
>
> Anything but C/C++, yes. See FAUST [1], a compiled language designed
> specificly for processing audio streams. Perl, Ruby, or Python, not
> really.
>
> [1] <http://faudiostream.sourceforge.net/>
The realtime extension for snd (scheme-like language) is another:
http://www.notam02.no/arkiv/doc/snd-rt/
Here is a cool alsa softsynth written in that system:
http://ccrma.stanford.edu/~kjetil/220c/
Hi,
Tonight I actually for once got around to working a bit on my pet
audio project, and thought I'd finally try to tackle my issues with a
processor-intensive audio loop. So I started writing a simple timing
class (C++) to do some profiling...
Unfortunately, instead I've found myself wasting my time because my
computer (or at least X) keeps freezing!
It seems that whenever I put a call to gettimeofday() in my audio loop
(which gets called about every 40-or-so milliseconds, a latency I'd
like to reduce), and run the program, everything just freezes... no
mouse, keyboard, no screen updates, etc. Reboot required.
(I tried using ssh from another computer but got no response...
strangely I did get a ping response however.)
To be more specific, the loop is actually a callback from PortAudio.
With gettimeofday commented out, there is no freeze, the software runs
as expected.
Originally I thought it might be a priority problem, but I tried
running it without a priority boost and using "nice -n 19", but still
I get a system freeze. It's strange, because I was under the
impression that a user process should never be able to hang my whole
system if not running as root.
Has anyone else had issues with this?
Is there a better way to profile my code?
Unfortunately it's a GUI program (using SDL for graphics) so it's
difficult to run it in text mode. I might try figuring out how to
comment out all the graphics stuff though, to see if it has the same
effect without X running.
I'm using Ubuntu Dapper, up-to-date:
$ uname -a
Linux hal9000 2.6.15-22-686 #1 SMP PREEMPT Sun May 7 16:37:57 UTC 2006
i686 GNU/Linux
Thanks,
Steve
Albert Graef:
> assembler for the low-level stuff. (Not sure about snd, does it compile
> to native code which can execute in realtime?)
Yes, the realtime extension that I wrote compiles a scheme-like language
into hard realtime-safe c code, which can be run and scheduled while snd
is running. Its not optimizing as much as faust, but mostly its not
significantly slower than hand-written C either. Sometimes it can even be
faster. Its a practical language to get real things done because it blends
into guile scheme and common lisp music so that everything is in the same
source and communicates with each other. Its possible to implement things
like ardour or supercollider in snd if anyone want to do that (although
they have to fix some of the many bugs first :-) ).
"David Cournapeau":
>>>
>>> On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote:
>>>> Hi there.
>>>>
>>>> Is it possible to write LADSPA plugins in anything but C/C++? I prefer
>>>> perl, ruby or python.
>>>>
>>>> alex
>>>
>>> Anything but C/C++, yes. See FAUST [1], a compiled language designed
>>> specificly for processing audio streams. Perl, Ruby, or Python, not
>>> really.
>>>
>>> [1] <http://faudiostream.sourceforge.net/>
>>
>>
>> The realtime extension for snd (scheme-like language) is another:
>> http://www.notam02.no/arkiv/doc/snd-rt/
>>
>> Here is a cool alsa softsynth written in that system:
>> http://ccrma.stanford.edu/~kjetil/220c/
> there is also chuck, that nobody has mentionned, I think :
>
> http://soundlab.cs.princeton.edu/research/chuck/
>
Not really. Chuck code runs in a VM and does not compile to native machine
code. It also process blocks of samples, while faust and snd process one
and one sample. In this respect, Chuck is more in the same class of
programs like Supercollider, nyquist, csound, pd and many many others.