Re: [linux-audio-dev] plug:jack device channel-count
On Fri, Aug 25, 2006 at 11:35:32AM +1000, Erik de Castro Lopo wrote: Lee Revell wrote: Does Sweep really have no JACK support? Unfortunately that is correct. Its high on the TODO list but none of the current developers have the time to tackle it. Sweep does have a nice driver output layer but I suspect that its mainly geared towards push outputs like OSS/ALSA etc and as I understand it, JACk uses pull instead of push. Is that correct? yeah, that's right :) the driver layer will need a bit of rearchitecture, as sweep can handle simultaneous input and multiple outputs (ie. for scrubbing on live input, with both headphone and live outputs). Could be fun :) Conrad.
Re: [linux-audio-dev] LADSPA2 name early consensus?
On Thu, Apr 27, 2006 at 10:02:20AM +0100, Steve Harris wrote: Discusson seems to have slowwed down a bit, so I went through the list archive and pulled out all the names: apa chap clap eep fap ladspa2 pea peep peeper rap sax wasap xap xaprappeep Conrad.
[linux-audio-dev] liboggz 0.9.5 Release
Oggz 0.9.5 Release -- Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-scan and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format. This release is available as a source tarball at: http://www.annodex.net/software/liboggz/download/liboggz-0.9.5.tar.gz New in this release: * Fixed and updated Windows (Visual Studio) support - added missing exported symbols, projects for oggz tools. (Alex Krumm-Heller, Silvia Pfeiffer) * Support for OggPCM (Draft 2, Main header) OggPCM is an experimental specification for storing uncompressed PCM audio in Ogg bitstreams. - liboggz: Recognition of OggPCM timestamps, and support for seeking in files that contain OggPCM logical bitstreams. - oggzinfo: Display OggPCM header details - oggzdump, oggzrip: New [--content-type pcm, -c pcm] option to filter on OggPCM - oggz-validate: Validate framing of OggPCM logical bitstreams This version is installed on http://validator.annodex.org/ for online validation of OggPCM files. For more information about OggPCM, see: http://wiki.xiph.org/index.php/OggPCM * ./configure support for large (2GB) files This version adds build configuration support for large files, allowing liboggz to operate on files 2GB. This version does not introduce any API changes; interfaces such as oggz_tell() continue to use off_t externally. However, sequential reading and validation of large files is now possible. * bug fixes and cleanups: - oggz-validate, oggzmerge, oggzdump, oggz-scan, oggzinfo: handle unknown content types (Ian Malone) - remove deprecated oggzed example - various code and documentation build cleanups About Oggz -- Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-scan and oggz-validate. liboggz supports the flexibility afforded by the Ogg file format while presenting the following API niceties: * Full API documentation * Comprehensive test suite of read, write and seeking behavior. The entire test suite can be run under valgrind if available. * Developed and tested on GNU/Linux, Darwin/MacOSX, Win32 and Symbian OS. May work on other Unix-like systems via GNU autoconf. For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files and Visual C++ 6.0 workspace files are provided in the source distribution. * Strict adherence to the formatting requirements of Ogg bitstreams, to ensure that only valid bitstreams are generated; writes can fail if you try to write illegally structured packets. * A simple, callback based open/read/close or open/write/close interface to raw Ogg files. * Writing automatically interleaves with packet queuing, and provides callback based notification when this queue is empty * A customisable seeking abstraction for seeking on multitrack Ogg data. Seeking works easily and reliably on multitrack and multi-codec streams, and can transparently parse Theora, Speex, Vorbis, FLAC, CMML and Ogg Skeleton headers without requiring linking to those libraries. This allows efficient use on servers and other devices that need to parse and seek within Ogg files, but do not need to do a full media decode. Full documentation of the liboggz API, customization and installation, and mux and demux examples can be read online at: http://www.annodex.net/software/liboggz/html/ Tools - The Oggz source tarball also contains the following command-line tools, which are useful for debugging and testing Ogg bitstreams: * oggzinfo: Display information about one or more Ogg files and their bitstreams. * oggzdump: Hexdump packets of an Ogg file, or revert an Ogg file from such a hexdump. * oggzdiff: Hexdump the packets of two Ogg files and output differences. * oggzmerge: Merge Ogg files together, interleaving pages in order of presentation time. * oggzrip: Extract one or more logical bitstreams from an Ogg file. * oggz-scan: Scan an Ogg file and output characteristic landmarks. * oggz-validate: Validate the Ogg framing of one or more files. License --- Oggz is Free Software, available under a BSD style license. More information is available online at the Oggz homepage: http://www.annodex.net/software/liboggz/ enjoy :) -- Conrad Parker Senior Software Engineer, Continuous Media Web, CSIRO
[linux-audio-dev] looking for maube ...
Hi, I'm trying to find a copy of a program called maube: http://www.vergenet.net/~conrad/maube/ It's from 1997, and I'm hoping that maybe someone who's been around here for a while might have a copy ... I can't find a copy of the source on any of my (working) machines, or via google. I wasn't happy to discover that the HTTP download link is a broken symlink to a filesystem on my old university account (ie. when I copied the website across to vergenet a few years ago, I copied the symlink not the directory it pointed to...). Anyway, if you happen to have a hard drive with nine years worth of linux audio cruft on it, please 'locate maube' for me :-) I'm interested to see if it builds or runs at all any more. And then we're gonna build a new Linux desktop to rival Gnome and KDE, but based on the Self Organising Interface Attenuator [ok, kidding, I can't even remember what that was]: http://www.vergenet.net/~conrad/maube/screenshots.html cheers, Conrad.
Re: [linux-audio-dev] looking for maube ...
On Thu, Feb 09, 2006 at 10:59:16PM +, peter wrote: On Fri, 2006-02-10 at 08:10 +1100, Conrad Parker wrote: Hi, I'm trying to find a copy of a program called maube: http://www.vergenet.net/~conrad/maube/ It's from 1997, and I'm hoping that maybe someone who's been around here for a while might have a copy ... http://www.zenadsl6252.zen.co.uk/maube-0.10.4.tgz Oh wow, thanks peter! Add one to the number of beers I owe you. The tarball is back on the site at http://www.vergenet.net/~conrad/maube/dl/ It builds! it runs! it crashes! kfish.
[linux-audio-dev] beatfish (codedump :)
Hi, a few years ago I made a drum machine with scrubbing, and showed it to some people at the LAD booth at LinuxTag 2003. Recently (at linux.conf.au 2006) I realized I've sat on the code and not released it. This is not a release, but a challenge; here's some code, and some instructions for building it: http://trac.metadecks.org/wiki/BeatfishInstall Beatfish is built on libremix (which is also not-quite-released; I'd like to freeze the API sometime this year though ;-) and Evas (a very high performance graphics canvas built for Enlightenment 17). The plan is to make a way of developing cute music machines, using DSSI and all that's good. For now, beatfish is a pretty basic Jack toy. enjoy :) Conrad.
Re: [linux-audio-dev] convenient ogg vorbis wrapper
On Sat, Sep 17, 2005 at 08:49:27AM +1000, Erik de Castro Lopo wrote: Richard Spindler wrote: Hi, I'm looking for a convenient wrapper library for ogg vorbis, because what I've found on the xiph.org pages looks a little overengineered to me. I've used libsndfile most of the time, so this is the API Style that I'd prefer, basically I need 4 functions I believe: Conrad Parker has been working on adding Ogg Vorbis and Speex support to libsndfile. Its been very close to working for some time now :-). aye, if you'd like to play with it, it's in an arch repository at: http://www.metadecks.org/arch/ The library dependencies etc. were described in this email (which references Erik's libsndfile--hack branch): http://music.columbia.edu/pipermail/linux-audio-dev/2005-July/013288.html cheers, Conrad.
Re: [linux-audio-dev] please help: enumerating library requirements
On Sat, Jul 23, 2005 at 08:29:30AM +1000, Erik de Castro Lopo wrote: If you are willing to go for a pre-release: http://www.mega-nerd.com/tmp/libsndfile-1.0.12pre10.tar.gz ... Ogg Vorbis (as well as Ogg Speex) is being worked on and is pretty close to working (Conrad). Hi, Here's an update about Ogg support in libsndfile. This was posted to libsndfile-devel a few days ago. - Support for Ogg Vorbis and Speex formats in libsndfile has not yet been released. This is mostly my fault :-) I provided an initial implementation sometime last year, but it does not yet pass all libsndfile's required feature tests. It does, however, fairly usefully decode, seek and encode both Ogg Vorbis and Speex files. It may be useful for some of you to experiment with, and help with further development and testing would be very much appreciated. In order to do so, you will need to build the --hack branch of libsndfile from Eriks' arch repository. To retrieve this using tla: tla register-archive http://www.mega-nerd.com/Arch/2004/ tla get [EMAIL PROTECTED]/libsndfile--hack--0 Ogg support requires liboggz and libfishsound: http://www.annodex.net/software/liboggz/ http://www.annodex.net/software/libfishsound/ The release tarballs of each of these are fine. I recommend liboggz = 0.9.1 (0.9.1 was released April 8 2005, 0.9.2 last week), and libfishsound == 0.7.0. libfishsound prior to 0.7.0 did not contain some API calls that libsndfile's Ogg support is using, so we previously recommended checking out libfishsound from svn.annodex.net. This is no longer necessary -- the release tarball is fine. In fact current releases are no longer coming from trunk, but maintained in http://svn.annodex.net/libfishsound/branches/1.0-stable/ Once you get that all built and installed, your favourite libsndfile apps should happily support Ogg Vorbis and Speex files (as well as the audio tracks of Ogg Theora files :). However, libsndfile's 'make check' test suite currently doesn't pass, so feel free to investigate why ;-) The secret codename for libfishsound 0.7.0 is the Happy Lucky Libsndfile Release. Enjoy :) Conrad.
[linux-audio-dev] Oggz 0.9.1 Release
and oggz-validate. liboggz supports the flexibility afforded by the Ogg file format while presenting the following API niceties: * Full API documentation * Comprehensive test suite of read, write and seeking behavior. The entire test suite can be run under valgrind if available. * Developed and tested on GNU/Linux, Darwin/MacOSX, Win32 and Symbian OS. May work on other Unix-like systems via GNU autoconf. For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files and Visual C++ 6.0 workspace files are provided in the source distribution. * Strict adherence to the formatting requirements of Ogg bitstreams, to ensure that only valid bitstreams are generated; writes can fail if you try to write illegally structured packets. * A simple, callback based open/read/close or open/write/close interface to raw Ogg files. * Writing automatically interleaves with packet queuing, and provides callback based notification when this queue is empty * A customisable seeking abstraction for seeking on multitrack Ogg data. Seeking works easily and reliably on multitrack and multi-codec streams, and can transparently parse Theora, Speex, Vorbis, FLAC, CMML and Ogg Skeleton headers without requiring linking to those libraries. This allows efficient use on servers and other devices that need to parse and seek within Ogg files, but do not need to do a full media decode. Full documentation of the liboggz API, customization and installation, and mux and demux examples can be read online at: http://www.annodex.net/software/liboggz/html/ Tools - The Oggz source tarball also contains the following command-line tools, which are useful for debugging and testing Ogg bitstreams: * oggzinfo: Display information about one or more Ogg files and their bitstreams. * oggzdump: Hexdump packets of an Ogg file, or revert an Ogg file from such a hexdump. * oggzdiff: Hexdump the packets of two Ogg files and output differences Oggz is Free Software, available under a BSD-style license. * oggzmerge: Merge Ogg files together, interleaving pages in order of presentation time. * oggzrip: Extract one or more logical bitstreams from an Ogg file. * oggz-validate: Validate the Ogg framing of one or more files. License --- Oggz is Free Software, available under a BSD style license. More information is available online at the Oggz homepage: http://www.annodex.net/software/liboggz/ enjoy :) -- Conrad Parker Senior Software Engineer, Continuous Media Web, CSIRO Australia http://www.annodex.net/ http://www.ict.csiro.au/cmweb/
[linux-audio-dev] linux.conf.au Audio Miniconf
This is a reminder, as the closing date for submissions is soon. Please do not confuse this event with the Linux Audio Conference (LAC) in Karlsruhe, Germany, which is on during the same week. There may or may not be video streaming or teleportation between the two. There are kangaroos in Australia. CALL FOR PARTICIPATION Linux Audio Miniconf at linux.conf.au (LCA2005) April 2005, Canberra, Australia http://www.metadecks.org/events/lca2005/ This mini-conference is part of linux.conf.au (LCA2005), Australia's national Linux conference. Participants of this mini-conference must register for LCA2005; the conference web site is http://linux.conf.au/ The Audio Miniconf comprises technical sessions during the day, and an opportunity for jamming and musical demonstrations in the evening at a local pub. This call for participation is for the technical sessions. Suggested topic areas include: * Linux for Digital Audio Workstations and musical instruments * low latency and reliable audio in the Linux kernel and userspace * systems for connecting music, processing and control hardware * core Linux audio subsystems: Jack, ALSA, LADSPA, etc. * software synthesis and sequencing applications * recording, editing and mastering applications * audio file formats and codecs * streaming and network services for audio * telephony and speech technologies * usability of music and audio applications Presentations must relate to Free and Open Source software and/or open standards. The suggested duration of sessions is 60 minutes; this may be varied according to the needs of each topic. If you would like to present a technical session, please mail a brief abstract (100-300 words) to [EMAIL PROTECTED] by February 20 2005. This mini-conference is being arranged by Conrad Parker (Sweep project) and Erik de Castro Lopo (libsndfile, Secret Rabbit Code), with venue and other logistics provided by the organisers of LCA2005. Conrad.
[linux-audio-dev] libfishsound-0.6.3
FishSound 0.6.3 Release --- libfishsound provides a simple programming interface for decoding and encoding audio data using Xiph.Org codecs (Vorbis and Speex). This release is available as a source tarball at: http://www.annodex.net/software/libfishsound/download/libfishsound-0.6.3.tar.gz This release fixes a bug in encoding to Speex format from a non-interleaved stereo PCM source, and closes a memory leak in the comments API. Additionally, the test suite has been expanded to cover all possible instances of encoding and decoding, and symmetrical trials of encode-decode pipelines have been introduced. The test suite and example programs have also undergone rigorous testing of memory management and correctness of generated audio. About libfishsound -- libfishsound by itself is designed to handle raw codec streams from a lower level layer such as UDP datagrams. When these codecs are used in files, they are commonly encapsulated in Ogg to produce Ogg Vorbis and Speex files. libfishsound is a wrapper around the existing codec libraries and provides a consistent, higher-level programming interface. It has been designed for use in a wide variety of applications; it has no direct dependencies on Annodex or Ogg encapsulation, though it is most commonly used in conjunction with liboggz to decode or encode Ogg encapsulated Vorbis or Speex files. FishSound has been developed and tested on GNU/Linux, Darwin/MacOSX and Win32. It probably also works on other Unix-like systems via GNU autoconf. For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files and Visual C++ 6.0 workspace files are all provided in the source distribution. Full documentation of the FishSound API, customization and installation, and complete examples of Ogg Vorbis and Speex decoding and encoding are provided in the source tarball, and can be read online at: http://www.annodex.net/software/libfishsound/html/ FishSound is Free Software, available under a BSD-style license. More information is available online at the FishSound homepage: http://www.annodex.net/software/libfishsound/ enjoy :) -- Conrad Parker Senior Software Engineer, Continuous Media Web, CSIRO Australia http://www.annodex.net/ http://www.ict.csiro.au/cmweb/
[linux-audio-dev] libfishsound-0.6.1
FishSound 0.6.1 Release
---
libfishsound provides a simple programming interface for decoding and
encoding audio data using Xiph.Org codecs (Vorbis and Speex).
This release is available as a source tarball at:
http://www.annodex.net/software/libfishsound/download/libfishsound-0.6.1.tar.gz
New in this release:
* Fixed bug in decoding stereo Speex to non-interleaved
* Added fish_sound_{get,set}_frameno() functions
* Added API for reading and writing Vorbiscomment style metadata
* Added test suite for comment read/write integrity
* Added comprehensive testing of encode/decode pipeline
libfishsound by itself is designed to handle raw codec streams from a
lower level layer such as UDP datagrams. When these codecs are used in
files, they are commonly encapsulated in Ogg to produce Ogg Vorbis
and Speex files.
libfishsound is a wrapper around the existing codec libraries and provides
a consistent, higher-level programming interface. It has been designed for
use in a wide variety of applications; it has no direct dependencies on
Annodex or Ogg encapsulation, though it is most commonly used in conjunction
with liboggz to decode or encode Ogg encapsulated Vorbis or Speex files.
FishSound has been developed and tested on GNU/Linux, Darwin/MacOSX and
Win32. It probably also works on other Unix-like systems via GNU autoconf.
For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files and
Visual C++ 6.0 workspace files are all provided in the source distribution.
Full documentation of the FishSound API, customization and installation,
and complete examples of Ogg Vorbis and Speex decoding and encoding are
provided in the source tarball, and can be read online at:
http://www.annodex.net/software/libfishsound/html/
FishSound is Free Software, available under a BSD-style license.
More information is available online at the FishSound homepage:
http://www.annodex.net/software/libfishsound/
enjoy :)
--
Conrad Parker
Senior Software Engineer, Continuous Media Web, CSIRO Australia
http://www.annodex.net/ http://www.ict.csiro.au/cmweb/
Re: [linux-audio-dev] libfishsound-0.6.1
On Thu, May 06, 2004 at 12:17:04AM +0200, Albert Graef wrote: What Conrad neglected to mention was that he is currently working on adding libfishsound and liboggz to libsndfile so that all this meaty goodness will be available to libsndfile users in the very near future. That's just great. We're using libsndfile all the time, and the prospect that it'll soon be able to read and write ogg files makes me want to hug someone. :) How long until we can get our hands on this? no promises on the release schedule, but I can tell you that the code is already working ;-) It still needs a test suite before release, which is actually turning out to be quite a lot of fun in itself. I'm targetting libsndfile-1.0.11, currently waiting to sync to Erik's arch repo ;) Conrad.
[linux-audio-dev] Linux Audio Miniconf, April 2005, Canberra Australia
Hi, for those who can't get enough Linux Audio in their diet: The Linux Audio Mini-Conf @ LCA2005 will be held before linux.conf.au, Australia's national Linux conference, in April 2005 at the Australian National University in Canberra, Australia. More details, including the call for technical presentations and an archive of the previous year's miniconf, is at: http://www.metadecks.org/events/lca2005/ Conrad.
Re: [linux-audio-dev] Can software authors make allowances for packagers?
On Sun, Apr 18, 2004 at 08:11:08PM +1000, Luke Yelavich wrote: If a package's configure script doesn't recognize CFLAGS, it is a bug. Report it as such. The configure scripts do recognise CFLAGS, however the custom CFLAGS either replace CFLAGS necessary for the package, or the package uses the same flags with different parameters, eg -march and -mcpu flags. packages using automake should only set AM_CFLAGS, AM_INCLUDES, AM_LDFLAGS etc. in Makefile.am. Resetting CFLAGS, INCLUDES, LDFLAGS etc. is a bug (which I've also been guiltly of many times :) so please report this to the authors, it's trivial to fix and usually affects packaging, cross-compiling, and other strange environments ... Conrad.
Re: [linux-audio-dev] Pitchshift/Timestretch project..
On Tue, Apr 06, 2004 at 08:38:09AM +1000, Erik de Castro Lopo wrote: On Tue, 6 Apr 2004 00:07:08 +0200 Christian Schoenebeck [EMAIL PROTECTED] wrote: Es geschah am Montag, 5. April 2004 23:33 als Erik de Castro Lopo schrieb: Well me. I've been working on this since the start of the year, but been thinking about the problem for over 10 years. Which brings me to the question: how old are you? :P Well according to my birth certificate, I was born in 1962, but I really don't feel like I'm 41 years old :-). well isn't that because you also spent about 10 years playing bass in a rock band? K.
Re: [linux-audio-dev] [newbie] mixing audio streams
On Sat, Mar 13, 2004 at 05:13:11PM +0100, Alex Marandon wrote: Hello, I'm a trying to make a piece of code to mix 2 WAV files and hear the output on my headphones. I've spent hours trying differents things with Is there any framework wich does such a task well ? I had a look at SndObj which seems to do such things but it's also quite old and not maintained against today configurations. try remix -- http://remix.sf.net/ Conrad.
Re: [linux-audio-dev] Cross platform mixer API?
On Fri, Feb 27, 2004 at 10:04:40PM +1100, Erik de Castro Lopo wrote: On Fri, 27 Feb 2004 12:09:34 +1300 Eliot Blennerhassett [EMAIL PROTECTED] wrote: Greetings, I am aware of PortMixer, which is a simple API that abstracts volume controls. Is anyone aware of any other crossplatform, cross-API mixer abstraction layers out there? Conrad Parker's libremix maybe? http://www.metadecks.org/software/remix/ Conrad is the author of Sweep, but has been extremely poor at publicing remix. [ACK: I need to pimp my recent stuff more] I think Eliot's after a hardware mixer abstraction, ie. something to abstract away the hardware gain controls etc. Remix is an application library for multitrack/multchannel pcm sequencing in software; I don't think it's what Eliot's after. Conrad.
[linux-audio-dev] Linux.Conf.Au Audio Mini-Conf
Hi, just a reminder that the Linux Audio mini-conf at Linux.Conf.Au is happening on Monday Jan 12 2004 in beautiful Adelaide, South Australia. Details are at: http://www.metadecks.org/events/lca2004/ if you can be there and would like to do a presentation, please submit an abstract soon, places are filling very fast and we'd like to get the programme sorted out this month :) other than that, it should be a lot of fun, as will the main conference on the following Wed-Sat: http://lca2004.linux.org.au/programme.cgi cheers, Conrad.
Re: [linux-audio-dev] While we're talking about lack of responses :-)
On Wed, Feb 12, 2003 at 10:40:53AM +, Dave Griffiths wrote: http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/ I think as linux developers, we could find something similar very handy - especially if it was toolkit agnostic. Has anyone heard of something like this? both KDE and Gnome have similar documents; they've recently agreed to combine efforts and come up with some common guidelines at freedesktop.org. (copy of the news at http://dot.kde.org/1044312611/) currently they're still separate documents, but of course there's a lot of overlap: http://developer.gnome.org/projects/gup/hig/ http://developer.kde.org/documentation/design/ui/resources.html Conrad.
Re: [linux-audio-dev] (OT) C++ flame war
On Wed, Feb 05, 2003 at 01:23:41PM -0500, David O'Toole wrote: Ok, I'll stop now, this is off-topic :-) for an on-topic rant, see Erik de Castro Lopo's interview on mstation.org: http://mstation.org/erikdecl.php where he discusses the OO design of libsndfile and libsamplerate (surely two of the most rock-solid audio libraries ever!) and be sure to scroll down to the second half of the interview, about test suites, for some really juicy useful hacking advice ... Conrad.
Re: [linux-audio-dev] Plugin APIs (again)
On Tue, Dec 03, 2002 at 01:58:29PM -0800, Tim Hockin wrote: From: Steve Harris [EMAIL PROTECTED] If you're going to support metadata, support the Dublin Core, but generally extrnal metadata is better than internal. Just provide a unique ID and metadata can refer to that. Firstly, I hate the idea that a plugin writer needs to procure a unique ID. Secondly, I think some meta-data needs to be IN the plugin. Now, maybe 'notes', and 'url' can be outside the plugin, but author/copyright/license/version can't. Think of commercial plugin (I know, pipe dreams, but just pretend :). As a commercial vendor you DO NOT want it to be trivial for a person to 'lose' the info about the license. I can think of a several reasons to keep it all together, and no good reason NOT to. Specifically, this data is inseperable from the plugin. As an author, I want this data joined at the hip with the plugin. Further, the idea that a plugin consists of a single .so file appeals to me. I have to say I agree with Tim here -- internal, inseparable strings are much simpler for both the host and plugin authors to deal with, and don't force apps to link against random external libraries (xml or rdf or whatever) just to get at a few necessary strings. The core stuff (name, description etc.) is not actually meta at all, they're fields which just happen to be of string type. If a host needs to parse xml, or even hit the network, just to access core information, that significantly raises the barrier to entry for developing compatible software. The barrier to entry is already high enough (the ability to write or load dynamic libraries and design a callback based plugin) -- high enough that I've seen a few people shy away from it already. Adding to this will only slow the uptake, or put us in a situation where all our half-developed apps can only do half of what's required of the standard, which will be awful. For stuff that is actually metadata (keywords, location of publication etc.) ... if you want to reference external metadata by unique id, I propose that the data type of the unique id be a URL :) Conrad.
Re: [linux-audio-dev] Plugin APIs (again)
Hi Tim, I like the style of your proposed API. A few comments: *) Scope: your stated goal is to produce an API that is full-featured enough to be the primary plugin system for an audio-development application. I think it would be more correct to say that this is an API designed for virtual instrument plugins, with a programmatic rather than GUI interface (as LADSPA is for effects plugins). This is not a bad thing, in fact I think we are better served with small, focussed plugin APIs for specific tasks -- and virtual instruments and effects are two very worthwhile specific tasks. Also, there are plugins that cannot be accomodated by this API; eg. causal plugins (eg. reversal of large buffers), plugins for which nsamples in != nsamples out (eg. time stretching and rate conversion), and plugins which need to do a number of passes (eg. GWC's noise reduction needs to profile some quiet data in a first pass); not to mention that this plugin implies time domain manipulation only. I don't think the scope of your API should be expanded to include these, as it would lose much of its elegance -- it would be awful to clutter the common cases (instruments and effects) just for the needs of offline and highly analytic plugins. However I would suggest that you refine the stated scope (eg. instruments and inline effects) and concentrate on doing a good job of that. *) Note control: I prefer your first method (separate voice_on() and off() functions, rather than a single voice_ctrl() function) -- for the same reason that ioctls are bad, mmkay and syscalls are good, ie. there's no need for a cryptic overloaded control function, especially here to implement only a well defined set of operations. *) Identifying controls: It would be quite useful to share the same get() and set() functions between a number of controls (eg. similar sliders of an equaliser), for which you would want eg. an int parameter identifying the control index. (In those situations, making a bunch of tiny interface functions within the plugin is pretty ugly). *) Descriptions: It'd be nice to supply both short and long descriptions for controls as well as for the whole plugin. that's it from me for now; nice work overall, I like that it treats multiple channels coherently and handles enum and string inputs, that makes generated GUIs a lot nicer :) Conrad.
Re: [linux-audio-dev] Announce : Secret Rabbit Code (aka libsamplerate)
Hi, I just wanted to mention that: a) Secret Rabbit Code ROCKS! and b) Sweep 0.5.11 (released a few days ago) has support for it, for sample rate converting the whole buffer. You'll need to build from source, ./configure will detect the rabbit and then it's all good :) ... http://sweep.sourceforge.net/ Conrad. On Sun, Dec 01, 2002 at 06:48:22PM +1100, Erik de Castro Lopo wrote: Hi People, This is the first announcement of Secret Rabbit Code: http://www.mega-nerd.com/SRC/ Secret Rabbit Code is a library for doing Sample Rate Conversion on audio. The web page has the full spiel of what it does. The source code tarball has two demo programs: sndfile-resample - A program which can perfrom sample rate conversion on a given sound file. varispeed-play - A program which plays a given sound file in a loop. During play, the speed of the playback is continuously varied. Lots of fun on drum loops and full mixes. This currently runs only on Linux/OSS (probably also ALSA OSS emulation). Work is being done on ports to MacOSX, Solaris and Win32. At the moment the rabbit code is known to compile on Linux and MacOSX. Win32 and Solaris support is coming RealSoonNow (tm). Enjoy, Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Everyone seems to assume that the current system in America is capitalism. I beg to differ. True capitalism does not involve false advertising, distribution cartels, or political lobbying for special advantages in the market. How can you call Microsoft or the RIAA capitalist, when their main business is interfering with a free market? Some of us would like to see a *return* to capitalism in this country. - Jim Flynn on Linuxtoday.com
Re: [linux-audio-dev] Wave Editors
On Fri, Oct 25, 2002 at 02:18:43PM -0400, Paul Davis wrote: Is this really of any use? I never recorded with sweep (I use ecasound), but when I tried to load a 10 minute ogg file into sweep, it refused this because of exhausted memory. I have 256 MB, that should be enough for 10 minutes of sound data. So how good is sweep with longer soundfiles? *if* sweep uses floats or ints to represent audio data in memory (a big *if*) then 10 minutes of 48kHz 2 channel audio is about 219MB: mins * secs/min * samples/sec * bytes/sample * channels 10 * 60 * 48000 * 4 * 2 = 23040 / 1048576 = 219 yep (floats) in fact sweep will even tell you how much memory it's blowing: http://www.metadecks.org/software/sweep/images/screenshots/tour/new_file.png i would consider a much more fundamental problem with sweep (which the author has plans to fix at some point) is the assumption that the audio data will fit in memory. this just isn't viable for working with music rather than audio clips. yep, you're right about that assumption. This year I kind of had to make a stable editor for short clips, so I went all out on the GUI and usability for sweep. I'm actually more interested personally in editing music than clips, so this is going to change. I've already got most of the internal code for that (and a whole lot more), but I'll shut up about that until its done. what I have found though is that you can do a hell of a lot more in memory than I'd previously thought possible, now I have to translate as much of that as possible to a work with disk caching :) Conrad.
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
Hi Paul, it might save you some hassles if you changed the intro to jack's web pages, which currently read: JACK is a low-latency audio server, written primarily for the GNU/Linux operating system. It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. that, by itself, sounds to the average user an awful lot like a general purpose audio server. Perhaps what you wrote in the email below, comparing JACK to ASIO, would be more appropriate. Conrad. On Mon, Oct 21, 2002 at 09:27:16PM -0400, Paul Davis wrote: So why, having studied the docs, am I completely stumped with jack? It refuses to play. I don't consider any solution based on a piece of software _I_ can't operate suitable for general use. JACK *isn't* intended for general use, and i get tired of suggestions that it should be. there are lots of people working on solutions for general use. JACK is intended for people who are serious about audio. in particular, although it might work with crappy consumer audio interfaces, its not intended to do so. if you can't run JACK at all, you basically have a box that wouldn't run an ASIO device driver under windows or macos. there's not much we can do about that except to point you at kernel adjustments (like hdparm) and ask that you check other mailing lists to see if your audio interface, video interface, etc. are known to be horrible in some respect. JACK is not yet finished, and it has some definite usability issues that need to be resolved. but it is not, and i hope will never be (primarily) a general purpose sound server. alternatively, there might be a bug in JACK. perhaps you can help us find it. --p
[linux-audio-dev] Sweep 0.5.8 -- with mp3 importing
Hi, pure evil ... now you can load all your legacy mp3 files into sweep and scrub around with them. I also made a few demo recordings, hooray :) Sweep 0.5.8 Development Release --- Sweep is a sound wave editor, and it is now also generally useful as a flexible recording and playback tool. Inside lives a pesky little virtual stylus called Scrubby who enjoys mixing around in your files. This development release is available as a source tarball at: http://prdownloads.sourceforge.net/sweep/sweep-0.5.8.tar.gz?download MP3 import is now supported (via libmad). Minor bugs have been fixed in rendering of record position and playback mixing. There is a new page of audio demos made with Sweep. These demonstrate the sounds of Scrubby, a tool which allows vinyl-like manipulation of digital audio: http://www.metadecks.org/software/sweep/demos.html Screenshots: http://www.metadecks.org/software/sweep/screenshots/ Sweep is designed to be intuitive and to give you full control. It includes almost everything you would expect in a sound editor, and then some: * precise, vinyl like scrubbing * looped, reverse, and pitch-controlled playback * playback mixing of unlimited independent tracks * looped and reverse recording * internationalisation * multichannel and 32 bit floating point PCM file support * support for Ogg Vorbis and MP3 compressed audio files * LADSPA 1.1 effects support * multiple views, discontinuous selections * easy keybindings, mouse wheel zooming * unlimited undo/redo with fully revertible edit history * multithreaded background processing * shaded peak/mean waveform rendering, multiple colour schemes Sweep is Free Software, available under the GNU General Public License. More information is available at: http://www.metadecks.org/software/sweep/ Thanks to Pixar Animation Studios and CSIRO Australia for supporting the development of this project. enjoy :) Conrad.
Re: [linux-audio-dev] Sweep 0.5.8 -- with mp3 importing
On Thu, Oct 17, 2002 at 06:23:55PM +1000, Conrad Parker wrote: Hi, pure evil ... now you can load all your legacy mp3 files into sweep and scrub around with them. I also made a few demo recordings, hooray :) and now, the broken links to those demo files are fixed ... There is a new page of audio demos made with Sweep. These demonstrate the sounds of Scrubby, a tool which allows vinyl-like manipulation of digital audio: http://www.metadecks.org/software/sweep/demos.html Conrad.
Re: [linux-audio-dev] Silence Detection
On Thu, Oct 17, 2002 at 03:31:36PM -0400, Taybin Rutkin wrote: On Thu, 17 Oct 2002, David Arney wrote: I work with a small community radio station, and since we're continually strapped for cash we implement our studio-transmitter link by streaming audio over a network. We use a variety of players and formats (mainly xmms and realplayer), but all of them share a common problem. Despite our process monitoring software, the stream occasionally goes silent. We would like to find a way to detect when the output of the playback computer's soundcard is silent- or at least quiet enough to count as such. Were you planning on using a noisegate algorithm? I think you would have to. One common mistake people make is thinking that silence is going to be all zeros. But that's almost never the case when doing real work with analog equipment. I'm not sure where to find an algorithm for that, but Steve Harris has many many open plugins at plugin.org.uk . we've got some bits of code for doing that at CSIRO: * MPEG Maaate has an analysis plugin for detecting loudness levels in the MPEG compressed domain: http://www.cmis.csiro.au/maaate/ * we did a select by energy plugin for Sweep that works on PCM data by a similar algorithm; have a look at plugins/byenergy/byenergy.c in the Sweep source distribution: http://sweep.sourceforge.net/ (both are GPL) Conrad.
[linux-audio-dev] Sweep 0.5.4 -- !ybburcS olleH
Sweep 0.5.4 Development Release --- Sweep is a sound wave editor, and it is now also generally useful as a flexible recording and playback tool. Inside lives a pesky little virtual stylus called Scrubby who enjoys mixing around in your files. This development release is available as a source tarball at: http://prdownloads.sourceforge.net/sweep/sweep-0.5.4.tar.gz?download Changes since version 0.5.3 (September 5 2002) include bug fixes for playback during destructive operations and for edits of tiny regions, and improvements in configuration checks for libsndfile-1.0.0. Additionally, scrubbing is now working for reverse playback, and has been tuned for responsiveness independent of sample rate. There is now a web page introducing Scrubby and outlining a few simple editing and live performance techniques: http://www.metadecks.org/software/sweep/scrub.html Summary of library dependencies: * GTK+ 1.2 (standard in most distributions) * libsndfile-1.0.0, available at: http://www.zip.com.au/~erikd/libsndfile/libsndfile-1.0.0.tar.gz * libtdb, available in many distributions or at: http://www.sourceforge.net/projects/tdb Screenshot: http://www.metadecks.org/software/sweep/images/screenshots/sweep_20020813.png Sweep is designed to be intuitive and to give you full control. It includes almost everything you would expect in a sound editor, and then some: * precise, vinyl like scrubbing * looped, reverse, and pitch-controlled playback * playback mixing of unlimited independent tracks * looped and reverse recording * internationalisation * multichannel and 32 bit floating point file support * LADSPA 1.1 effects support * multiple views, discontinuous selections * easy keybindings, mouse wheel zooming * unlimited undo/redo with fully revertible edit history * multithreaded background processing * shaded peak/mean waveform rendering, multiple colour schemes Help wanted! Sweep needs testing; please report any problems encountered! Urgent development is required in the following areas: ALSA and Jack support, updating of translations and user documentation. (NB. Sweep works fine with ALSA under OSS emulation -- the native ALSA support needs some fixing). Sweep is Free Software, available under the GNU General Public License. More information is available at: http://www.metadecks.org/software/sweep/ Thanks to Pixar Animation Studios and CSIRO Australia for supporting the development of this project. enjoy :) Conrad. ___ linux-audio-dev mailing list [EMAIL PROTECTED] http://music.columbia.edu/mailman/listinfo/linux-audio-dev
Re: [linux-audio-dev] collaborators - Fruity feel-alike
On Wed, Sep 04, 2002 at 06:25:38PM +1000, Erik de Castro Lopo wrote: Well I certainly hope that libsndfile will be your first choice for sound file I/O. I also have another library that you will find useful once it is finished and released. (no blabbing K :-)) h, secret rabbit code! no worries Erik, I won't blab! speaking of fruity music environments, I hear rumours that that crazy coder over at metadecks.org has forgotten how to sleep! he's been possessed by Scrubby! (seriously now, you must all use Erik's libraries, and put wads of regression testing into your own just like he does, or else risk the damnation of a million segfaults :). K. ps. Scrubby wants the secret rabbit code!
Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
On Wed, Sep 04, 2002 at 02:16:34PM +0100, Richard Bown wrote: On Wednesday 04 September 2002 13:49, Steve Harris wrote: [RDF] 2) A way of ogranising plugins into meaningful categories (so you can pick them from a menu). Ah, is this what I see implemented in Sweep 0.5.2? no, that just sorts them alphabetically, but it puts enough letters in each menu title to make them useful. (By coincidence the Echoes are near the Feedbacks and all the Simple stuff is near the Sine stuff, so some things lump together by chance). however, you still need to know what you're looking for. if we had a set of standard generic categories (echos, distorts, EQs, satan maximisers etc) then, in all apps, the plugins would be easier to find and experiment with for non-expert users ;-) Conrad.
Re: [linux-audio-dev] managing installations from source [CVS]
On Tue, Sep 03, 2002 at 12:45:05AM +0200, Vincent Touquet wrote: Hi, I ask this question here because I know a lot of you manage to install lots of applications from a fresh cvs snaphot without troubles (I think ;). How do you manage these from-source installs ? Are there people who use stow ? [cfr. http://www.gnu.org/software/stow/stow.html] Or does make install / make uninstall usually does a good task of (un)installing the software ? I have installed software from sources this way before, most notably alsa eg. I just wonder if there are any tricks of the trade to be mastered. most packages use GNU automake/autoconf, for which the make uninstall target is fairly reliable. obviously something like the ALSA drivers needs some system-wide configuration, but most apps and libraries will work fine with just make install / make uninstall. tips? if you're installing libraries in /usr/local, make sure /etc/ld.so.conf contains /usr/local/lib, and be sure to run ldconfig after installing or removing libraries. Oh and watch your PKG_CONFIG_PATH, that tends to bite everyone: export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig Conrad.
[linux-audio-dev] Sweep 0.5.1 -- Scrubby learns to remember
(nb. among other things, this release fixes the problem where Sweep's configure complained about libsndfile-1.0.0 being too old ... also take note of the PKG_CONFIG_PATH thing below, which has bitten many people) Sweep 0.5.1 Development Release --- Sweep is a sound wave editor, and it is now also generally useful as a flexible recording and playback tool. Inside lives a pesky little virtual stylus called Scrubby who enjoys mixing around in your files. This development release is available as a source tarball at: http://www.metadecks.org/software/sweep/download/sweep-0.5.1.tar.gz The main change since version 0.5.0 is the inclusion of preferences saving. This is done via libtdb, a rock-solid file datastore with concurrent access initially developed for the Samba project by Andrew Tridgell. Additionally, Sweep 0.5.1 supports the recently released version 1.0.0 of Erik de Castro Lopo's powerful sound file library, libsndfile. Please note that after installing libsndfile from source, you will need to set the PKG_CONFIG_PATH environment variable before configuring Sweep, most likely as follows: export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig Summary of library dependencies: * GTK+ 1.2 (standard in most Linux distributions) * libsndfile-1.0.0, available at: http://www.zip.com.au/~erikd/libsndfile/libsndfile-1.0.0.tar.gz * libtdb, available in many distributions or at: http://www.sourceforge.net/projects/tdb Screenshot: http://www.metadecks.org/software/sweep/images/screenshots/sweep_20020813.png Sweep is designed to be intuitive and to give you full control. It includes almost everything you would expect in a sound editor, and then some: * precise, vinyl like scrubbing * looped, reverse, and pitch-controlled playback * playback mixing of unlimited independent tracks * looped and reverse recording * internationalisation * multichannel and 32 bit floating point file support * LADSPA 1.1 effects support * multiple views, discontinuous selections * easy keybindings, mouse wheel zooming * unlimited undo/redo with fully revertible edit history * multithreaded background processing * shaded peak/mean waveform rendering, multiple colour schemes Help wanted! Sweep needs testing; please report any problems encountered! Urgent development is required in the following areas: ALSA and Jack support, updating of translations and user documentation. Sweep is Free Software, available under the GNU General Public License. More information is available at: http://www.metadecks.org/software/sweep/ Thanks to Pixar Animation Studios and CSIRO Australia for supporting the development of this project. enjoy :) Conrad.
Re: [linux-audio-dev] Sweep 0.5.0 -- Scrubby's surprise
On Tue, Aug 13, 2002 at 10:53:11AM +0200, Robert Jonsson wrote: Great stuff! thanks, and to everyone who's been involved so far, and to the rest of you who will contribute soon ;-) More information is available at: http://www.metadecks.org/software/sweep/ Thanks to Pixar Animation Studios and CSIRO Australia for supporting the development of this project. Uhh... forgive me but... ## ### # # # ###### # # ## # # ## # # # # # # # # # # # # # # # # # ##### ### # # # ## ### ### ### ### # # # #### # # #### # ## # # # ## #### # # # # # # #### yep, they're now using it in production. They got me to add some features and fix up some stuff earlier this year, hence all the new energy in this project :) They're great people to deal with and insisted from the start that it remain open source. CSIRO (the national science labs here in Australia) is my regular employer and have been very supportive of sweep in broader media content and networking research. but this is really just the start, if you like it get onto the sweep-devel mailing list and help out, there's plenty more coding to be done, and it really is fun to work with :) yay scrubby! Conrad.
[linux-audio-dev] Sweep 0.5.0 -- Scrubby's surprise
Sweep 0.5.0 Development Release --- This is the first public development release of Sweep since October 2000. Please try it out and provide feedback and testing! Sweep is a sound wave editor, and it is now also generally useful as a flexible recording and playback tool. Inside lives a pesky little virtual stylus called Scrubby who enjoys mixing around in your files. This development release is available as a source tarball at: http://www.metadecks.org/software/sweep/download/sweep-0.5.0.tar.gz The only dependencies are GTK+ 1.2 and libsndfile-1.0.0rc5. The first is standard in most Linux distributions, and the second is available at: http://www.zip.com.au/~erikd/libsndfile/libsndfile-1.0.0rc5.tar.gz Screenshot: http://www.metadecks.org/software/sweep/images/screenshots/sweep_20020813.png Sweep is designed to be intuitive and to give you full control. It includes almost everything you would expect in a sound editor, and then some: * precise, vinyl like scrubbing * looped, reverse, and pitch-controlled playback * playback mixing of unlimited independent tracks * looped and reverse recording * internationalisation * multichannel and 32 bit floating point file support * LADSPA 1.1 effects support * multiple views, discontinuous selections * easy keybindings, mouse wheel zooming * unlimited undo/redo with fully revertible edit history * multithreaded background processing * shaded peak/mean waveform rendering, multiple colour schemes Help wanted! Sweep needs testing; please report any problems encountered! Urgent development is required in the following areas: ALSA and Jack support, updating of translations and user documentation. Sweep is Free Software, available under the GNU General Public License. More information is available at: http://www.metadecks.org/software/sweep/ Thanks to Pixar Animation Studios and CSIRO Australia for supporting the development of this project. enjoy :) Conrad.
Re: [linux-audio-dev] LADSPA Defaults via RDF
On Wed, Jul 17, 2002 at 12:37:00PM +0100, Steve Harris wrote: On Wed, Jul 17, 2002 at 10:28:10 +1000, Conrad Parker wrote: My concerns are: * bloat -- requiring all LADSPA hosts to link against libxml and ... * licensing -- requiring all LADSPA hosts to link to GPL code Defining a C struct to describe settings (which I did, see above) only solves half the problem. The other half is a way of transmitting the defaults and presets between machines with different architectures. sure, this would only be for author-defined defaults, which would assumedly be minimal and available through getDefault(), and thus implicitly available on any architecture the plugin is available on. The licencing issue I agree with, I would prefer LGPL. For user-defined presets, for which we need read/write access, do any of these XML libraries allow concurrent read/write? otherwise anyone using the same plugin in multiple apps concurrently is going to have a very easily corrupted preset system. (If we're going to link against GPL code anyway, we may as well use tdb [http://sourceforge.net/projects/tdb] :) OTOH, I am starting to think that the live format should be a GDBM file (or TDM, I assume its similar), and RDF/XML should just be used for import/export. This adds an extra layer around the settings, but might be generally better. I'm think you'd need two GDBM files, eg. /usr/lib/ladspa/settings/system.gdbm and ~/.ladspa/settings/user.gdbm This has the advantage that multiple hosts can share the same, live settings information. cool yeah, TDB is a similar concept to GDBM but is designed for concurrent access. It was developed for Samba where its used for all internal tables, and communication between multiple servers, and is very lightweight (the full library is 2000 lines of code), fast and reliable. only problem is its GPL ... Conrad.
Re: [linux-audio-dev] LADSPA Defaults via RDF
Hi Steve, all,
For plugin (author-defined) defaults, I really can't see how any use of
RDF/XML can be a good thing -- we really should be moving towards defining
a getDefault() method in the API, and even dynamic parameter suggestions.
My concerns are:
* bloat -- requiring all LADSPA hosts to link against libxml and
handle xml data is unnecessary. XML lets you do in 100 lines what
took 10 lines before etc. etc. Well defined C structs would be
neater, easier for plugin and app authors to handle, require no
external libraries and have no chance of becoming disassociated
from their plugins. Audio authors are traditionally paranoid about
bloat, now that more are moving to Linux lets not scare anyone away.
* licensing -- requiring all LADSPA hosts to link to GPL code
could limit LADSPA's uptake [tho I'm a fan of the GPL myself]
For user-defined presets, for which we need read/write access, do any of
these XML libraries allow concurrent read/write? otherwise anyone using
the same plugin in multiple apps concurrently is going to have a very
easily corrupted preset system. (If we're going to link against GPL code
anyway, we may as well use tdb [http://sourceforge.net/projects/tdb] :)
Conrad.
On Tue, Jul 16, 2002 at 06:44:59PM +0100, Steve Harris wrote:
OK, I now have a minimal proof of concept for describing LADSPA plugins,
presets and defaults with RDF (http://w3c.org/RDF).
At this point I'd like to get some feedback so I can decide wether to cut
my losses or finish it (a usable library for hosts would be about another
weeks work, on and off).
My solution relys on the raptor RDF parser (GPL), which inturn links to
libxml or expat (though only libxml works ATM). An example code fragment
to find the defaults for a plugin, given its UID looks like:
def_uri = lrdf_get_default_uri(uid);
if (def_uri == NULL) {
printf((none known)\n);
return 1;
}
printf(Defaults for plugin %d: %s\n, uid,
lrdf_get_setting_metadata(def_uri, title));
defs = lrdf_get_setting_values(def_uri);
for (i=0; i defs-count; i++) {
printf(\tport %d (%s) = %f\n, defs-items[i].pid,
defs-items[i].label, defs-items[i].value);
}
lrdf_free_setting_values(defs);
giving:
[swh@dumuzi lrdf]$ ./showdefaults 1416
Defaults for plugin 1416: Concert A sine (soft)
port 1 (wave) = 1.00
port 2 (freq) = 440.00
port 3 (warm) = 0.50
port 4 (instab) = 0.00
You can see my work in progress at http://plugin.org.uk/lrdf/ , if you're
brave you could try building it, make sure you build raptor with
./configure --with-xml-parser=libxml
The bad news is that RDF is pretty verbose, a description of 61 plugins +
thier defaults comes in at 91k (all.rdf). This doesn't include scales,
units, metadata (see sample.rdf) or the type hierachy, but they won't add
much.
Also in the directory above is a sample plugin description (sample.rdf)
and a sample defaults file (default-sample.rdf).
Conclusion
Advantages
Its a unified way of describing everything* about plugins, it's standards
compliant, extensible, and generally good.
Disadvantages
Its not as efficient as a pure XML approach.
Comments?
- Steve
* well... most things
Re: [linux-audio-dev] LADSPA clarifications?
On Mon, Jul 15, 2002 at 12:00:37PM +0200, J?rgen Zimmermann wrote: Hello, I just joined the linux-audio-dev list a few days ago, and after some time studying the ladspa.h file, I have still some questions left: 1. Must the buffers assigned to audio input and audio output ports have the same length? Where is this stated??? The sample implementations suggest so, though... a) if you're an app (a ladspa host) they must all be at least long enough to handle the SampleCount argument you pass to the plugin's run() method. noone will spank you if your buffers are too big, but your app might go kaboom if you pass a longer SampleCount than what you've allocated. you choose the SampleCount to run() for, and you choose the lengths of the buffers ... in practice, if an app is coded to always call run with a SampleCount of 256 (say), then there's not much point allocating either input or output buffers any longer than that, which is why the code you've looked at allocates buffers all of the same length. b) if you're a plugin well, the lengths of the buffers isn't up to you, but you should hope the app author didn't screw up, and in your run() method you have to assume all the input and output buffers are at least as long as the SampleCount the app asked to run for. 2. Is there any range constraint applied to the audio content communicated by the audio input/audio output ports? VST e.g. does restrict the range from -1.0 to +1.0. by convention, -1.0 to 1.0 (in most plugins and hosts) K.
Re: [linux-audio-dev] Sample conversion tools
On Mon, Jun 03, 2002 at 04:39:55AM -0400, rm wrote: i currently have a simple gtk based app called abrowse for the conversion of AKAI S1000/3000 sample libraries at http://abrowse.sourceforge.net/ the current code base is around 3 years old, and i'm embarking on a bit of re-architecting. interest has been expressed for generalizing the program to include plugins to handle multiple formats. my current plan is to support akai S1/3k, giga, and possibly roland and emu formats. each plugin will support a path like abstraction for addressing data, output in mono wav (float or integer?) along with some set of properties in a key/value hash (in xml files perhaps?). libsndfile (http://www.zip.com.au/~erikd/libsndfile/) provides an excellent simple API for addressing data, and read/write in short/int/float/double (virtualised, ie. independant of what's on-disk). Although it doesn't give explicit support for file properties it would probably be trivial to add (via the existing sf_command() interface; Erik?) You would probably save yourself the most time by contributing your file readers to that (and then other applications built on libsndfile will benefit from your work also :)) Next, you would write abrowse to use libsndfile, which is easier than falling off a teflon log after drinking a bottle of vodka: http://www.zip.com.au/~erikd/libsndfile/api.html and you would instantly be able to export to not just WAV but also AIFF, AU, and a bunch of others, even in floating point where possible. Also, if you wrote file writers for each sample patch format, you could just as easily convert between formats, even changing bit width on the fly ... Conrad.
Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
On Thu, May 30, 2002 at 06:30:35PM +0100, Steve Harris wrote: On Thu, May 30, 2002 at 09:41:25 -0400, Paul Davis wrote: I would say that persets are metadata, and so they should be seperate from the API. do you agree that defaults are really a preset? Yes, but I was being pragmatic. I think that defaults are more important than a standardised preset format. yep, I agree -- we *need* a mechanism for defaults so that users can load up a plugin and work with useful settings from the start. Without that, LADSPA is a harcore-audio-hackers-only tool; with it, users could learn about the plugins by experimenting with them (and hence, become hardcore audio hackers, so that they too may contribute to LAD's world domination :). general presets, on the other hand, are more of a *want* item -- they're cool, but can wait past LADSPA 1.1. [The lower half of this message discusses this ...] I also thought that it would be easier to get people to agree on a defaults system than a presets system. This doesn't appear to be true ;) getting there -- a few people still need to make up their minds ;) since you've already agreed that we need defaults, and since i find it hard to argue with the idea that defaults are presets, i personally find the conclusion that we actually need an API for presets fairly compelling. API, no. Spec, yes. An RDF (for preference) or XML file + filesystem convention should do the job. We've been there before though. Maybe we should have a presets server, or write it on punch cards and read them with a scanner. ;) Hehe. I think we're confusing two kinds of presets, and hence some people want presets in the plugins, and some want them separate (RDF, XML, punch cards ...). [I haven't seen this distinction covered before, apologies if it has been.] First up there are presets without which the plugin is fairly useless to a novice, and which would be equally useful to everyone just to get started. These include defaults and, for plugins with more than one mode of behaviour, a canonical example of each mode. These are known by the plugin author at the time of writing the plugin, and for all intents and purposes are part of the plugin. Some concrete examples taken from Steve's LADSPA Plugin Docs (http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html): * The description of Juhana's GVerb contains the comments: Roomsize (m) ... Values of around 30 sound good Reverb time (s) ... 7 is a good place to start. The plugin should simply start at a good place ... * The description of the Crossover distortion is: This is a simulation of the distortion that happens in class B and AB power amps when the signal crosses 0. For class B simulations the smooth value should be set to about 0.3 +/- 0.2 and for AB it should be set to near 1.0. These two modes of simulation would be equally useful starting points, as suggested by the plugin's author. Let's call these author presets. Secondly, there are presets which a user discovers through experiment and wants to save for later, or which users trade with each other, or which the plugin maintainer or distributor thinks are simply cl. These evolve over time. Let's call these user presets. The nature of author presets is that they should always exist when the plugin exists, and they will not change or develop over time other than when the plugin does. I'd suggest these should be provided by the plugin, and available through the LADSPA API. User presets, on the other hand, must be user definable, edittable, shareable, etc. and for these, RDF/XML/punch cards make sense. If we keep author presets within the plugin, then we can know they will always be available and correct, even if the user blows away or messes up their user presets, or if a new version of the plugin alters its parameter usage and gets out of sync with its previous presets. If we keep user presets separate from the plugin, users can modify them and share them, and never risk harming the plugin. Hence, finally getting back to Paul's suggestion -- ie. taking a step back and looking at the bigger question regarding defaults -- I think it makes sense to: * handle author presets (at least a single set of defaults) through the LADSPA API. * handle user presets through a separate means such as RDF/XML Conrad.
Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
On Wed, May 29, 2002 at 11:51:56PM +0100, Richard W.E. Furse wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Goetze
Sent: 29 May 2002 22:32
[...]
totally agree -- Tim's solution doesn't break binary compatability,
richard pointed out that it'd actually break binary compatibility with
hosts that call connect_port at every processing cycle.
however, until these hosts are fixed, it only means 'always default'
rather than 'always segfault' for them so i'm still for it.
[...]
To flesh this out, some problems I can think of with this approach are as
below (mostly following from the first):
I'll deal with each in turn, but preface this by clarifying that we are
only talking about control ports, not audio ports, because:
* conceptually, we're only talking about default parameters;
default audio input would be a somewhat stranger concept.
* practically, connect_port() doesn't have a SampleCount arg
so it could not consider blocks of audio.
You made this point in 4. and 5. below too, I don't think anyone was asking
for default audio input.
1. Writing to inputs is conceptually ugly.
sure. but initialising inputs to a sensible default at creation isn't
nearly as bad -- and only the plugin knows what is sensible. The scheme
you suggest with a multitude of hints either offloads much of that
decision onto the host, which simply cannot know which values are useful,
or unnecessarily limits default values to {0.0, 1.0, 100.0, 440.0}.
It's writing to inputs at run() which would be truly ugly ;)
2. The find a default a GUI has to do the following: [a] load the library,
[b] instantiate the plugin, [c] write a value to a memory location, [d] call
connect_port(), [e] compare old and new values, [f] if they're the same,
repeat [c] to [e] with a different value in case the written value happened
to be the default, [g] destroy the plugin. This can be simplified by
addition of a default flag, but even so it's ugly.
no; a host need only do [a] [b] and [d].
I'd argue that a host only ever gets down to the nitty gritty of considering
actual data values when it's getting ready to run -- ie. the user has already
indicated they want to be using this plugin, the host has a sample rate, it
just wants to go that extra step and set up the parameters before calling
run().
By the time a host needs defaults, it's already done [a] [b] and [d].
3. A plugin has to be loaded and instantiated to find a default value - it
is no longer possible to deal with the plugin in the abstract using just
descriptor data (which is easily marshalled).
yes, it would not be possible to deal in the abstract with concepts like:
* default gain = 0.7
* default window_length = 0.25 * sample rate
(these concepts look pretty concrete to me!).
It would still be possible to deal in the abstract with concepts like:
* the gain control is a logarithmic input
* the window_length is an integer input with these bounds
I think the point of dealing in the abstract is to consider the scope and
use of a parameter, eg. in order to decide what kind of slider to display or
to decide whether a host can make use of a plugin at all. But by the time
you're considering default values, your dealings are getting concrete.
4. The semantics are untidy with audio ratio ports and outputs. Output
defaults are admittedly of limited usefulness (but of some - consider a host
that's going to filter the output or flash a light when a toggle changes - a
default is a useful initial value). Audio rate defaults ARE useful - however
at the connect_port() stage the plugin can write only to the first point of
the buffer. Only the host knows how long the buffer is and will have to copy
the value through the buffer so it cannot just connect the port and forget
about it.
yes, default audio input is stranger and not part of this proposal.
5. connect_port() used with read-only shared memory or memory-mapped
soundfiles will segfault (I'm mostly using using IEEE float soundfiles at
the moment, so the latter is a real requirement).
yes, another reason not to handle default audio input.
6. Hosts can no longer usefully call connect_port() each frame - they will
always lose their intended input data on defaulting ports. These hosts will
always have to copy data into place, in which case it's more efficient just
to call connect_port() once only at initialisation. This is a nuisance for
hosts using event or frame packets rather than fixed data areas (e.g.
Glame?).
as others suggested, perhaps hosts built in this way are broken anyway.
in any case, I'd think it's *less* efficient to call connect_port() each
frame than to copy a single float of data to a known location each frame.
Creative thinking though...
My preference is the extra 4bits of hint. I'm happy to get rid of the high
and low options if they're too confusing
Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
regarding the provision of default values in LADSPA, I totally support Tim's suggestion -- in fact, I reckon it is brilliant for reasons I'll outline below :) On Tue, May 28, 2002 at 04:25:21PM +0200, Tim Goetze wrote: Steve Harris wrote: On Mon, May 27, 2002 at 02:21:04 +0200, Tim Goetze wrote: so what do you think about the actual proposal? (*DataLocation = default in connect_port) I don't think it gains anything over Richards original suggestion, does it? The problem is that it moves the definition of the defualt values away from the definition of the port's data. agree. however i reckon it won't hurt too badly to have default values no sooner than when the plugin is instantiated. I think it's even more powerful this way because it lets a plugin calculate defaults programmatically, taking into account the instantiated sample rate and the state of the plugin. if we restricted ourselves to keeping the definition of default values near the definition of the port's data, we would restrict ourselves to static default mechanisms, such as simple default values or kludgy default boundaries. by making the defaults an outcome of connect_port() instead, we get a dynamic mechanism for free. Default frequencies can be related to the sample rate, etc. Going further (but still without breaking binary compatibility), we see that we are already allowed to call connect_port() multiple times, even between calls to run(); from ladspa.h: connect_port() may be called more than once for a plugin instance to allow the host to change the buffers that the plugin is reading or writing. These calls may be made before or after activate() or deactivate() calls. so, a very smart plugin could profile the data it is being fed via run() and then suggest a very relevant default value for a parameter on a subsequent call to connect_port(). So, now, default values can be related to the plugin's state and the kind of data being processed (eg. a suggested compression ratio for the kind of data that has been processed so far). All this requires is that a plugin suggest default values in the way Tim proposed: by setting *DataLocation before returning from connect_port(). It would still be perfectly valid for a host to ignore this, and it would still be perfectly valid for a plugin to not modify *DataLocation, so existing hosts and plugins should not be affected. the LADSPA_HINT_DEFAULT_* solution looks very awkward to me, and despite all the code it involves it isn't even capable of expressing any value from the valid range. i think it would even be better to break binary compatibility now than force ourselves to support a kludge like this (sorry, richard) in future versions of the API. it is better to admit that we cannot have a perfect solution without breaking binary compatibility, and thus should at least go for the simpler one, i think. totally agree -- Tim's solution doesn't break binary compatability, doesn't introduce any new symbols or macros and doesn't consume any bits out of the port hints; plus, it allows plugins to set defaults using any criteria they like. all it requires is additional (but backwards-compatible) behaviour for those plugins and hosts that care about default values, and that this behaviour be documented in ladspa.h. a suggested patch to ladspa.h, touching comments only, is attached :) Conrad. --- /usr/include/ladspa.h Wed Aug 8 20:21:03 2001 +++ ladspa.hWed May 29 14:08:46 2002 -352,14 +352,20 to be an array of LADSPA_Data for audio ports or a single LADSPA_Data value for control ports. Memory issues will be managed by the host. The plugin must read/write the data at these - locations every time run() or run_adding() is called and the data - present at the time of this connection call should not be - considered meaningful. + locations every time run() or run_adding() is called. + + The data present at the time of calling connect_port() should not + be considered meaningful. However a plugin may suggest a default + control value by setting this data before returning from + connect_port(). Thus a host that requires useful default values + for control inputs can get these by examining the data contents + immediately after a call to connect_port(). connect_port() may be called more than once for a plugin instance to allow the host to change the buffers that the plugin is - reading or writing. These calls may be made before or after - activate() or deactivate() calls. + reading or writing, or to request updated default control values. + These calls may be made before or after activate() or deactivate() + calls. connect_port() must be called at least once for each port before run() or run_adding() is called. When working with blocks of
