Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[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

18 years, 9 months

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

18 years, 9 months

[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>

18 years, 9 months

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

18 years, 9 months

[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

18 years, 9 months

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

18 years, 9 months

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

18 years, 9 months

[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

18 years, 9 months

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

by Steve Harris

On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote: > 2007/1/22, Dmitry Baikov <dsbaikov(a)gmail.com>: >> On 1/23/07, Stefano D'Angelo <zanga.mail(a)gmail.com> wrote: >> > Good point! This is true, but there are lots of sound processing >> > plugins around, so maybe instead of creating a new API and then >> apply >> > some "compatibility layer", it should be better to create a >> wrapping >> > tool natively. I think it should be also easier to expand. >> >> Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA >> and anything you want. >> Or if you want something not possible with LV2, write an extension >> proposal. >> >> I think LV2 was designed as a very extendable API. >> If it is not, in your opinion, then help the guys to improve it. > > That could be a very wise solution, but there's one big problem with > it: when you load a LV2 plugin, you load only one plugin! > To be clearer I make an example: I have 10 VST plugin, and I want to > write a LV2 plugin which loads VST plugins. When the LV2-aware > application asks me which plugin I want to load I should specify the > VST plugin loader... but then? There's no way for my LV2 plugin to > determine which VST plugin it should load. This works fine, and was in the design brief for LV2. When asked what effects your LV2 plugin supports, you can return a list. > But also if this is an overcomeable problem, for each VST plugin I > load I have to waste memory space with a new instance of the LV2 VST > loader plugin. No you don't. A LV2 VST loader would be a single shared object, so the OS would only load one instance of it. > Then, it is quite absurde from the user point of view to open a plugin > which lets you open other plugins... it's just illogical! It doesn't look like that to the user, they will just see a list of plugins, some of which will be VST and some will not be. Have you tried the DSSI VST reflector? It would work the same as that. > Don't misunderstand me, LV2 is great, I think that it's the best > processing architecture out there, but it's designed with a 1:1 > relationship in mind (one plugin = one effect). That's absolutely not > an LV2 weakness, it just does its job and nothing else (as it should > be). You need to read the spec again. The terminology is confused, not least in the spec documents, but a single .lv2 "plugin" can host multiple effects with different ports and so on. - Steve

18 years, 9 months

[linux-audio-dev] interview with Rui Nuno Capela

by Dave Phillips

Greetings: I've placed online an interview with Rui Capela, the creator of QJackCtl, QSynth, QSampler, and QTractor. You can read it here: http://www.linuxjournal.com Enjoy! Best, dp

18 years, 9 months

Jump to page:

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