Linux-audio-dev January 2007

linux-audio-dev@lists.linuxaudio.org

68 participants
48 discussions

[linux-audio-dev] an relevant link about Vista

by Dave Phillips

Greetings: This link may have been posted here before now, but it bears repetition : http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt Nasty stuff planned in Redmond. Best, dp

19 years

Re: [linux-audio-dev] JACK data transfers

by danni

On a side note there is a discussion on the freebob list of whether to add a control api to Jack or just for freebob. On Thursday 25 January 2007 04:40, linux-audio-dev-request(a)music.columbia.edu wrote: > On 24 Jan 2007, at 16:02, Stefano D'Angelo wrote: > > Well... I know I'm quite a boring person, but I need some informations > > for my project and so I'm going to stress you a bit ;-) > > I'm wondering if JACK is suitable to transfer non-audio data beetween > > applications (my particular case is to transfer control data to > > processing plugins). Is that "naturally" possible, is it an hack or is > > it impossible at all? > > You could encode control data in the audio stream, or build a bespoke > JACK that add additional data types, or you could use the nascent > JACK-MIDI stuff. > > You could also look at OSC, which, depending on your syncronisation > needs could be a better fit. > > > And another thing (I'm too lazy to check it out myself :-P): does jack > > transfers data by copying or uses something like shared memory or > > whatever? > > It uses shared memory where possible. > > - Steve -- When it comes to broken marriages most husbands will split the blame -- half his wife's fault, and half her mother's.

19 years

[linux-audio-dev] Sound processing objects architecture, is it possible?

by Stefano D'Angelo

Hi all, I'm quite new to sound-related programming, but however I have an idea which could interest some of you, but I don't know if it's possible to develop such thing. What I'd like to work on is a sound processing architecture (LADSPA, VST, DSSI, etc.) wrapper, which hides the details of a particular implementation to audio program developers. The whole thing could be made of a library to be used directly by audio developers in their programs, one or more configuration files used to retrieve directories in which plugins are placed and other stuff, and modules which contain implementation details for each processing architecture. The library could also contain some code to "trap" particular kinds of functions (for example Xlib functions to embed plugin GUIs inside programs). I think that the advantage of all of these stuff is to enable programs to use any kind of processing object (they could not only be loadable modules, but also text files or whatever), to collect "information" on how to implement a certain processing object type just in one place, and, last but not least, to ease creation of new standards and comparison of existing ones. What do you think about it? Sincerely, Stefano D'Angelo

19 years

[linux-audio-dev] a new patent for us to challenge

by Paul Davis

http://www.freshpatents.com/Low-latency-real-time-audio-streaming-dt2006040… in which Microsoft patents designs partially implemented by OSS 10 years ago and fully implemented by ALSA 5 years ago. Wrapping this up in windows API nonsense obscures the basic fact this design is not innovative in any way unless compared only to existing Windows audio driver architectures.

19 years

[OT] Zionism and LAD (was: Re: [linux-audio-dev] an relevant link about Vista)

by Bob Ham

MUST.. RESIST URGE.. TO CLICK SEND... DAMN! -- Bob Ham <rah(a)bash.sh>

19 years

[linux-audio-dev] Re: Sound processing objects architecture, is it possible?

by Kjetil S. Matheussen

Paul Davis: > > On Wed, 2007-01-24 at 16:06 +0100, Jay Vaughan wrote: >> At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: >>> What I'd like to work on is a sound processing architecture (LADSPA, >>> VST, DSSI, etc.) wrapper, which hides the details of a particular >>> implementation to audio program developers. >> >> Nice idea. Already done: >> >> http://teragon.org/products/PluginCore/ >> >>> What do you think about it? >> >> Would be nice if there were a GPL effort in the same way .. > > ARDOUR::Plugin ? > > which currently wraps VST, LADSPA and will soon do either LV2 or > DSSI ... > > yeah, ok, so its partly in jest, but not entirely. > Another one is the "Juce Audio Plugin Framework", which wraps VSTs, RTAS and AudioUnits. http://www.rawmaterialsoftware.com/juce/download.php It doesn't support ladspa though, but Julian said that he should look at LV2. (He also said that he hadn't heard of LV2 before, so maybe he hasn't heard about ladspa either. :-) So if someone request ladspa, he might do that as well...)

19 years

[linux-audio-dev] JACK data transfers

by Stefano D'Angelo

Well... I know I'm quite a boring person, but I need some informations for my project and so I'm going to stress you a bit ;-) I'm wondering if JACK is suitable to transfer non-audio data beetween applications (my particular case is to transfer control data to processing plugins). Is that "naturally" possible, is it an hack or is it impossible at all? And another thing (I'm too lazy to check it out myself :-P): does jack transfers data by copying or uses something like shared memory or whatever? Thanks is advance. Stefano D'Angelo

19 years

Re: [linux-audio-dev] Sound processing objects architecture, is it possible?

by Stefano D'Angelo

2007/1/24, Jay Vaughan <jayv(a)synth.net>: > At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: > >What I'd like to work on is a sound processing architecture (LADSPA, > >VST, DSSI, etc.) wrapper, which hides the details of a particular > >implementation to audio program developers. > > Nice idea. Already done: > > http://teragon.org/products/PluginCore/ > > >What do you think about it? > > Would be nice if there were a GPL effort in the same way .. > > -- > > ; > > Jay Vaughan > > Well, it seems like LV2 can do (at least theorically) all of these already, altough some things might be a bit tricky (read the rest of the conversation). Now I'm seeking whether this approach (LV2 bridges plugins) can present practical problems and, in such case, I think it's better to solve them in LV2 than restart from scratch. To be true, there are two things I'm concerned about: one (less relevant, maybe) is RDF files... a bridge plugin should generate them for all installed plugins when it is loaded, and so it has to contain (or link to) code that can handle such syntax (I really don't understand why LV2 developers choose such language instead of XML, which is much more known and supported). The other one is more serious (but should have been also faced by vstserver, fst and dssi-vst): I'm talking about logical compatibility beetween LV2 and other standards (VST in this case) in handling some tasks (settings and session storing, banks/effects/programs metaphor, etc.). Does anyone know about these matters? Then I think that it would be nice if some GUI programs could take advantage of trapping Xlib (or whatever) functions (LD_PRELOAD?) in order to embed plugin GUIs inside the app and/or have a library that autogenerates GUIs for non GUI-plugins (well... the XML GUI specification for LADSPA has been dropped in LV2 in favour of extensions?). ... it's such a complex matter :-P Regards, Stefano

19 years

[linux-audio-dev] ScoreChaser -- a new music notation editor

by Michelle Donalies

I recently began work on a new music notation editor called ScoreChaser. A prototype release can be found at sourceforge.net/projects/scorechaser. Its intent is to be a program in the vein of Rosegarden (and indeed, it borrows quite heavily from RG, at least in these early versions), but with groupable tracks, tablature support, and (eventually) multiple simultaneous time signatures. It's currently just an initial release with very limited functionality, but it does demonstrate the groupable tracks and the beginnings of tablature support.

19 years

[linux-audio-dev] Sample Rate Converter Comparison

by Erik de Castro Lopo

Hi all, SecretRabbitCode was recently included in a test of a number of commercially available sample rate converters and while it wasn't the best, it certainly didn't disgrace itself either. The results are here: http://src.infinitewave.ca/ This test gives me yet more incentive to continue my work on coming up with a new improved algorithm. Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I'd rather not work with people who aren't careful. It's darwinism in software development." -- Linus Torvalds on the linux-kernel list

19 years

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 January 2007