Hello list,
After much debate, I propose to extend the current LADPSA 1.1 interface
specification in the way documented below. Two new LADSPA_HINT bits are
introduced. Both can be ignored by existing hosts without any ill
consequences.
The purpose of the first new bit is to allow simple hosts that do not
need the extended information in an RDF file to display meaningfull
labels on a switch widget, as they can already do for e.g. sliders.
The second new bit allows a plugin to request that the host indicates
unconnected ports by providing a NULL pointer.
To those who have followed the debate, I changed the original name
LADSPA_HINT_ENUMERATED to LADSPA_HINT_SWITCHED. This more correctly
represents the idea, and also allows Tim to use LADSPA_HINT_ENUMERATED
for his proposal which is complementary to this one.
The text below represents those sections of ladspa.h that would be added
or modified by this proposal.
--
Fons
------------8<-------------------------------------------------------
#define LADSPA_VERSION "1.2"
#define LADSPA_VERSION_MAJOR 1
#define LADSPA_VERSION_MINOR 2
.....
/* This hint must be used only together with LADSPA_HINT_INTEGER.
It indicates that the port corresponds to a multiway switch selecting
between options that have no natural numerical value. A port using this
option would typically correspond to a switch statement in the plugin
code, and can be represented in a GUI by a menu, a set of radio buttons,
or any '1 out of N' selection widget.
For each option a label string is provided in the PortNames array (see
below). These strings come after all port names. They must be listed
in order of the ports using this hint bit, and for each port in order
of the numerical value that represents the switch option. The number of
options and strings is equal to MAX - MIN + 1, where MIN and MAX are
the values of the LowerBound and UpperBound fields in the PortRangeHint
struct for the port. These values must be integers. */
#define LADSPA_HINT_SWITCHED 0x400
/* This hint indicates that a host may provide a NULL pointer for this
port, to indicate that it is not connected. The host must still define
the port pointer, even if it is NULL. The plugin code must check ports
using this bit after each call to connect_port() (see below) that may
have changed the port's pointer. */
#define LADSPA_HINT_NULLPOINTER 0x800
......
#define LADSPA_IS_HINT_SWITCHED(x) ((x) & LADSPA_HINT_SWITCHED)
#define LADSPA_IS_HINT_NULLPOINTER(x) ((x) & LADSPA_HINT_NULLPOINTER)
......
/* This member indicates an array of null-terminated strings
describing ports (e.g. "Frequency (Hz)"). Valid indices vary
from 0 to PortCount-1.
If there are any ports using LADSPA_HINT_SWITCHED, then their
label strings follow after all port names (i.e. the port names
remain in their normal place). In this case the range of valid
indices is increased by the number of labels defined. The labels
are not included in PortCount. */
const char * const * PortNames;
------------8<-------------------------------------------------------
attached you'll find my latest patch against ladspa.h that, in
addition to the previous patches, discusses the well-known-port
concept and in particular the "_latency" port. it removes the
Latency member from the descriptor structure, introduces
LADSPA_VERSION and tries to clarify things in other places.
as before, the patch causes no side-effects in hosts and plugins
implementing ladspa 1.1 during either compilation or use. in
effect, upgrading is painless.
to keep this post small, the accompanying sample host and plugin
source code has been moved to http://quitte.de/ladspa .
tim
Wait, I just implemented support for RDF presets in Ardour. Is that for naught? We're doing something else now?
Taybin
-----Original Message-----
From: Matthias Nagorni <mana(a)suse.de>
Sent: Mar 10, 2004 5:46 AM
To:
The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu>
Subject: Re: [linux-audio-dev] LADSPA extension - Formal proposal.
On Tue, 9 Mar 2004, Fons Adriaensen wrote:
> To those who have followed the debate, I changed the original name
> LADSPA_HINT_ENUMERATED to LADSPA_HINT_SWITCHED. This more correctly
> represents the idea, and also allows Tim to use LADSPA_HINT_ENUMERATED
> for his proposal which is complementary to this one.
Thanks a lot for your proposal. It solves the issue which has triggered
the debate, namely the ill representation of the preset names in the TAP
reverb. I hope that Tom will follow your suggestion in his plugin, so that
I can modify AlsaModularSynth to support Combobox selectors for LADSPA
plugin GUIs.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
On Wed, Mar 10, 2004 at 11:44:26AM +0000, Steve Harris wrote:
> But it will use up two flags that may be needed later and may clash with
> future extensions, or produce binary imcompatibility. Not to mention that
> it is effectivly a fork in LADSPA.
There are still 20 bits left. And we can reserve #31 for a version jump anyway.
And I think 1.1 -> 1.2 is not a fork, it isn't meant to be anyway.
> I think this is a very, very bad idea.
Do you mean the proposal, or any premature implementation ?
--
FA
attached you'll please find three files:
* a patch moving ladspa.h 1.1 to 2.0
* a program showing how a host evaluates 2.0 extensions
* a thoroughly documented example plugin making use of the extensions
changes to the patch with respect to the last version include
consolidation of the extended port info into a dedicated structure.
also included is a warning note concerning the deprecation of the
1.1 default value hints and some minor clarifications.
the patch defines HINT_MOMENTARY as asked by Taybin and Steve. it
also credits Taybin now (Steve already being credited).
-
the example plugin is written with the intention to show, in all its
sometimes gory detail, how ladspa works 'from the plugin side'. the
plugin is fully operational in hosts implementing either version of
the standard. (it doesn't even sound so bad at all :)
there are a number of more elegant ways to accomplish what the plugin
source does, but these have all been ignored for the sake of showing
exactly how things are coming together in ladspa.
-
if you expect the extension to make a plugin author's life harder by a
significant amount, i would like to ask you to go over the source code
of the example plugin and see for yourself.
all the places where the plugin refers to the 2.0 incarnation have
been marked as such. i'm confident you'll agree that words like
'invasive', 'incomprehensible', 'bloated' or 'complicating' are not
doing the extension justice.
i would also like you to consider that it is up to you, either plugin
or host author, to altogether ignore the extension and still come up
with something perfectly useful. you can always extend your work to
make use of the extension at a later date. all this takes is added
code, with no changes to what you already have.
-
my apologies offered for the obnoxious use of the '2.0' version tag
for this proposal. for sheer lack of fantasy, typing laziness and a
number of other bad habits, i couldn't come up with something better.
amicalement,
tim
ps: it is hoped that the example plugin source will be helpful to
aspiring plugin authors, no matter the fate of the extension proposal.
How should a host deal with a port that is MOMENTARY, but not TOGGLED? What would the UI be?
Taybin
-----Original Message-----
From: Tim Goetze <tim(a)quitte.de>
Sent: Mar 8, 2004 1:06 PM
To:
The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu>
Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
ok, suppose we say only MOMENTARY, and one-shot triggering is always
rising edge. now we have another problem: Taybin is pretty adamant in
requiring MOMENTARY to imply TOGGLED. this means we'll always need
another port to transmit the velocity value for note-on and similar
events. fine, no problem? apart from this meaning a waste of
resources, how do we transmit two such impulses in successive run()
calls? simply split the run() call in two? at what a waste of
resources do we arrive then, for the doubtful pleasure of having
a 'simple' model. beats the intention of simplicity if you ask me.
Please pardon cross postings.
ICMC 2004 :
Online submissions for papers, demos, and posters are now fully
functional and available at http://www.icmc2004.org. Please follow
instructions on the website. Thank you.
Best Regards,
Tae Hong Park, ICMC 2004 Publicity Chair
That can't be. What would a MOMENTARY output port mean?
Taybin
-----Original Message-----
From: Matthias Nagorni <mana(a)suse.de>
Sent: Mar 8, 2004 11:14 AM
To: Taybin Rutkin <taybin(a)earthlink.net>,
The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu>
Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
On Mon, 8 Mar 2004, Taybin Rutkin wrote:
> The presence of both MOMENTARY and TRIGGER seems redundent. TRIGGER means that it's reset to 0 after one call to run() or run_adding()? That'll happen so fast, the user won't even notice the UI change. If TRIGGER is for scale values, how will it scale if it's set to 0 after every call? The distinction between them is overlapping and confusing.
It looks like TRIGGER is for input and MOMENTARY for output ports.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
Something that was suggested for GMPI, and might be applicable for LADSPA
is a convetion where port names can be written as paths, eg for a delay
line you might have
"delay/base delay (ms)"
"delay/feedback (%)"
"lfo 1/ammount (%)"
"lfo 1/wave"
"lfo 1/frequency"
"lfo 2/ammount (%)"
"lfo 2/wave"
"lfo 2/frequency"
this would allow the host to group the controls logically when building
the UI, eg. tabbing them, and friendlier OSC reflections of plugins.
It would require that lexical /'s be escaped, but other than that it
should be transparent. Its only worth adding if hosts would implement
something using it though, as it would cause a bit of disruption, there
are about 30 exisiting ports with /'s in them.
A different character could be used, but / seems like the obvious one.
- Steve
galan-0.3.0_beta5 is released.
For those who know it already:
One of the new features include cloning. you can now select a bunch of
components and clone them. (This will be changed to a full blown
copy/paste mechanism soon) And the polyphony option will be added soon.
galan is a modular synthesizer similar to SSM and AMS.
The difference is that you build the schematics in one window and
have the controls in another window. So your synth UI is not cluttered
with the schematics.
galan also supports subpatches. You can add patches from the library to
your current patch with 2 mouseclicks.
the LADSPA adsr can be used for real note-on note-off behaviour.
And with the voice allocator it is already possible to build polyphonic
synths. I will refine that process somwhat. But it already works.
When you have setup your schematic and placed the controlling knobs and
sliders on your control panel, you can draw a custom background for the
ControlPanel and import the painted picture into galan. The knobs now
support alpha transparency, so they should integrate onto every
background.
galan supports jack and alsa sequencer. You can open any number of ports
you would like. The internal sequencers can sync to jack-transport.
galan also supports LADSPA. You will have all LADSPA effects handy you
normally use. And you will be able to setup a nice Interface for your
Effects. You would then save them to your sheet library, making them 2
clicks away.
So wiring a jack-inport and another jack-outport to your favorite
plugin, is done in a few seconds.
It even supports the first jack-midi patch (although only as a synth and
as the patch changed recently, there will be no sequencer around :)
perhaps the next patch.
get it at http://galan.sf.net
and look at
http://galan.sf.net/anti-aliased-knobs.png
cause this is how it looks like.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language