ladspar is a Ruby module for using LADSPA plugins. Here's a short
example:
---
require 'ladspa'
require 'narray'
# load the CMT library
cmt = LADSPA.load_library('cmt')
# get an instance of the amp_mono plugin
amp_mono = cmt.plugins.find {|p| p.label == 'amp_mono'}.instantiate(44100)
# The ports are Gain, Input, and Output.
amp_mono.ports[0].connect_port(1.5) # gain
input = NArray.sfloat(44100)
amp_mono.ports[1].connect_port(input)
output = NArray.sfloat(44100)
amp_mono.ports[2].connect_port(output)
amp_mono.activate if amp_mono.has_activate
# prep the input data ...
amp_mono.run
amp_mono.deactivate if amp_mono.has_deactivate
amp_mono.cleanup
---
This is the first release of ladspar; I consider it beta quality. I have
put it through its paces (more test code than swig code), but I am the
only one to have tested it. Nevertheless I think it is usable, and I am
eager to fix any bugs you may find.
Go grab it at http://rubyforge.org/projects/ladspar
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
>From: Dave Robillard <drobilla(a)connect.carleton.ca>
>
>The question is, which implementation is best? All I can find is
>Steve's liblo, libosc++, and the 'official' OSC kit. What are the
>advantages/drawbacks of each? I can find very little information on any
>of them.
Last I checked OSC, it had Lisp/Scheme like syntax. Don't know
if that is a drawback --- anyone?
Has anyone used MPI (Message Passing Interface) for this?
People use these for high performance parallel computations
in Linux clusters. MPI itself is a standard supported by academic
and by vendors. MPI is used, e.g., in supercomputers.
See, e.g.,
http://www.csc.fi/reports/pc-cluster/Finalreport.pdf
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
This bit ardour a little while ago when one plugin author changed the number or ordering of their ports without changing the ID number.
Taybin
-----Original Message-----
From: Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
Sent: Jul 29, 2004 4:00 AM
To:
The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu>
Subject: Re: [linux-audio-dev] LADSPA "Unique" IDs
On Thu, Jul 29, 2004 at 09:17:03AM +0100, Chris Cannam wrote:
> On Thursday 29 Jul 2004 12:42 am, Dave Robillard wrote:
> > I vaguely remember a discussion here about LADSPA ID's (unsigned
> > long UniqueID) not actually being globally unique to a plugin like
> > the header implies, but I can't find it in the archives.
> >
> > So.. unique or not? Basically I need to know what the "proper"
> > information is to send a synth in order to load a plugin.
>
> The outcome was that (i) LADSPA _does_ appear to specify that the
> unique ID should be globally unique, but (ii) it's not in practice
> easy to guarantee that, for generated or wrapper plugins (e.g. a vst
> wrapper that doesn't know how many plugins will be in the .so until
> it's counted your VSTs), and (iii) some plugin developers (Steve!)
> thought the LADSPA docs said differently anyway, so it's possible
> they may have made plugins with duplicate IDs.
Personally I've only done that by accident! But it has happened. My buil
process now has a bozosity checker run, that looks for silly mistakes,
like two plugins with the same ID. I do learn eventually :)
> /* This identifier can be used as a unique, case-sensitive
> identifier for the plugin type within the plugin file. Plugin
> types should be identified by file and label rather than by index
> or plugin name, which may be changed in new plugin
> versions. Labels must not contain white-space characters. */
>
> To me this makes it pretty plain that filename and label is at least
> intended to be a valid unique ID within your filesystem, and in
> practice I'd expect it to be an effective id for the plugin anywhere
> in the world.
I think it should be: local filenames are unique, and labels are
required to be unique in the file.
A problems with using UIDs for this kind of thing is that they dont have
to change with plugin versions, so you can end up with two plugins iwth
the same ID and ports, but different paths nad different effects/bugs, and
you dont know which one to load.
> One problem is that there seems to be an informal understanding that
> if you change the port specifications for a plugin you should also
> change its unique ID, but I don't think there's any such
> understanding for labels, so you don't have the reassurance of
> knowing you're using the version you actually intended.
All this and more :)
- Steve
Hello everybody,
At http://hortus-mechanicus.net/perl/audio-ladspa/
you can find my attempts at making a LADSPA interface for
Perl. The LADSPA API should be completely supported, but at the
moment the system only supports mono audio out (via
Audio::Play) and no way of reading/writing audio files.
There is also a crude GUI at:
http://hortus-mechanicus.net/perl/audio-ladspa/rack.perl.txt
To use the GUI you need to have perl-tk installed.
Bugreports / missing features welcome.
Joost Diepenmaat.
--- README follows ---
Audio::LADSPA
==============
This is a set of extensions to host LADSPA plugins,
you can query them, or apply them to audio data.
INSTALLATION
To install this module type the following:
perl Makefile.PL
make
make test
make install
Or, if you prefer the CPAN installer, type:
perl -MCPAN -e'install Audio::LADSPA'
Which will fetch, make and install the module for you.
DEPENDENCIES
LADSPA dependencies:
The tests specifically need the demo plugins from the
ladspa_sdk package, with LADSPA_PATH pointing to the
directory where they are installed.
You do not have to set the LADSPA_PATH environment variable
if your LADSPA plugins are located in either /usr/lib/ladspa
or /usr/local/lib/ladspa, but you will be warned when the
modules are loaded. You'll probably want to set it anyway,
because most other LADSPA hosts need it.
You can download the sdk from from http://www.ladspa.org/
Debian users can use "apt-get install ladspa-sdk"
Alternatively, you can skip the tests, but these modules
are of no use without at least SOME plugins installed.
CPAN dependencies:
Also, this extension requires the following Perl modules;
Test::More, Audio::Play, Scalar::Util, Data::Uniqid
and Graph::Directed
Install them first from CPAN. Alternatively, if you're
installing using the CPAN or CPANPLUS shell, this can be taken
care of automatically.
COPYRIGHT AND LICENCE
Copyright (C) 2003 - 2004 Joost Diepenmaat
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
See the COPYING file for more information
I vaguely remember a discussion here about LADSPA ID's (unsigned long
UniqueID) not actually being globally unique to a plugin like the header
implies, but I can't find it in the archives.
So.. unique or not? Basically I need to know what the "proper"
information is to send a synth in order to load a plugin. At the moment
I'm sending filename and index, which I don't think is ideal. (The
synth could be running on a completely seperate machine, so the sender
and receiver might not have the same LADSPA plugins around...)
Thanks,
-DR-
Hi all,
Thought I'd better get round to releasing this at last:
The noiseweapon is a multitimbral, polyphonic synth that I use for live
performance:
http://www.pawfal.org/Software/noiseweapon/
have fun,
dave
hi,
for being able to try the linux port of mythical ircams "open music" I
trying to compile from source (CVS) the grams "midishare"
unfortunately, with some build errors.
My box:
slackware 9.1/current, kernel 2.6.6, gcc 3.3.3
every aid is a lot appreciated
Lazzaro
Follow the errors:
make[1]: Entering directory
`/opt/sources/midi/midishare/linux-dev/midishare-linux/linux/kernel'
gcc -O6 -Wall -D_LOOSE_KERNEL_NAMES -DMODVERSIONS -D__Pentium__
-DCONFIG_KERNELD -DMODULE -D__KERNEL__ -DLINUX
-I/lib/mod ules/`uname -r`/build/include/ -I../../common/Headers -c -o
msLoader.o msLoader.c
In file included from /lib/modules/2.6.6/build/include/asm/processor.h:18,
from
/lib/modules/2.6.6/build/include/asm/thread_info.h:16,
from
/lib/modules/2.6.6/build/include/linux/thread_info.h:21,
from
/lib/modules/2.6.6/build/include/linux/spinlock.h:12,
from
/lib/modules/2.6.6/build/include/linux/capability.h:45,
from /lib/modules/2.6.6/build/include/linux/sched.h:7,
from /lib/modules/2.6.6/build/include/linux/module.h:10,
from msLoader.c:41:
/lib/modules/2.6.6/build/include/asm/system.h: In function
`__set_64bit_var':
/lib/modules/2.6.6/build/include/asm/system.h:193: warning: dereferencing
type-punned pointer will break
strict-aliasing r ules
/lib/modules/2.6.6/build/include/asm/system.h:193: warning: dereferencing
type-punned pointer will break
strict-aliasing r ules
msLoader.c: In function `prnt':
msLoader.c:79: error: structure has no member named `tty'
msLoader.c:84: error: request for member `write' in something not a
structure or union
msLoader.c:85: error: request for member `write' in something not a
structure or union
msLoader.c: In function `MidiReset':
msLoader.c:130: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at
/lib/modules/2.6.6/build/include/linux/module.h:51 3)
msLoader.c: In function `myopen':
msLoader.c:141: warning: `MOD_INC_USE_COUNT' is deprecated (declared at
/lib/modules/2.6.6/build/include/linux/module.h:50 1)
msLoader.c: In function `myclose':
msLoader.c:150: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at
/lib/modules/2.6.6/build/include/linux/module.h:51 3)
make[1]: *** [msLoader.o] Error 1
make[1]: Leaving directory
`/opt/sources/midi/midishare/linux-dev/midishare-linux/linux/kernel'
make: *** [kernel] Error 2
I've been putting together a library for using LADSPA plugins in Ruby. I
think it's code-complete, and could use some early beta testers while I
finish packaging it up. If you know ruby and LADSPA and would like to
look at it send me an email off-list and I'll send you a tarball.
I anticipate a first release later this week.
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
>From: "Susan R. Cragin" <susancragin(a)earthlink.net>
>
>Can anyone send me to a web site describing wavelet sampling as it
>applies to speech recognition?
Probably best would be to search at ACM and IEEE digital libraries.
But google can bring up good papers too.
http://www.wavelet.org should be worth of looking at. They publish
a digest having research notifications.
Juhana