Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7529 discussions

[linux-audio-dev] Writing a winner takes it all gain filter.

by 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. 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

19 years, 6 months

Re: [linux-audio-dev] Writing a winner takes it all gain filter.

by Kjetil S. Matheussen

"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...

19 years, 6 months

Re: [linux-audio-dev] Writing a winner takes it all gain filter.

by Kjetil S. Matheussen

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.)

19 years, 6 months

[linux-audio-dev] [iua-mtg] CLAM 0.91.0

by Pau Arumi

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

19 years, 6 months

[linux-audio-dev] Re: Writing LADSPA plugins in high level language?

by Kjetil S. Matheussen

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/

19 years, 6 months

[linux-audio-dev] gettimeofday() freeze?

by Steve

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

19 years, 6 months

Re: [linux-audio-dev] Writing LADSPA plugins in high level language

by Kjetil S. Matheussen

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 :-) ).

19 years, 6 months

[linux-audio-dev] Re: Writing LADSPA plugins in high level language?

by Kjetil S. Matheussen

"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.

19 years, 6 months

[linux-audio-dev] Mx44.1 ... The Sequel

by Jens M Andreasen

Mx44 got itself an update and will now understand some of the most important standard GS midi controllers. Also included is a fix for compiling with gcc 4. The homepage has moved to: http://members.chello.se/luna/ Mx44 is a multichannel polyphonic synthesizer, loosely based on FM-synthesis, with a Klingon approach to oscillators ... Implemented GS controllers -------------------------- R ## Ctrl 73 Attack (modifies the time value of all env stage 1 and 2) 75 Decay (modifies the time value of all env stage 3 and 4) 79 Loop (modifies the time value of all env stage 5 and 6) 72 Release (you get the drill ...) 05 Portamento (routed to intonation, being the closest match) 94 Celeste (modifies amount of frequency offset) * 07 Channel Volume (yep!) 10 Pan (rotates the sound-image) * 01 Modulation (modulation send amount from op with "Wheel" btn ON) * 70 Timbre (modulation send amount from op with "Wheel" btn OFF) * 71 Variation (balance between modulation from op 1+3/op 2+4) * 74 Cutoff Freq (resonance ctrl for oscillators connected to envelope) Controllers marked with asterix operates in true RT mode (ie: on a sustained note.) The rest is set up at note-on -- mvh // Jens M Andreasen

19 years, 6 months

[linux-audio-dev] Re: Writing LADSPA plugins in high level language?

by lazzaro

[feel free to redistribute this posting to other mailing lists] On Jun 15, 2006, at 6:56 AM, Paul Winkler wrote: > And, is all the sfront / saol action happening somewhere > that I'm not aware of? I was always disappointed that there > didn't seem to be a lively community around saol. No, the MIT mailing list went inactive a few years ago, and to my knowledge a new one hasn't sprung up to replace it. The only communication channel at the moment is the mailing list to be notified of new sfront releases via freshmeat.net: http://freshmeat.net/projects/sfront/ Which does have 10 subscribers, and I'm not one of them, so there must be 11 sfront users left in the world (at least) :-). I've actually spent the last few months going through my queue of bug reports and feature requests, and updating the code base. But, these are the sorts of changes that benefit from doing them in "batch mode" and then testing thoroughly, so the plan is to hold off on a new release until its time for me to switch back into teaching mode for the fall ... Historically, a few things happened with sfront: [1] The standardization of RTP MIDI via the IETF took priority, and it took longer than I had thought (first running code happened Christmas 2000, and the IESG approved the I-Ds a few months ago: http://www1.ietf.org/mail-archive/web/ietf-announce/current/ msg02110.html We're now in the copy-editing queue (it takes a long time to proof-read 250 pages of dense text ...), once this is done we'll get our RFC numbers. [2] It took a long time to really get a sense of where SAOL could fit in the community ... I think pitching it as a Max/MSP or Pd or SuperCollider or CSound competitor won't succeed ... instead, I think it needs to be relaunched as "audio Postscript" -- an ISO/IEC standard for normatively interchanging audio algorithms in a domain-specific representation. And, as a extra bonus, SAOL is easier for human programmers to read/write than Postscript :-). This is an old idea -- some of you may remember an editorial David Wessel wrote about "audio Postscript" many years ago in Electronic Musician magazine ... Admittedly, SAOL is not perfect for this role -- being standardized almost a decade ago, its inevitable that its dated in some respects, and even during its birth some of its design decisions were controversial. But, I don't think that a core group of academic and industrial folks would be willing to mount (another) 5 year effort to standardize a better audio algorithm interchange language, unless they see real evidence from the community that there's a need for such an effort. And the best way to show that need is to try to insert SAOL into markets for such an interchange format where SAOL's limitations are not of great concern. >> Sfront compiles a high-level music language (Structured Audio) to C, >> and there's no reason in theory that audio drivers couldn't be >> written >> for LADSPA. > > I remember asking you about this a couple years ago and you said > it could be done, but you could only run one plugin instance > at a time... .is that still the case? or am I misremembering? You are remembering correctly ... Basically, one of the "feature requests" in my queue is improving the sfront audio driver API to remove this restriction, and to reality-test it by writing an AudioUnits driver. Until that happens, yes, you'd be limited to single-instantiation for your LADSPA driver ... realistically, I don't think "multiple instances" would make it into the "late summer 2006" release, unless I get lucky and finish earlier items in the queue ahead of schedule. The priority items are fixing real semantic bugs in the language implementation, since sfront is serving as a de-facto secondary reference implementation at this point, as saolc has trouble running a lot of correct SAOL code ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

19 years, 6 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev