Linux-audio-dev May 2009

linux-audio-dev@lists.linuxaudio.org

61 participants
47 discussions

by Sebastian Moors

Hi, i would like to know if somebody has already thought about a (unified) way to save or export the settings of ladspa plugins (or vst,lv2..) I'm familiar with the idea of LASH, but i want to share plugin settings between different sessions. A typical use case: After recording songs with my drumset, the gate-plugin applied to basedrum and snare has most times (nearly) the same setting. At the moment this is a quite painful task: Ardour is able to save the settings, but you can't export these or exchange them between other applications. In addition, ardour's ladspa plugin dialog can just save the settings, changing an already saved settings is not possible. This results in a heap of saved settings and old revisions.. It would be great to export these settings, it could be implemented as a feature in applications like ardour2 ,jackrack or hydrogen. After exporting the setting to a plain text file (or xml), sharing the file with other people or between your computer would be no problem. What are your thoughts on this? What are the disadvantages? Thanks, Sebastian

16 years, 3 months

[LAD] supporting a dedicated DSP chip with ALSA

by Ziv Haziz

Hi All, i'm seeking an advise on the preferred way to support a dedicated DSP chip under ALSA. The system is an embedded system constructed on a dual core chip - one core is ARM vanlia and the other is a dedicated DSP core. The DSP core is capable of both playing both encoded streams (mp3, wma, various voice coders) and of course PCM streams. the codec (a2d, d2a) are connected to DSP. I looking for an elegant design to hide the DSP under the ALSA sysem and I have several ideas and would like to get your advise: 1. use LADSPA to make the DSP look as a plug-in for both control and data - what I don't know is if LADSPA forces me to return data to the ALSA for sending it to the kernel drivers 2. use the LADSPA to make the DSP control only and make another kernel driver for the audio data pass - is it possible? There can be a sync problem between the commands and the time the data will arrive? Will this support JACKD ? I'm open to other suggestions as well, Thanks in advance Ziv ______________________________________________________________________ DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System. _____________________________________________________________________

16 years, 7 months

[LAD] Could not deliver the message in the time limit specified.

by Ralf Mardorf

Hi :) sorry, I'm a fan of Qtractor, but it's still on a state were bugs urgently should be reported and wishes might have more effect than for similar, but established applications. I send 3 mails to rncbc(a)rncbc.org, but I got 'Could not deliver the message in the time limit specified.' I also wasn't able to surf http://www.rncbc.org/, the strange thing is, that I don't get an error message. I know that he's subscribed to Jack-dev and LAD. Is anybody able to connect to http://www.rncbc.org/? Some time ago there was a similar problem with his domain. I fear I can imagine what the problem is :(. Best, Ralf PS: Now I got "The server at www.rncbc.org is taking too long to respond."

16 years, 7 months

[LAD] [ANN] invada-studio-plugins-lv2-1.0.0

by Fraser

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Everyone, I'm pleased to announce the initial 'LV2' release of the Invada Studio Plugins which feature plugin GUI's along with a new 'Stereo Phaser' plugin. The plugins have been tested on Arch 2009.02, Ubuntu Hardy and Ubuntu Jaunty (amd64) using Ardour 2.8 & Lars Luthman's Elven but if you come across something that doesn't look right (or is plain broken) please log it as a bug via the Invada Studio Launchpad page: https://launchpad.net/invada-studio More information & source download can be found here: http://www.invadarecords.com/Downloads.php?ID=00000264 For those running Ubuntu or derivatives, packages for Hardy, Jaunty, Intrepid & Karmic exist in the Invada PPA: https://launchpad.net/~invada/+archive/ppa Any Feedback / comments welcome. Enjoy! Fraser. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKIO/1NZroiEh4erwRArYFAJwO6dYaLr2m3vHPji/DYQA5muvE/gCfYfYj S30U9TNMJPG5CJ4dJZ80c6A= =/Om7 -----END PGP SIGNATURE-----

16 years, 7 months

[LAD] Connie, an organ template for JACK

by linuxaudio

Hi, this is my first post to LAD. The discussion about a hammond simulation "Fons could you make us...", Beatrix and some research for writing a (german) wikipedia article (stub) about the Vox Continental inspired me to hack a quick organ program that simulates the internal signal flow of the "Connie" with JACK MIDI input and JACK audio output. Have fun: http://cryptomys.de/horo/Connie/Connie-0.1.tar.gz Ciao Martin Homuth-Rosemann

16 years, 7 months

[LAD] FST and JUCE-based plugins

by Julien Pommier

Hi, I have noticed that all JUCE-based vst plugins do not work in fst (at least their GUI and their internal message passing stuff). The reason is that the JUCE framework is initialising its internal machinery (a MessageManager etc) during the first call to the VST entrypoint, and if the later call to effEditOpen is performed from a different thread, then all sort of terrible things happens, and it ends with a deadlock. There is a discussion in the JUCE forum here: http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?p=21530#21530 Please note that I'm not asking for a fix, but I just want to let the FST developers know about this problem ! Julien

16 years, 8 months

[LAD] Location of header files...

by Ulrich Lorenz Schlüter

On my system the location of some headers changed. For example /usr/include/lash/lash.h changed to /usr/include/lash-1.0/lash/lash.h. Are the headers in the wrong place or is there a link missing or do I have to change my #includes? Thanks and regards Uli

16 years, 8 months

[LAD] New proposal for the jackd/jackdbus mess

by Stéphane Letz

Hi all, New much simplified proposal, should be "Fons compatible", hopefully "Nedko compatible" (with little work), "Paul one package only compatible", others "keep it simple compatible"... The first "big" conceptual change compared to the current SVN state is this new "control IPC" scheme. That is the so called control API can be used on client side also. The other conceptual change is that "jackd" process is supposed to be an "always running" daemon that defines an IPC entry point to be used from "clients". This daemon does not "automatically" starts the server (as it does now), but will when requested (either by the "jackd" code directly using C API ) or by the request of external control font-end using IPC. 1) Server side: - libjackserver.so contains: server code + C control API + "new" IPC control API (server side) + C Jack API + IPC Jack API (server side) - jackd executable is linked with libjackserver.so (nothing new here) - backends (ALSA, dummy...) are linked with libjackserver.so (nothing new here) - a "standalone" client (that wants to embed the server in it's process) is linked with libjackserver.so and directly uses the C control API to control/start the server and C Jack API to be a client (nothing new here). 2) Client side: - libjack.so contains : "new" IPC control API (client side) + IPC Jack API (client side) - clients are linked to libjack.so (nothing new here) - new control front-end (jackdbus, jackOSC...) are linked to libjack.so: they control the server using the IPC control API (client side), they can be regular clients using IPC Jack API (client side) to deal with connections management and so on... - a "default" centralized state for the server is always kept in ~/ jackdrc. When a client wants to auto-start, this "default" state is used. (this is important to keep in mind) - libjack may have to start the "jackd" executable using the fork+exec way, or the "jackd" process is an "always running + relaunch" process (this has to be more defined later on...) - Qjakctl stays as a regular client, it can still start the "jackd" process as usual. It can keep its own way of keeping multiple configurations as it does now. - more sophisticated control front-end (jackdbus, jackOSC...) are now regular clients. They can use the IPC control API (client side) for more sophisticated control of the server. As regular clients, they access the API to control connections... and so on. The important thing is that those clients are *obliged* to deal with this "default" centralized state. Even if they deal with multiple configs in a new format (XML...) they are supposed to always put a "default" state in ~/jackdrc for the client "auto-start" feature to continue working. - Ardour can still do it's server control mess on its own... ((-: 3) General: - a single jack2 package is needed. It contains the "jackd" daemon/ server are before. - "jackdbus" is now conceptually separated from the Jack source code. It only uses jack.h + control.h and is linked to libjack.so as any regular client. It can be distributed separately as a more sophisticated control front-end available, or be available in the jack2 package. - old fashion users can keep their habits - new "D-Bus aware" guys can explore new fields... This scheme seems to hopefully solve most of the problems we had, and requires only a bit of change for the "jackdbus" front-end to continue working, but not much. Comments? Stephane

16 years, 8 months

[LAD] Presenting volume control sliders

by Lennart Poettering

Heya! I am currently working on the volume control handling of PulseAudio. Until now the sliders in the UI mapped their position linearly to the dB volume scale. i.e. if the slider is at '0%' we get -90dB, if it is at '100%' we get 0dB, and between that we map linearly from those percentages to the dB value. To be frank, this sucked big time because the 'interesting' part is usually way up at -10dB to 0dB. and the remaining part of the volume sliders is pretty boring. >From reading through the ALSA drivers I know that a lot of sound card mixer controls usually have a much higher dB resolution near 0dB then the have near -90dB. Most of the time the steps they choose are very arbitrary however. So, I was looking for better suggestions for mapping 'pixel distances' in the UI to volume factors. I googled a bit and found this: http://www.robotplanet.dk/audio/audio_gui_design/ Which suggests a cubic relation between 'pixel distances' and the linear factor. Any opinions on that? Other suggestions? Thanks, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

16 years, 8 months

[LAD] A picture...of the global mess

by Stéphane Letz

He all, A picture to try summary what I understand about we would like : - a new shared library called "libjackontrol.so" : is does implement the so called control API and a IPC mechanism to use it. - "jackcontrol" is an *always" running deamon that defined an entry IPC point. jackcontrol get requests from control applications. "jackcontrol" can start a seprated server called "jackserver (using a fork+exec) way. "jackcontrol" is a *unique* place where setting are handled. - "jackd" is a recoded control application that parse it's command line, and use the control IPC to speak to "jackcontrol" (then just quits). jackcontrol then start the "jackserver" whith the appropriate paramaters. - "jackddbus" is a D-Bus aware control application; It receive DBus requests and translate them to control IPC to speak to "jackcontrol". jackcontrol then start the "jackserver" whith the appropriate paramaters - "libjack.so" speaks also to "jackcontrol" using the control IPC: an client that auto-start actually use this mecanism Does it helps? Stephane

16 years, 8 months

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 May 2009