Discussion:
[linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?
Marek Peteraj
2004-06-08 09:45:53 UTC
Permalink
Lately, while looking at screenshots of a few VST(i) plugins, i began to
wonder what makes them different from LADSPA plugins. Not technically,
but from the philosophical point of view.

VST plugins tend to be rather complex, offering tons of features and
eyecandish GUIs, while LADSPAs usually offer limited functionality, no
GUI at all(hosts usually provide simple ones to control the parameters).
But what's interesting is that each LADSPA plugin usually implements
exactly one type of DSP technique, for example, an oscillator, or a
delay. This basically leads to a situation where a certain DSP technique
is 'isolated' in a separate plugin.

Now if we look at an arbitrary VST plugin we'll see that it's fairly
complex, and that there's a large amount of creativity involved both
visually and featurewise. But if you look at it closer, you'll recognize
that each such plugin is actually a bunch of DSP techniques put together
in a creative way.

Let's look at JAMin. What makes JAMin interesting is that it's
basically(although probably not entirely, haven't looked at the code) a
collection of LADSPA plugins where each of those plugins implements a
DSP technique dedicated to improve the characteristics of a sound in a
certain way. So JAMin tends to "package" these DSP techniques into a
standalone JACK effect client.
Now imagine you'd replace the gtk+ based GUI with a 3d eyecandish GUI.
What would you get? A typical audiomastering VST plugin. Except - it's a
JACK client.

So LADSPA becomes LA-DSP-A and each such plugin becomes a basic building
block for a complex JACK effect or synth.
The benefits i see:
1. It unifies the way audio is routed from/to/through daws, effects,
synths and other audio applications. The VST(i) vs. Rewire situation
becomes one - JACK.
2. If offers unlimited flexibility (together with MIDI over JACK) - for
example controlling a synth with a DAW via a midi track while letting
the DAW record the output of the synth.
3. It simplifies the notion of handling effects, synths etc in hosts for
the users. No need for insert vs. send.
4. No need for a GUI standard. Simply write your own Gtk+/Qt frontend
whether widget or pixmap based.
5. Allows developers to design complex 'plugins' i.e. JACK effect/synth
clients and be creative in picking DSP algorithms and wiring them
together *even* if they don't have any background in DSP programming.
6. Allows DSP developers to fully concentrate on the DSP part, only
developing the desired DSP technique without caring about the rest.
7. Points 5. and 6. help to accelerate development of complex and high
quality effects and synths that we all miss and the win32 and macosx
users already have.
8. It would unify the LinuxAudio scene in terms of DSP code - DSP =
LADSPA.

Political issues:
1. we'd need to centralize the LADSPA scene on the web, using the
www.ladspa.org site, building a unified ladspa directory, each entry
would describe the plugin(category, author, decription, purpose)
2. the centralised site should make some general suggestions on how to
build complex JACK clients out of LADSPAs, for example splitting the
JACK client in two parts (GUI/engine) communicating via a standard msg
bus system, such as D-BUS, which in turn would make it easier to write
different GUIs for the same JACK client, Gtk+/Qt, pixmap/widget based
etc. Moreover, it would help to set and improve a standard msg bus such
as D-BUS. D-BUS seems to be very attractive since it's binary and comes
from the desktop world which would make this issue
interdisciplinary(linux desktop / linux audio) - a thing which i believe
is crucial for linux in order to become a successful platform.
3. LADSPA should allow to build both complex effects and
synths(technical issues? time-stamped events?)

Comments?

Marek
Steve Harris
2004-06-08 08:18:58 UTC
Permalink
Post by Marek Peteraj
VST plugins tend to be rather complex, offering tons of features and
eyecandish GUIs, while LADSPAs usually offer limited functionality, no
GUI at all(hosts usually provide simple ones to control the parameters).
But what's interesting is that each LADSPA plugin usually implements
exactly one type of DSP technique, for example, an oscillator, or a
delay. This basically leads to a situation where a certain DSP technique
is 'isolated' in a separate plugin.
I think thats down to two factors (and its not a good thing)

1) LADSPA developers are few in number and short in time. The basics are a
good place to start.

2) The lack of a UI standard makes complex plugins a bit pointless.

There are a few counter examples (e.g. my VyNil plugin wraps a lot of
different bits), and infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.

[OT] - my canned plugin writing experience - all generalisations and IMHO
of course

Time breakdown: 10% writing code, 10% maths and optimising, 80% tweaking
and tuning.

Mapping the controls 1:1 with DSP parameters makes plugins crap - people
say they want that if you ask them, but they dont mean it ;)

Fewer controls is better.

Affordance, appearance and usability has as much affect on the perceived
sound quality as the DSP code (posivly and negativly). Some of this can
be achieved without a custom UI.

You mentioned JAMin - true that does use LADSPA plugins - but of the total
ammount of code the LADSPA plugins are a tiny fraction. I just reused them
because I hate fixing bugs in two places :)

[OOT] I used to think that a UI spec for LADSPA (to make it competetive
with VST) was a technological problem. I now thinks its a manpower issue
(I think Paul Davis pointed this out a couple of years ago :). Games
develpment has moved to the point where the graphics work is more
expensive than the software development, and I bet its not far off in
plugin / eyecandy app development. We have no, or almost no, graphics
people here.

There are plenty of graphics people working on Free Software projects, but
they all seem to be working on games projects. What a waste. I guess
drawing goblins is more fun than sliders and LEDs. Who knew? ;)

- Steve
Marek Peteraj
2004-06-08 10:50:36 UTC
Permalink
Post by Steve Harris
Post by Marek Peteraj
VST plugins tend to be rather complex, offering tons of features and
eyecandish GUIs, while LADSPAs usually offer limited functionality, no
GUI at all(hosts usually provide simple ones to control the parameters).
But what's interesting is that each LADSPA plugin usually implements
exactly one type of DSP technique, for example, an oscillator, or a
delay. This basically leads to a situation where a certain DSP technique
is 'isolated' in a separate plugin.
I think thats down to two factors (and its not a good thing)
1) LADSPA developers are few in number and short in time. The basics are a
good place to start.
The number of dsp developers isn't relevant.
Besides - there's at least 5 devs i know of. The number will grow.
Post by Steve Harris
2) The lack of a UI standard makes complex plugins a bit pointless.
Why do you need a UI standard for jack fx/synth clients? Does JAMin
follow one such standard?
You could do a virtually unlimited amount of UIs for exactly 1 fx/synth
using IPC.
Post by Steve Harris
There are a few counter examples (e.g. my VyNil plugin wraps a lot of
different bits), and infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
According to my proposal, this shouldn't happen. :)
Post by Steve Harris
[OT] - my canned plugin writing experience - all generalisations and IMHO
of course
Time breakdown: 10% writing code, 10% maths and optimising, 80% tweaking
and tuning.
See point 6)
Post by Steve Harris
Fewer controls is better.
Doesn't seem like if you look at the most successful
VST(i)/DX(i)/RTAS/TDM/AI plugins :)
Post by Steve Harris
Affordance, appearance and usability has as much affect on the perceived
sound quality as the DSP code (posivly and negativly). Some of this can
be achieved without a custom UI.
Today we've got 100% Affordance, 0% appearance and 0% usability. :)
At least the point that there's no unified affordance since each host
implements it's own, makes the question of usability irrelevant.
Post by Steve Harris
You mentioned JAMin - true that does use LADSPA plugins - but of the total
ammount of code the LADSPA plugins are a tiny fraction. I just reused them
because I hate fixing bugs in two places :)
And? :)
Points 5) and 6)

Marek
Steve Harris
2004-06-08 09:17:23 UTC
Permalink
I wasn't particularly disagreeing with your proposal BTW, I was just
rambling on my pet topic :)
Post by Marek Peteraj
Post by Steve Harris
I think thats down to two factors (and its not a good thing)
1) LADSPA developers are few in number and short in time. The basics are a
good place to start.
The number of dsp developers isn't relevant.
Besides - there's at least 5 devs i know of. The number will grow.
It is relevent, the point is that the development efort going into plugins
is dispraportioanlyl small compared to the apps. This means that the few
of us wh oare coding plugins start with fairly basic things, as there
needed most.
Post by Marek Peteraj
Post by Steve Harris
2) The lack of a UI standard makes complex plugins a bit pointless.
Why do you need a UI standard for jack fx/synth clients? Does JAMin
follow one such standard?
You could do a virtually unlimited amount of UIs for exactly 1 fx/synth
using IPC.
JAMin is not a plugin. Its an app.
Post by Marek Peteraj
Post by Steve Harris
There are a few counter examples (e.g. my VyNil plugin wraps a lot of
different bits), and infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
According to my proposal, this shouldn't happen. :)
Ah, but its a good thing :)
Post by Marek Peteraj
Post by Steve Harris
Fewer controls is better.
Doesn't seem like if you look at the most successful
VST(i)/DX(i)/RTAS/TDM/AI plugins :)
They have fewer controls than they could have. Also, with custom UIs its easier
to get away with more as some can be hidden in an "advanced" popout or
whatever.
Post by Marek Peteraj
Post by Steve Harris
Affordance, appearance and usability has as much affect on the perceived
sound quality as the DSP code (posivly and negativly). Some of this can
be achieved without a custom UI.
Today we've got 100% Affordance, 0% appearance and 0% usability. :)
At least the point that there's no unified affordance since each host
implements it's own, makes the question of usability irrelevant.
I Disagree. We have 0% affordance, 0% appearance, 100% usability (not that
there really orthoganal). You cant have affordance if you dont have
control over appearance and layout.

On topic though - there are some advantages to the way plugins interact
with apps - as thier hosted thier execution order and control binding can
be controlled by apps. This is very useful.

Look at DSSI, which is an attempt to move some of the kind of things from
th JACK model into the LADSPA model, fine control over the routing is
quite important.

- Steve

- Steve
Marek Peteraj
2004-06-08 11:52:02 UTC
Permalink
Post by Steve Harris
I wasn't particularly disagreeing with your proposal BTW, I was just
rambling on my pet topic :)
NP, just trying to make you completely agree :)
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
I think thats down to two factors (and its not a good thing)
1) LADSPA developers are few in number and short in time. The basics are a
good place to start.
The number of dsp developers isn't relevant.
Besides - there's at least 5 devs i know of. The number will grow.
It is relevent, the point is that the development efort going into plugins
is dispraportioanlyl small compared to the apps. This means that the few
of us wh oare coding plugins start with fairly basic things, as there
needed most.
True and as i'm trying to point out, basic things is all we need in
terms of DSP. You're more looking at the history of LADSPA development,
how the whole concept evolved. But i think this could really be
irrelevant for the future development of linux audio fx and synths.
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
2) The lack of a UI standard makes complex plugins a bit pointless.
Why do you need a UI standard for jack fx/synth clients? Does JAMin
follow one such standard?
You could do a virtually unlimited amount of UIs for exactly 1 fx/synth
using IPC.
JAMin is not a plugin. Its an app.
Think about it.
A typical fx plugin takes audio as input does DSProcessing to the audio
and outputs that. What does JAMin do?
The whole purpose of JAMin is to do DSP. And if you make a send in
ardour... :)
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
There are a few counter examples (e.g. my VyNil plugin wraps a lot of
different bits), and infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
According to my proposal, this shouldn't happen. :)
Ah, but its a good thing :)
JAMin is a good thing :)
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
Fewer controls is better.
Doesn't seem like if you look at the most successful
VST(i)/DX(i)/RTAS/TDM/AI plugins :)
They have fewer controls than they could have. Also, with custom UIs its easier
to get away with more as some can be hidden in an "advanced" popout or
whatever.
They have a lot of controls usually. The point in having lots of
controls in a dedicated plugin is that you don't have to setup a dozen
of ladspas in a mixer strip, care about their number of i/os and reorder
them in order to achieve what you want.
Try to reproduce JAMin in one ardour mixer strip(yeah, that tiny black
insert window) with the corresponding ladspas.
The lesser controls you'll have the more plugins you'll be forced to
use.
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
Affordance, appearance and usability has as much affect on the perceived
sound quality as the DSP code (posivly and negativly). Some of this can
be achieved without a custom UI.
Today we've got 100% Affordance, 0% appearance and 0% usability. :)
At least the point that there's no unified affordance since each host
implements it's own, makes the question of usability irrelevant.
I Disagree. We have 0% affordance, 0% appearance, 100% usability (not that
there really orthoganal). You cant have affordance if you dont have
control over appearance and layout.
Usability - as each host provides it's own UI for the same plugins,
there's really no usability at all. The true beauty about VSTs is that
they have the same visual appearance no matter which application you're
using. That's rule #1 for having usability at all. And then there's the
question of smaller usability issues, this varies from VST plugin to VST
plugin.

Marek
Steve Harris
2004-06-08 10:11:58 UTC
Permalink
Post by Marek Peteraj
Post by Steve Harris
JAMin is not a plugin. Its an app.
Think about it.
A typical fx plugin takes audio as input does DSProcessing to the audio
and outputs that. What does JAMin do?
The whole purpose of JAMin is to do DSP. And if you make a send in
ardour... :)
The point I didnt make is that JAMin /cannot/ be implemented efficiently
as a set of plugins. The (majority, non-ladspa) DSP code is very
intermingled, to make it run in realtime. You could argue that its just a
bad example, but I dont think thats the case.
Post by Marek Peteraj
Post by Steve Harris
I Disagree. We have 0% affordance, 0% appearance, 100% usability (not that
there really orthoganal). You cant have affordance if you dont have
control over appearance and layout.
Usability - as each host provides it's own UI for the same plugins,
there's really no usability at all. The true beauty about VSTs is that
they have the same visual appearance no matter which application you're
using. That's rule #1 for having usability at all. And then there's the
question of smaller usability issues, this varies from VST plugin to VST
plugin.
Usability is a very broad term, some things, like not glitching when you
move a control or making each control have an (apparently) linear and
a definable effect on the sound, are also usability features. Those are
got by correctly mapping the user-facing controls to the underlying DSP
parameters. Usually in a very non-obvious way, but they have no bearing on
the appearance.

Though I do think appearance is important.

- Steve
Marek Peteraj
2004-06-08 14:24:05 UTC
Permalink
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
JAMin is not a plugin. Its an app.
Think about it.
A typical fx plugin takes audio as input does DSProcessing to the audio
and outputs that. What does JAMin do?
The whole purpose of JAMin is to do DSP. And if you make a send in
ardour... :)
The point I didnt make is that JAMin /cannot/ be implemented efficiently
as a set of plugins. The (majority, non-ladspa) DSP code is very
intermingled, to make it run in realtime.
How much DSP code is non-ladspa in JAMin? (approx. in %-age?)

Marek
Steve Harris
2004-06-08 13:43:48 UTC
Permalink
Post by Marek Peteraj
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
JAMin is not a plugin. Its an app.
Think about it.
A typical fx plugin takes audio as input does DSProcessing to the audio
and outputs that. What does JAMin do?
The whole purpose of JAMin is to do DSP. And if you make a send in
ardour... :)
The point I didnt make is that JAMin /cannot/ be implemented efficiently
as a set of plugins. The (majority, non-ladspa) DSP code is very
intermingled, to make it run in realtime.
How much DSP code is non-ladspa in JAMin? (approx. in %-age?)
90%

The non-ladspa DSP code is 3800 lines (not inc. libraries), the LADSPA code
(including preamble, not libraries) is < 400.

- Steve
Marek Peteraj
2004-06-08 18:40:54 UTC
Permalink
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
JAMin is not a plugin. Its an app.
Think about it.
A typical fx plugin takes audio as input does DSProcessing to the audio
and outputs that. What does JAMin do?
The whole purpose of JAMin is to do DSP. And if you make a send in
ardour... :)
The point I didnt make is that JAMin /cannot/ be implemented efficiently
as a set of plugins. The (majority, non-ladspa) DSP code is very
intermingled, to make it run in realtime.
How much DSP code is non-ladspa in JAMin? (approx. in %-age?)
90%
The non-ladspa DSP code is 3800 lines (not inc. libraries), the LADSPA code
(including preamble, not libraries) is < 400.
Which part of that DSP code would be impossible to implement separately
as ladspa?

Marek
Steve Harris
2004-06-08 16:41:27 UTC
Permalink
Post by Marek Peteraj
Post by Steve Harris
Post by Marek Peteraj
Post by Steve Harris
The point I didnt make is that JAMin /cannot/ be implemented efficiently
as a set of plugins. The (majority, non-ladspa) DSP code is very
intermingled, to make it run in realtime.
How much DSP code is non-ladspa in JAMin? (approx. in %-age?)
90%
The non-ladspa DSP code is 3800 lines (not inc. libraries), the LADSPA code
(including preamble, not libraries) is < 400.
Which part of that DSP code would be impossible to implement separately
as ladspa?
Not impossible, just not efficiently. The EQ, xover and metering is all
combined together as they share a lot of internal (non time domain) data.
LADSPA can only input and output time domain audio data and control data.
Neither is appropraite, so you would have to do a lot of (expensive and
high latnecy) conversions before the inputs and outputs of each plugin.

- Steve
Frank Barknecht
2004-06-08 10:51:49 UTC
Permalink
Hallo,
Post by Marek Peteraj
Usability - as each host provides it's own UI for the same plugins,
there's really no usability at all. The true beauty about VSTs is that
they have the same visual appearance no matter which application you're
using. That's rule #1 for having usability at all.
I disagree. I really hate probably 95 percent of the VST GUIs I saw on
screenshots. If I was forced to use on of those eye-candy,
hardware-lookalike, un-ergonomic interfaces for LA-DSP-A plugins, I
would probably stop using them.

I use LADSPA plugins a lot in Pd, and there I just hide those controls
I don't need (often because they are updated by scripting), and make
those I do need much larger and colorful. Even just having to handle
lots of small applications windows instead of my clean (to me) reduced
Pd GUI (like Loading Image...) would really annoy
me. So votes-- for GUI Ladspa. ;)

Ciao
--
Frank Barknecht _ ______footils.org__
Marek Peteraj
2004-06-08 14:24:03 UTC
Permalink
Post by Frank Barknecht
Hallo,
Post by Marek Peteraj
Usability - as each host provides it's own UI for the same plugins,
there's really no usability at all. The true beauty about VSTs is that
they have the same visual appearance no matter which application you're
using. That's rule #1 for having usability at all.
I disagree. I really hate probably 95 percent of the VST GUIs I saw on
screenshots.
Judging from the current situation of the audio market that includes
proprietary app/plugins, the popularity thereof, from the numerous
reviews i've seen and from the numerous forum threads i've read...

You're representing a very small minority :)

Marek
Frank Barknecht
2004-06-08 15:50:42 UTC
Permalink
Hallo,
Post by Marek Peteraj
Judging from the current situation of the audio market that includes
proprietary app/plugins, the popularity thereof, from the numerous
reviews i've seen and from the numerous forum threads i've read...
You're representing a very small minority :)
True, my taste is special, but it's also, because people working with
Pd, Max/MSP, Supercollider or similar tools have everything they need
in those apps, thus in general they don't need to hunt down new hip
applications, which often are only doing a single task, in magazines.

But I intended to point out two other things:

* First is, that usability has nothing to do with nice looks. I
truely believe - and given some research time, I'm sure I could prove
it as well - that photorealistic graphical user interfaces modelled
after hardware when shown on a screen are far from usability. Other
people will probably want just that: photo-GUIs. I fear, looking at
the commercial audio market, that exactly these might happen in the
Linux Sound world: eye candy, but bad usability.

* and then I'd like to add, that usabilty in the Linux world comes
from customizabilty, which is mostly absent in the Windows world. The
Unix philosphy is built upon small (or specific) tools that can be
combined in various, *custom* ways and that can be used to let the
computer appear in a way, the user wants, not the other way around.

LADSPA combined with Jack is of course a good example of this
philosophy. Look e.g. at Jackrack: it does provide a consistent GUI
for LADSPA plugins, that you could use just fine with every other
jack-enabled application, and one will get a very usable and
consistent interface. And that even without Steve wasting his precious
time writing GUI code. ;)

Ciao
--
Frank Barknecht _ ______footils.org__
Steve Harris
2004-06-08 16:31:40 UTC
Permalink
Post by Frank Barknecht
* First is, that usability has nothing to do with nice looks. I
truely believe - and given some research time, I'm sure I could prove
it as well - that photorealistic graphical user interfaces modelled
after hardware when shown on a screen are far from usability. Other
people will probably want just that: photo-GUIs. I fear, looking at
the commercial audio market, that exactly these might happen in the
Linux Sound world: eye candy, but bad usability.
Theres two seperate points there:

"...that usability has nothing to do with nice looks"

Hmm, maybe, depends how you define 'nice'. nice != photorealsitic in my
book. I think ableton live is 'nice', and it has a very useable UI - an
equivlanet built with stock GTK/Qt slider widgets would be nowhere near as
usable, IMHO.

and "...I truely believe - and given some research time, I'm sure I could
prove it as well - that photorealistic graphical user interfaces modelled
after hardware when shown on a screen are far from usability..."

That I agree with, with a very small number of exceptions.
Post by Frank Barknecht
LADSPA combined with Jack is of course a good example of this
philosophy. Look e.g. at Jackrack: it does provide a consistent GUI
for LADSPA plugins, that you could use just fine with every other
jack-enabled application, and one will get a very usable and
consistent interface. And that even without Steve wasting his precious
time writing GUI code. ;)
Thats true (and I have no intention of wasting my time writing GUI code
:). But, there are plugins that could be better with *appropriate* UIs, it
doesnt take much, but I think it can make a huge difference - e.g.
superlooper. There are also plugins that aren't being written, becuase
they would just be unusable.

- Steve
Frank Barknecht
2004-06-08 17:53:43 UTC
Permalink
Hallo,
Post by Steve Harris
"...that usability has nothing to do with nice looks"
Hmm, maybe, depends how you define 'nice'. nice != photorealsitic in my
book. I think ableton live is 'nice', and it has a very useable UI - an
equivlanet built with stock GTK/Qt slider widgets would be nowhere near as
usable, IMHO.
Okay, "nice" was much too general. But I'm glad you brought Live up.
Live is actually a really usable and innovative GUI, because it does
*not* try to model hardware at all. This is a GUI that obviously was
intended and designed to be used on the screen of a computer. Ableton
did a great job here, but they were also taking quite a risk with
doing so. When Live wasn't as widely know as it is now, "business"
people were telling Ableton: "You'll never sell that. It looks too
flat."

What I meant with "nice" is more in the vein of this here:
Loading Image...

I mean, it looks like a nice piece of hardware, but what good is that
on screen. You don't even know which button is more important that
others. And why are there srews? And Reason gets especially terrible
if you look at the moving cables on the back. Ah well, I could go on
for hours on how terrible I think this is... ;)

Ciao
--
Frank Barknecht _ ______footils.org__
t***@gmx.de
2004-06-09 06:53:43 UTC
Permalink
Post by Frank Barknecht
Hallo,
http://www.propellerheads.se/products/reason/img/closeup/redrum/closeup-redrum450.jpg
I mean, it looks like a nice piece of hardware, but what good is that
on screen. You don't even know which button is more important that
others. And why are there srews? And Reason gets especially terrible
if you look at the moving cables on the back. Ah well, I could go on
for hours on how terrible I think this is... ;)
the moving cables are quite distracting.
but you can right click on every jack and connect it to another jack via
the menu. and you can see the connections in the menu too.

reason also does a very good job at connecting everything for you.
this is of course only possible, because the reason building blocks are
really big. how should pd know how you wanted to have your objects
connected ?

i consider the eyecandy RACK part of reason only for playing (fooling)
around with the effects. so that you get to know them.

you can rightclick on every control, and add a control track to the
sequencer.

and that is what makes reason a nice tool. the sequencer is integrated
with the rack part.

imagine you got muse sequencing pd and you can add a control track to
muse with one mouse click on a pd control. (not to mention, that you can
record automation from pd to muses control track)

this is why i am still tempted to implement a full sequencer into galan
someday. But it would be much better to define some API to make this
possible in the UNIX way.

if reason had a schematic behind the rack i would be quite happy with
it. (well should run under linux and be jackified :)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Robert Jonsson
2004-06-09 07:50:38 UTC
Permalink
Post by t***@gmx.de
Post by Frank Barknecht
Hallo,
http://www.propellerheads.se/products/reason/img/closeup/redrum/closeup-r
edrum450.jpg
I mean, it looks like a nice piece of hardware, but what good is that
on screen. You don't even know which button is more important that
others. And why are there srews? And Reason gets especially terrible
if you look at the moving cables on the back. Ah well, I could go on
for hours on how terrible I think this is... ;)
the moving cables are quite distracting.
but you can right click on every jack and connect it to another jack via
the menu. and you can see the connections in the menu too.
reason also does a very good job at connecting everything for you.
this is of course only possible, because the reason building blocks are
really big. how should pd know how you wanted to have your objects
connected ?
i consider the eyecandy RACK part of reason only for playing (fooling)
around with the effects. so that you get to know them.
you can rightclick on every control, and add a control track to the
sequencer.
and that is what makes reason a nice tool. the sequencer is integrated
with the rack part.
imagine you got muse sequencing pd and you can add a control track to
muse with one mouse click on a pd control. (not to mention, that you can
record automation from pd to muses control track)
Hey! That's a nice idea. Don't patent it ;)
Post by t***@gmx.de
this is why i am still tempted to implement a full sequencer into galan
someday. But it would be much better to define some API to make this
possible in the UNIX way.
That would be the way to go. I have to give this some thought...

/Robert
Post by t***@gmx.de
if reason had a schematic behind the rack i would be quite happy with
it. (well should run under linux and be jackified :)
--
http://spamatica.se/music/
Marek Peteraj
2004-06-08 18:55:16 UTC
Permalink
Post by Frank Barknecht
Hallo,
Post by Marek Peteraj
Judging from the current situation of the audio market that includes
proprietary app/plugins, the popularity thereof, from the numerous
reviews i've seen and from the numerous forum threads i've read...
You're representing a very small minority :)
True, my taste is special, but it's also, because people working with
Pd, Max/MSP, Supercollider or similar tools have everything they need
in those apps, thus in general they don't need to hunt down new hip
applications, which often are only doing a single task, in magazines.
* First is, that usability has nothing to do with nice looks.
Wrong. :)
Post by Frank Barknecht
I
truely believe - and given some research time, I'm sure I could prove
it as well - that photorealistic graphical user interfaces modelled
after hardware when shown on a screen are far from usability.
It all depends on how you perceive different controls (different knobs
in different sections etc) and how you learn ot perceive them, i.e. how
you get to know them and how you get used to them.

Second thing is that the way you percieve them shouldn't change as you
switch applications. Which is what VST perfectly fulfills - it provides
its own UI.

Virtual 3d guis copy the real world. Try to do it the other way around,
with widget sliders and one color for both sliders and background(most
cases). Imagine a hw which would look like that.

Another such case is animations in UI. They improve usability aswell.
If carefully adjusted, they help to prevent sudden changes in the UI.
Animations are not just eye-candy.
Post by Frank Barknecht
Other
people will probably want just that: photo-GUIs.
Because they're easier to learn and get used to.
Post by Frank Barknecht
I fear, looking at
the commercial audio market, that exactly these might happen in the
Linux Sound world: eye candy, but bad usability.
What you probably prefer is modularity rather than usability. It's what
the term usability means for you.
Post by Frank Barknecht
* and then I'd like to add, that usabilty in the Linux world comes
from customizabilty,
Usability != modularity. See the Gnome HiG for examples.

Marek
Paul Winkler
2004-06-08 17:40:40 UTC
Permalink
Post by Marek Peteraj
Virtual 3d guis copy the real world. Try to do it the other way around,
with widget sliders and one color for both sliders and background(most
cases). Imagine a hw which would look like that.
I agree with your point here. I used to have a Yamaha four-track
that had nothing but black sliders (no knobs) on a black background.
It was horrible to use - there was no visual or tactile
distinction
Post by Marek Peteraj
Post by Frank Barknecht
Other
people will probably want just that: photo-GUIs.
Because they're easier to learn and get used to.
Initially, sure; they look familiar.

But I don't believe you can simply imitate hardware and get a good UI without
thinking critically about each widget. A lot is lost in the
translation. Remember that hardware still offers vastly better visual
resolution, tactile feedback (e.g. potentiometer detents, switch clicks),
more physical space (even a lowly Mackie 1604 mixer doesn't fit on a single
display at actual size), and a much lower impedance to physical control
(compare moving a physical slider to clicking and dragging an onscreen slider
via a mouse; also, you have two hands and can use them easily at once,
but you only get one mouse.)

Even when a photo-GUI approach is chosen, there's no need to take it
to extremes. Think of Reason. You flip the "rack" around to look at
the connecting "cables" and they show you fans, screws, fuse holders...
goofy.
--
Paul Winkler
http://www.slinkp.com
Frank Barknecht
2004-06-08 18:12:07 UTC
Permalink
Hallo,
Post by Marek Peteraj
Second thing is that the way you percieve them shouldn't change as you
switch applications. Which is what VST perfectly fulfills - it provides
its own UI.
True somehow but then also not: If I don't like a UI I'd like to be
able to change it. That's something valueable that VST doesn't allow
you to do - or makes it harder. Usablity also has to do with what
people ae used to. I think, Emacs is not useable, Emacs users think,
Vim is not. But actually both are useable, just not if you're used to
something else.
Post by Marek Peteraj
Virtual 3d guis copy the real world. Try to do it the other way
around, with widget sliders and one color for both sliders and
background(most cases). Imagine a hw which would look like that.
I'm not at all against GUIs and colors. I'm only against drop shadows
(most of the time) and screws and fans (always). ;)
Post by Marek Peteraj
Other people will probably want just that: photo-GUIs.
Because they're easier to learn and get used to.
I never have used a hardware synth. Why should I first learn to
understand hardware when I only want to use software? Imagine if Word
would show a rendered, animated image of an old fashioned typewriter
with paper extending from it as its interface. It's really strange
that audio software makers can get away with this kind of GUI design
approach.

It's okay and useful to use metaphors that are common in music
production. You see this everywhere. Ardour does this with its mixing
desk. But in Ardour this is just a metaphor, not a copy.

But then, even the GUI gurus at Apple were forced to show a
photorealistic hard disk on the OS-X desktop. Why they did, fails
me...
Post by Marek Peteraj
I fear, looking at the commercial audio market, that exactly these
might happen in the Linux Sound world: eye candy, but bad
usability.
What you probably prefer is modularity rather than usability. It's
what the term usability means for you.
Well, I also want modularity, but here I'm really talking about
customizability. Maybe an ideal GUI would not need that - which I
doubt. But I'm talking about things like making it easy or possible to
allow me to customize my workspace. If someone clones Reason and
inserts fans and screws, I'd like to be able to hide them or to use
another GUI.

Ciao
--
Frank Barknecht _ ______footils.org__
martin rumori
2004-06-08 18:45:45 UTC
Permalink
Post by Frank Barknecht
But then, even the GUI gurus at Apple were forced to show a
photorealistic hard disk on the OS-X desktop. Why they did, fails
me...
surprisingly, each single partition is shown with a photorealistic
hard disk. surprisingly, if you open the cover of a mac after
partitioning it's really divided into several disks :-)

martin
Lee Revell
2004-06-08 18:51:19 UTC
Permalink
Post by Frank Barknecht
Hallo,
Post by Marek Peteraj
Second thing is that the way you percieve them shouldn't change as you
switch applications. Which is what VST perfectly fulfills - it provides
its own UI.
True somehow but then also not: If I don't like a UI I'd like to be
able to change it. That's something valueable that VST doesn't allow
you to do - or makes it harder.
VST certainly does allow this. When using VST plugins in Ableton Live,
the default interface is Live's widgets, but then you click on the
wrench (or whatever its supposed to be) and it opens up the VST plugin's
native GUI. I am not sure how hard this was for them to do of course,
but it works, brilliantly. This is really the only way to go, provide a
default but allow it to be overridden.

Lee
Frank Barknecht
2004-06-09 00:38:04 UTC
Permalink
Hallo,
Post by Lee Revell
Post by Frank Barknecht
True somehow but then also not: If I don't like a UI I'd like to be
able to change it. That's something valueable that VST doesn't allow
you to do - or makes it harder.
VST certainly does allow this. When using VST plugins in Ableton Live,
the default interface is Live's widgets, but then you click on the
wrench (or whatever its supposed to be) and it opens up the VST plugin's
native GUI.
You got me when I was cheating. ;) Actually I found out it's the same
in VST for Pd (on Win, but also using vstserver): You can still
control the plugin through Pd's internal messages and the actual GUI
only shows when you tell it to do so. So yes, my argument wasn't
fully valid, sorry.

So maybe it's like this: eye-candy GUI is fine, but please do also
allow some kind of textual control using maybe D-Bus, which I don't
know, or maybe OSC, which already is common and accepted in the music
world, or something else.

Ciao
--
Frank Barknecht _ ______footils.org__
Steve Harris
2004-06-09 09:13:18 UTC
Permalink
Post by Frank Barknecht
Hallo,
Post by Lee Revell
Post by Frank Barknecht
True somehow but then also not: If I don't like a UI I'd like to be
able to change it. That's something valueable that VST doesn't allow
you to do - or makes it harder.
VST certainly does allow this. When using VST plugins in Ableton Live,
the default interface is Live's widgets, but then you click on the
wrench (or whatever its supposed to be) and it opens up the VST plugin's
native GUI.
You got me when I was cheating. ;) Actually I found out it's the same
in VST for Pd (on Win, but also using vstserver): You can still
control the plugin through Pd's internal messages and the actual GUI
only shows when you tell it to do so. So yes, my argument wasn't
fully valid, sorry.
Actually it was - you can have 1 cutom UI that will work in any host, and
any number of generic, host specific UIs.

If the user wants to build thier own (curses for e.g.) UI to work in
all hosts, theyre screwed.

- Steve
t***@gmx.de
2004-06-09 07:02:59 UTC
Permalink
Post by Lee Revell
Post by Frank Barknecht
Hallo,
Post by Marek Peteraj
Second thing is that the way you percieve them shouldn't change as you
switch applications. Which is what VST perfectly fulfills - it provides
its own UI.
True somehow but then also not: If I don't like a UI I'd like to be
able to change it. That's something valueable that VST doesn't allow
you to do - or makes it harder.
VST certainly does allow this. When using VST plugins in Ableton Live,
the default interface is Live's widgets, but then you click on the
wrench (or whatever its supposed to be) and it opens up the VST plugin's
native GUI. I am not sure how hard this was for them to do of course,
but it works, brilliantly. This is really the only way to go, provide a
default but allow it to be overridden.
if i try out a new VST plug i open its GUI. with the GUI i get a nice
and compact look of all its controls.
If i want to use the plugin i resort to rebuilding the GUI with galan
controls (they have better functionality).

its all there and its your choice.
but there are of course several vst plugins, where you need the GUI,
because the controls cant be mapped to knobs or sliders.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Robert Jonsson
2004-06-09 07:44:49 UTC
Permalink
Post by t***@gmx.de
if i try out a new VST plug i open its GUI. with the GUI i get a nice
and compact look of all its controls.
If i want to use the plugin i resort to rebuilding the GUI with galan
controls (they have better functionality).
its all there and its your choice.
but there are of course several vst plugins, where you need the GUI,
because the controls cant be mapped to knobs or sliders.
Is there really? This would make automation impossible.

/Robert
--
http://spamatica.se/music/
Steve Harris
2004-06-09 09:16:00 UTC
Permalink
Post by Robert Jonsson
Post by t***@gmx.de
if i try out a new VST plug i open its GUI. with the GUI i get a nice
and compact look of all its controls.
If i want to use the plugin i resort to rebuilding the GUI with galan
controls (they have better functionality).
its all there and its your choice.
but there are of course several vst plugins, where you need the GUI,
because the controls cant be mapped to knobs or sliders.
Is there really? This would make automation impossible.
Automation in VST is pretty much broken AFAICT. It relys on explicit
support from the plugins to work.

- Steve
t***@gmx.de
2004-06-09 06:57:54 UTC
Permalink
Post by Frank Barknecht
But then, even the GUI gurus at Apple were forced to show a
photorealistic hard disk on the OS-X desktop. Why they did, fails
me...
has the avarage mac user ever seen a HardDisk ? :))
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Jens M Andreasen
2004-06-09 07:31:34 UTC
Permalink
Post by Frank Barknecht
But then, even the GUI gurus at Apple were forced to show a
photorealistic hard disk on the OS-X desktop. Why they did, fails
me...
... and it is even weirder when you consider that most Apple consumers
never open their boxes and have no idea what it looks like inside.

/jens :)
Steve Harris
2004-06-09 09:10:43 UTC
Permalink
Post by Frank Barknecht
Hallo,
Post by Marek Peteraj
Second thing is that the way you percieve them shouldn't change as you
switch applications. Which is what VST perfectly fulfills - it provides
its own UI.
True somehow but then also not: If I don't like a UI I'd like to be
able to change it. That's something valueable that VST doesn't allow
you to do - or makes it harder. Usablity also has to do with what
people ae used to. I think, Emacs is not useable, Emacs users think,
Vim is not. But actually both are useable, just not if you're used to
something else.
FWIW the DSSI UI protocol allows this. I wouldn't really consider a
hardcoded UI system sane if it didn't allow users to replace the UI.

The UI is just an executable on disk that is run when the host wants the
open hte UI for the first time - it could eg. be a scrit that spawns Pd and
then uses a Pdpatch to control the host via OS ;)

- Steve
Steve Harris
2004-06-09 09:17:01 UTC
Permalink
Post by Steve Harris
open hte UI for the first time - it could eg. be a scrit that spawns Pd and
then uses a Pdpatch to control the host via OS ;)
OSC of course.
Jos Laake
2004-06-08 19:16:16 UTC
Permalink
Just some thoughts...

As one who tends to use more than build these things, I can see the
pros and cons of the photorealistic GUI. For one thing, if it's
simulating a piece of equipment I once used (many years ago ;-) )
having the GUI mirror the original HW device makes a lot of sense
because I immediately remember how to run it. All my favourite
settings all "patch in" quite naturally. I like that. I can't
imagine trying to run a Mini-Moog plug in that didn't look like
one.

Having said that, I used to play my Moog with the knobs as well,
not just the keyboard. That wouldn't be very easy to do with the
GUI.

I also like the argument for knobs when you use them for settings
not going to change them much once they're set, so useability isn't
as big of an issue. Sliders aren't nearly as practical for this job.

On the other hand, I like being able to change the look of something
once I've gotten the feel of it, ala "skins". Like having the full
screen version with all the knobs and sliders and blinky lights, but
be able to minimize the effect to tiny primary controls once I have
it set up the way I want.

I know, I know, I don't ask for much. ;-) And I don't do GUI's
either. Actually, I've done so much deep level real-time systems
coding in the last 20 years, I'm very happy to let faster younger
folks have at it so I can spend my time making *MUSIC* which is
kinda my point for being here. All the same, I'm adamant about
supporting GPL solutions in professional digital audio, and the
more we can consense on what works *well enough*for most of us,
the more we move toward useability and interchangability. I'm
not so sure about "affordance" though. ;-)

Okay, there's my $1.27 worth.

Clean tracks for all!
~Jos~
t***@gmx.de
2004-06-09 07:11:07 UTC
Permalink
Post by Jos Laake
Just some thoughts...
As one who tends to use more than build these things, I can see the
pros and cons of the photorealistic GUI. For one thing, if it's
simulating a piece of equipment I once used (many years ago ;-) )
having the GUI mirror the original HW device makes a lot of sense
because I immediately remember how to run it. All my favourite
settings all "patch in" quite naturally. I like that. I can't
imagine trying to run a Mini-Moog plug in that didn't look like
one.
Having said that, I used to play my Moog with the knobs as well,
not just the keyboard. That wouldn't be very easy to do with the
GUI.
I also like the argument for knobs when you use them for settings
not going to change them much once they're set, so useability isn't
as big of an issue. Sliders aren't nearly as practical for this job.
On the other hand, I like being able to change the look of something
once I've gotten the feel of it, ala "skins". Like having the full
screen version with all the knobs and sliders and blinky lights, but
be able to minimize the effect to tiny primary controls once I have
it set up the way I want.
hopefully i will find the time to add this on the fly change to control
panels to galan soon.
should not be that much code. but i am not sure about the UI.
Post by Jos Laake
I know, I know, I don't ask for much. ;-) And I don't do GUI's
well for galan its not THAT much anymore.
Post by Jos Laake
either. Actually, I've done so much deep level real-time systems
coding in the last 20 years, I'm very happy to let faster younger
folks have at it so I can spend my time making *MUSIC* which is
kinda my point for being here. All the same, I'm adamant about
supporting GPL solutions in professional digital audio, and the
more we can consense on what works *well enough*for most of us,
the more we move toward useability and interchangability. I'm
not so sure about "affordance" though. ;-)
Okay, there's my $1.27 worth.
Clean tracks for all!
~Jos~
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Pelle Nilsson
2004-06-09 09:04:09 UTC
Permalink
Post by Marek Peteraj
...
Second thing is that the way you percieve them shouldn't change as you
switch applications. Which is what VST perfectly fulfills - it provides
its own UI.
If I have 100 LADSPA plug-ins installed and 3 LADSPA hosts, I'd rather
spend my time learning the guis of the 3 host-applications than
learning the different guis of 100 plug-ins. That a plug-in then has
three different interfaces depending on in which application I use it
isn't a problem. Also it looks a lot better (imho) when everything in
an application looks exactly the same. Letting plug-ins decide too
much about how they should be rendered is a bad thing. A little more
control than today could be useful at times though.

br /Pelle
Steve Harris
2004-06-09 09:24:22 UTC
Permalink
Post by Pelle Nilsson
If I have 100 LADSPA plug-ins installed and 3 LADSPA hosts, I'd rather
spend my time learning the guis of the 3 host-applications than
learning the different guis of 100 plug-ins. That a plug-in then has
three different interfaces depending on in which application I use it
isn't a problem. Also it looks a lot better (imho) when everything in
an application looks exactly the same. Letting plug-ins decide too
much about how they should be rendered is a bad thing. A little more
control than today could be useful at times though.
Of those 100 plugins I image that only a about 10 or so would want / need
/ justify a custom UI.

...though that does sound worryingly like dangerously inaccurate early
computing predictions. "I predict that within 100 years, computers will
be twice as powerful, 10,000 times larger, and so expensive that only the
five richest kings of Europe will own them" -- Professor John Frink.

- Steve
Jos Laake
2004-06-08 19:38:46 UTC
Permalink
Post by Frank Barknecht
LADSPA combined with Jack is of course a good example of this
philosophy. Look e.g. at Jackrack: it does provide a consistent GUI
for LADSPA plugins, that you could use just fine with every other
jack-enabled application, and one will get a very usable and
consistent interface. And that even without Steve wasting his
precious time writing GUI code. ;)
BTW, Jackrack causes my system to freeze up. Anybody else experiencing
this?

~Jos~
Joost Diepenmaat
2004-06-08 19:51:46 UTC
Permalink
Post by Frank Barknecht
* First is, that usability has nothing to do with nice looks. I
truely believe - and given some research time, I'm sure I could prove
it as well - that photorealistic graphical user interfaces modelled
after hardware when shown on a screen are far from usability.
I couldn't agree more. I like keyboard input (mostly computer keyboard,
not synth.) and I don't need and dont want "realistic" GUIs that
generally waste more space. I want clarity and fast editing.

As an example of a quite popular application on the windows world that
usually keeps away from photorealistic GUIs for plugins, take a look at
Buzz - http://www.buzzmachines.com/ has about 800 plugins, increasing
with a couple a month - and buzz itself hasn't been updated in ages.
Post by Frank Barknecht
* and then I'd like to add, that usabilty in the Linux world comes
from customizabilty, which is mostly absent in the Windows world. The
Unix philosphy is built upon small (or specific) tools that can be
combined in various, *custom* ways and that can be used to let the
computer appear in a way, the user wants, not the other way around.
There is just one problem with this approach; that once you have
seperate apps for different parts of your composition, it's usually a
lot more hassle to set up than a big giant app when you want to work
on it again. I vaguely remember a discussion on this list about an
application or library that was supposed to take care of this issue,
but I can't find it. Does anyone have any pointers?

Cheers,

Joost.
Dave Robillard
2004-06-08 20:42:55 UTC
Permalink
Post by Joost Diepenmaat
There is just one problem with this approach; that once you have
seperate apps for different parts of your composition, it's usually a
lot more hassle to set up than a big giant app when you want to work
on it again. I vaguely remember a discussion on this list about an
application or library that was supposed to take care of this issue,
but I can't find it. Does anyone have any pointers?
Cheers,
Joost.
Yep, that's LADCCA, now renamed LASH (LASH Audio Session Handler).

http://lash-audio-session-handler.org/

-Dave Robillard (who came up with the new name, for the record :] )
Albert Graef
2004-06-08 22:27:14 UTC
Permalink
Post by Dave Robillard
Yep, that's LADCCA, now renamed LASH (LASH Audio Session Handler).
http://lash-audio-session-handler.org/
For me the new page takes ages to load. Anyone else experiencing this?

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
Erik de Castro Lopo
2004-06-08 08:54:32 UTC
Permalink
On Tue, 8 Jun 2004 09:18:58 +0100
Post by Steve Harris
[OOT] I used to think that a UI spec for LADSPA (to make it competetive
with VST) was a technological problem. I now thinks its a manpower issue
(I think Paul Davis pointed this out a couple of years ago :). Games
develpment has moved to the point where the graphics work is more
expensive than the software development, and I bet its not far off in
plugin / eyecandy app development. We have no, or almost no, graphics
people here.
We don't necessarily need eyecandy, but the plain simple sliders provided
by most of the gui toolkits would be MAJORLY useful.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo ***@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
A good debugger is no substitute for a good test suite.
Steve Harris
2004-06-08 09:18:47 UTC
Permalink
Post by Erik de Castro Lopo
On Tue, 8 Jun 2004 09:18:58 +0100
Post by Steve Harris
[OOT] I used to think that a UI spec for LADSPA (to make it competetive
with VST) was a technological problem. I now thinks its a manpower issue
(I think Paul Davis pointed this out a couple of years ago :). Games
develpment has moved to the point where the graphics work is more
expensive than the software development, and I bet its not far off in
plugin / eyecandy app development. We have no, or almost no, graphics
people here.
We don't necessarily need eyecandy, but the plain simple sliders provided
by most of the gui toolkits would be MAJORLY useful.
I agree. I'm not rally fond of the "spinning cow" model of UI design, but
sensible layout and display would help immensly.

- Steve
Marek Peteraj
2004-06-08 11:17:25 UTC
Permalink
Forgot to add...

<snip>
... infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
True that you can't have an ideal isolation of all DSP techniques,
whether simple of complex ones. But still, LADSPAs are simple plugins as
the name itself suggests.

<snip>
You mentioned JAMin - true that does use LADSPA plugins -
<snip>
I just reused them (LADSPA plugins)
because I hate fixing bugs in two places :)
Which is perfect. :)

There are two advantages to this:
1. one ladspa package - get them all -- no need to chase for several
ladspas on the net. It's going to get ugly soon with the increasing
number of dsp devs.
2. 100% reusable -- interesting and attractive DSP stuff doesn't need to
be bound to one application - see glame high/low/band pass filters for
example.
Steve Harris
2004-06-08 09:20:37 UTC
Permalink
Post by Marek Peteraj
Forgot to add...
<snip>
... infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
True that you can't have an ideal isolation of all DSP techniques,
whether simple of complex ones. But still, LADSPAs are simple plugins as
the name itself suggests.
The API is simple, /not/ the plugins!

I think you're tarring all plugins with my brush. In 2000 I was basicly a
DSP novice, so all my early plugins are a bit simplistic.

- Steve
Marek Peteraj
2004-06-08 11:54:58 UTC
Permalink
Post by Steve Harris
Post by Marek Peteraj
Forgot to add...
<snip>
... infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
True that you can't have an ideal isolation of all DSP techniques,
whether simple of complex ones. But still, LADSPAs are simple plugins as
the name itself suggests.
The API is simple, /not/ the plugins!
I think you're tarring all plugins with my brush. In 2000 I was basicly a
DSP novice, so all my early plugins are a bit simplistic.
Fons' Moog HP filter is a complex piece of DSP i suspect.
But it's still a HP filter which is a smaller part of a complex synth,
or a complex fx.

Marek
Fons Adriaensen
2004-06-08 19:15:13 UTC
Permalink
Post by Marek Peteraj
Fons' Moog HP filter is a complex piece of DSP i suspect.
No, it's actually quite simple :-) The most complex one is
the four-band parametric filter I released recently, and
that's also the only one that is not intended as an AMS
plugin. And it will reappear in some time as a JACK
application with it's own GUI, as this permits to do some
things that would be difficult in a plugin.

Just to throw in my 2 eurocents in this debate:

- When I saw the collection of VST plugins that Paul Davis used
to show his VST hosting in Karlsruhe, I asked myself "My god,
do they all look that childish ?". This is just to say I terribly
dislike this eye-candy style, and given the choice between that
and a (maybe boring) set of standard toolkit sliders, I'd prefer
the latter. The ideal is somewhere in between, but certainly not
to the eye-candy side.

- Before everything went digital, multitrack mixing desks had
lots of controls and very little space to put them in. Good
layout was absolutely essential, and most of the big name
manufacturers mastered this quite well. It's done by

- observing elementary aesthetic rules (e.g. color
combinations),
- removing all useless clutter,
- following the logic of the application, e.g. keeping
things that are related together,
- accepting culturally defined standards, such as that
a signal flows from left to right and from top to bottom.
- using hints that are picked up unconsciously, rather
than explicit labeling.

All of this is practically the inverse of eye-candy.

- Confucius says: When you see a piece of audio equipment
with the word "Professional" printed on it, then it probably
isn't.

- The typical VST plugin (talking about the serious ones)
corresponds more to a JACK application than a LADSPA plugin,
not because both have a GUI, but because of the complexity.
This is just a matter of naming. We could start calling a
JACK application a JACK 'plugin' but I'd vote against.
JAMIN is a good example of this.

- As to LADSPA plugins, we could probably give almost all
of them a very functional and nice GUI by defining a set
of a few dozens of 'widget types'. Then there are a few
options:

1. the plugin specifies the dimensions and positions of
all the widgets,

2. the dimensions are standard, and the plugins specifies
the positions only,

3. the host keeps it own database of layouts indexed by
plugin ID.

I'm somehow in favour of 3, if the host's end user has
a simple way to add new plugins to the database.
--
Fons
Chris Cannam
2004-06-08 19:35:13 UTC
Permalink
Post by Fons Adriaensen
- When I saw the collection of VST plugins that Paul Davis used
to show his VST hosting in Karlsruhe, I asked myself "My god,
do they all look that childish ?".
I only saw this by webcam (and 'scuse me if I just digress to say how
much I enjoyed both this and your own presentation Fons) so I'm not
sure which plugins they were, or what they looked like. Anyone able
to name names, have links to screenshots etc?

There are a few VST plugins -- particularly synths -- that have
ridiculous cheesy GUIs that I really like, but there are plenty of
hopeless ones too.


Chris
Marek Peteraj
2004-06-09 08:06:00 UTC
Permalink
Post by Fons Adriaensen
Post by Marek Peteraj
Fons' Moog HP filter is a complex piece of DSP i suspect.
No, it's actually quite simple :-) The most complex one is
the four-band parametric filter I released recently, and
that's also the only one that is not intended as an AMS
plugin. And it will reappear in some time as a JACK
application with it's own GUI, as this permits to do some
things that would be difficult in a plugin.
- When I saw the collection of VST plugins that Paul Davis used
to show his VST hosting in Karlsruhe, I asked myself "My god,
do they all look that childish ?".
Ask win32 and mac users how the linux audio UIs look like :)
Post by Fons Adriaensen
This is just to say I terribly
dislike this eye-candy style, and given the choice between that
and a (maybe boring) set of standard toolkit sliders, I'd prefer
the latter. The ideal is somewhere in between, but certainly not
to the eye-candy side.
- Before everything went digital, multitrack mixing desks had
lots of controls and very little space to put them in. Good
layout was absolutely essential, and most of the big name
manufacturers mastered this quite well. It's done by
- observing elementary aesthetic rules (e.g. color
combinations),
- removing all useless clutter,
thus saving a few bucks.. :)
Post by Fons Adriaensen
- following the logic of the application, e.g. keeping
things that are related together,
- accepting culturally defined standards, such as that
a signal flows from left to right and from top to bottom.
- using hints that are picked up unconsciously, rather
than explicit labeling.
Doesn't influence eye-candy much.
Post by Fons Adriaensen
- The typical VST plugin (talking about the serious ones)
corresponds more to a JACK application than a LADSPA plugin,
not because both have a GUI, but because of the complexity.
This is just a matter of naming. We could start calling a
JACK application a JACK 'plugin' but I'd vote against.
JAMIN is a good example of this.
But if you let JAMin run as the only client, you'll see it makes no
sense, since it needs audio input to be useful.

You guys are developers, but this could get rather confusing for users.

Marek
Steve Harris
2004-06-09 09:34:01 UTC
Permalink
Post by Marek Peteraj
But if you let JAMin run as the only client, you'll see it makes no
sense, since it needs audio input to be useful.
Actually some people do - audio can come from outside PCs ;)

- Steve
Alfons Adriaensen
2004-06-09 09:49:45 UTC
Permalink
Post by Marek Peteraj
Post by Fons Adriaensen
- When I saw the collection of VST plugins that Paul Davis used
to show his VST hosting in Karlsruhe, I asked myself "My god,
do they all look that childish ?".
Ask win32 and mac users how the linux audio UIs look like :)
Whatever they think about linux audio UIs, that will not change
my opinion expressed above.

There are various kinds of users of audio SW; their requirements
and opinions will vary. In my experience, most serious and
professional users prefer a UI that is first of all functional,
with as little clutter as possible, i.e. a UI that is designed
by people who understand how something works and how it is
used, rather than by the marketing department. This type of
user may be a minority, but they are the only ones that really
matter to me - I am neither a politician nor a salesman, and I
have no desire to be popular.

In a more general sense, a majority is not 'right' by itself,
a majority of informed people probably is. And having paid for
something does not qualify someone as informed. In other words,
the consumer is not always right by definition. If he were,
there would be no place for marketing, which has been defined
as 'the art of disturbing rational decision making'.

The audio business is full of hype and irrational behaviour.
Lots of people seem prepared to pay 5 Eur for a meter of
'directional oxygen free left-twisting copper' loudspeaker
cable. Should I take their opinion seriously ? I prefer not to.
Post by Marek Peteraj
Post by Fons Adriaensen
- The typical VST plugin (talking about the serious ones)
corresponds more to a JACK application than a LADSPA plugin,
not because both have a GUI, but because of the complexity.
This is just a matter of naming. We could start calling a
JACK application a JACK 'plugin' but I'd vote against.
JAMIN is a good example of this.
But if you let JAMin run as the only client, you'll see it
makes no sense, since it needs audio input to be useful.
*What* makes no sense ?
Post by Marek Peteraj
You guys are developers, but this could get rather confusing
for users.
When you buy a piece of equipment and put it somewhere in
your studio it doesn't make much sense until you connect it.
Most users *do* understand this.
--
FA
Marek Peteraj
2004-06-09 13:44:53 UTC
Permalink
Post by Alfons Adriaensen
Post by Marek Peteraj
Post by Fons Adriaensen
- When I saw the collection of VST plugins that Paul Davis used
to show his VST hosting in Karlsruhe, I asked myself "My god,
do they all look that childish ?".
Ask win32 and mac users how the linux audio UIs look like :)
Whatever they think about linux audio UIs, that will not change
my opinion expressed above.
It should if you don't do your program just for yourself.
Post by Alfons Adriaensen
There are various kinds of users of audio SW; their requirements
and opinions will vary. In my experience, most serious and
professional users prefer a UI that is first of all functional,
Have you done a survey?
Post by Alfons Adriaensen
with as little clutter as possible, i.e. a UI that is designed
by people who understand how something works and how it is
used, rather than by the marketing department.
It's always done that way. It's because it's *driven* by market demand.
Those people are called usability engineers.
i.e. it is *never* designed by marketing department.
The kind of people that linux still totally lacks in certain areas.

Rule #1: comfort. technologies help to achieve that goal. We have tons
of great technologies, no comfort.

Software companies are not only about developers and sw technologies.
Lots of oss developers tend to think they can do it all. They can't.

Marek
Dave Griffiths
2004-06-09 12:05:24 UTC
Permalink
Post by Marek Peteraj
Post by Alfons Adriaensen
There are various kinds of users of audio SW; their requirements
and opinions will vary. In my experience, most serious and
professional users prefer a UI that is first of all functional,
Have you done a survey?
Most music software written for profit is now aimed at rich bedroom techno
making kids - hence all the flashy GUI's. Professional software (that costs
much much more) will often have much simpler, clean interfaces because if you
use it all day every day gimmicky GUI's tend to get very annoying very fast.

cheers,

dave
Marek Peteraj
2004-06-09 14:42:32 UTC
Permalink
Post by Dave Griffiths
Post by Marek Peteraj
Post by Alfons Adriaensen
There are various kinds of users of audio SW; their requirements
and opinions will vary. In my experience, most serious and
professional users prefer a UI that is first of all functional,
Have you done a survey?
Most music software written for profit is now aimed at rich bedroom techno
making kids - hence all the flashy GUI's. Professional software (that costs
much much more) will often have much simpler, clean interfaces because if you
use it all day every day gimmicky GUI's tend to get very annoying very fast.
Really?

I can give you a perfect example - a *reference* DAW system - ProTools.
Which, in ver. 6, has gone eye-candy.
Guess why.

Another fine example - serious professionals using Mac, with macosx.
Pure eyecandy.

Marek

Steve Harris
2004-06-09 09:32:00 UTC
Permalink
Post by Fons Adriaensen
No, it's actually quite simple :-) The most complex one is
the four-band parametric filter I released recently, and
that's also the only one that is not intended as an AMS
plugin. And it will reappear in some time as a JACK
application with it's own GUI, as this permits to do some
things that would be difficult in a plugin.
While having it as a jack app would certianly be good, I think it would
also be useful to have it still as a plugin but with a custom UI. Not that
that's possible right now.

- Steve
Uwe Koloska
2004-06-08 09:54:31 UTC
Permalink
Post by Steve Harris
[OT] - my canned plugin writing experience - all generalisations
and IMHO of course
Affordance, appearance and usability has as much affect on the
perceived sound quality as the DSP code (posivly and negativly).
Some of this can be achieved without a custom UI.
Sorry for my ignorance -- but is there someone who can present me
the german term for "affordance"? The web-dicts I searched, don't
know this word -- and the wikipedia entry doesn't give me any clue
about the german word (though I understand the concept).

Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
Jan Depner
2004-06-08 21:11:54 UTC
Permalink
Post by Uwe Koloska
Post by Steve Harris
[OT] - my canned plugin writing experience - all generalisations
and IMHO of course
Affordance, appearance and usability has as much affect on the
perceived sound quality as the DSP code (posivly and negativly).
Some of this can be achieved without a custom UI.
Sorry for my ignorance -- but is there someone who can present me
the german term for "affordance"? The web-dicts I searched, don't
know this word -- and the wikipedia entry doesn't give me any clue
about the german word (though I understand the concept).
The problem is that it's not a word. Your understanding of it is
probably the best definition there is ;-)

Jan
Steve Harris
2004-06-09 09:37:41 UTC
Permalink
Post by Jan Depner
Post by Uwe Koloska
Sorry for my ignorance -- but is there someone who can present me
the german term for "affordance"? The web-dicts I searched, don't
know this word -- and the wikipedia entry doesn't give me any clue
about the german word (though I understand the concept).
The problem is that it's not a word. Your understanding of it is
probably the best definition there is ;-)
I have to disagree with this - it may not be a german word, but it
certainly is an English one - its been in consistant use in scientific
literature for ~30 years.

(UK) English is defined by usage - not a canonical dictionary, so it is a
word.

- Steve
CK
2004-06-08 10:31:51 UTC
Permalink
Post by Uwe Koloska
Sorry for my ignorance -- but is there someone who can present me
the german term for "affordance"? The web-dicts I searched, don't
know this word -- and the wikipedia entry doesn't give me any clue
about the german word (though I understand the concept).
It's "Affordanz", a psychological term see:
http://www.wissenschaft-online.de/abo/lexikon/psycho/320

regards,

x
--
***@lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
Uwe Koloska
2004-06-08 12:16:58 UTC
Permalink
Post by CK
http://www.wissenschaft-online.de/abo/lexikon/psycho/320
Aaah! Thank you.
This also explains, why this artword isn't found in any dictionary.

Another little piece in the neverending quest for knowlegde ;-)

Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
Steve Harris
2004-06-08 13:36:12 UTC
Permalink
Post by Uwe Koloska
Post by CK
http://www.wissenschaft-online.de/abo/lexikon/psycho/320
Aaah! Thank you.
This also explains, why this artword isn't found in any dictionary.
Its in FOLDoc and Wikipedia: (first two I tried)
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=affordance&action=Search
http://en.wikipedia.org/wiki/Affordance

Its also in Hyperdictionary and the Computer Dictionary and a google would
have found you a defintion in the top hit. It is however not in the OED
(arguably the nearest thing to a authorative dictionary in English), it's
a production from the verb 'afford'.

Its not a very good word, but its the only one I know of that can
describe... affordance ;)

- Steve
Chris Share
2004-06-08 11:24:19 UTC
Permalink
Hi,

I'd like to get a copy of Takashi Iwai's "Writing an ALSA Driver"
however most of the links to it seem to be broken.

Where can I get a copy of this article?

Cheers,

Chris Share
Claudio Mettler
2004-06-08 11:33:02 UTC
Permalink
Post by Chris Share
I'd like to get a copy of Takashi Iwai's "Writing an ALSA Driver"
however most of the links to it seem to be broken.
Where can I get a copy of this article?
Google, less than 1 Minute:
http://www.alsa-project.org/documentation.php#Driver
e***@cableone.net
2004-06-08 15:03:39 UTC
Permalink
Hey, I wouldn't mind working on the graphics, I just don't know where to start or
who else is working on it.

Jan
Post by Steve Harris
Post by Marek Peteraj
VST plugins tend to be rather complex, offering tons of features and
eyecandish GUIs, while LADSPAs usually offer limited functionality, no
GUI at all(hosts usually provide simple ones to control the parameters).
But what's interesting is that each LADSPA plugin usually implements
exactly one type of DSP technique, for example, an oscillator, or a
delay. This basically leads to a situation where a certain DSP technique
is 'isolated' in a separate plugin.
I think thats down to two factors (and its not a good thing)
1) LADSPA developers are few in number and short in time. The basics are a
good place to start.
2) The lack of a UI standard makes complex plugins a bit pointless.
There are a few counter examples (e.g. my VyNil plugin wraps a lot of
different bits), and infact if you look in many LADSPA plugins you will
see theres really more going on than there appears to be.
[OT] - my canned plugin writing experience - all generalisations and IMHO
of course
Time breakdown: 10% writing code, 10% maths and optimising, 80% tweaking
and tuning.
Mapping the controls 1:1 with DSP parameters makes plugins crap - people
say they want that if you ask them, but they dont mean it ;)
Fewer controls is better.
Affordance, appearance and usability has as much affect on the perceived
sound quality as the DSP code (posivly and negativly). Some of this can
be achieved without a custom UI.
You mentioned JAMin - true that does use LADSPA plugins - but of the total
ammount of code the LADSPA plugins are a tiny fraction. I just reused them
because I hate fixing bugs in two places :)
[OOT] I used to think that a UI spec for LADSPA (to make it competetive
with VST) was a technological problem. I now thinks its a manpower issue
(I think Paul Davis pointed this out a couple of years ago :). Games
develpment has moved to the point where the graphics work is more
expensive than the software development, and I bet its not far off in
plugin / eyecandy app development. We have no, or almost no, graphics
people here.
There are plenty of graphics people working on Free Software projects, but
they all seem to be working on games projects. What a waste. I guess
drawing goblins is more fun than sliders and LEDs. Who knew? ;)
Steve Harris
2004-06-08 16:36:41 UTC
Permalink
Post by e***@cableone.net
Hey, I wouldn't mind working on the graphics, I just don't know where to start or
who else is working on it.
Ah, well, thats back to problem A, the technical problem. ;)

I lent the DSSI specification (http://dssi.sourceforge.net/) towards
something that would be applicable to LADSPA too if its successful, but
noones implemnted it in a real LADSPA host yet, so it not useful for
LADSPA.

There have been a few attempts at LADSPA GUI specs in the past, but
they've all been missing that elusive something, and support.

- Steve
Tim Orford
2004-06-08 17:59:11 UTC
Permalink
Post by Steve Harris
There have been a few attempts at LADSPA GUI specs in the past, but
they've all been missing that elusive something, and support.
is it possible to summarise the objections to the dssi approach
for ladspa? Its difficult to get an overview from the archives, but
this did seem to be the favourite.

on the surface it looks like a good solution
(gui as separate app, gui -> plugin-host ipc via osclite).
It could free graphic artists to use the tools they are comfortable
with, which is a prerequisite for the emergence of nice gui's.
--
Tim Orford
Chris Cannam
2004-06-08 19:26:21 UTC
Permalink
Post by Tim Orford
is it possible to summarise the objections to the dssi approach
for ladspa?
One objection is that it completely avoids addressing the problem of
how to embed the GUI inside the host on-screen. Each GUI is
basically assumed to run up as a separate top-level window.

I could imagine some library support for re-parenting GUIs, but it
certainly isn't intrinsic to the current proposal. The problem is
exacerbated by the fact that GUIs that are most comfortable running
in entirely separate windows are likely to be the more complex ones
that are perhaps less amenable to being hosted plugins in the first
place -- if the GUI can happily run standalone, there's a stronger
argument for making the entire "plugin" a standalone JACK app.

(The upside of this, of course, is that if the GUI crashes it won't
bring down the host. Since the GUI is often the most unstable bit of
a plugin, that could be a very good thing.)

A further conceptual criticism is that it will just encourage people
to produce GUIs that are inconsistent, inelegant, tasteless and hard
to use -- i.e. it doesn't do anything to address the biggest problems
a plugin author might face when writing a GUI, namely what to build
the GUI from and how to design and organise it. A separate library
to help with that by wrapping basic toolkit widgets in forms likely
to be of use to audio plugins might be worth considering.

An implementation disadvantage is the need to produce two separate
object files (the .so and the GUI), to ensure that they can both be
discovered by the host, and to keep them in sync -- for example to
make sure the GUI knows about the most up-to-date set of plugin
ports. Of course the GUI can always load the plugin and query it
itself, but most probably wouldn't want to do that.


Chris
Dave Robillard
2004-06-08 19:26:03 UTC
Permalink
Post by Chris Cannam
Post by Tim Orford
is it possible to summarise the objections to the dssi approach
for ladspa?
One objection is that it completely avoids addressing the problem of
how to embed the GUI inside the host on-screen. Each GUI is
basically assumed to run up as a separate top-level window.
Maybe it's just me personally, but I don't see much of a problem with
this. I think of ams, where the modules themselves are just shown as,
er, little boxes with ports, but you can click 'em to get the gui and
change all the parameters. Ardour is the same way.

All we need IMHO is a way to have that parameter view be a custom GUI.

I can't honestly even think of a case where embedding the plugin UIs
would even be wanted (though I'm sure someone can).. plugin GUIs are
huge and take up a lot of space. I just want to be able to pop the
thing up, fiddle with it, and make it go away.

Maybe if you want to do a reason-like virtual rack type of thing, but..
well, reason's UI is stupid. :)

-Dave Robillard
Chris Cannam
2004-06-08 19:55:09 UTC
Permalink
Post by Dave Robillard
All we need IMHO is a way to have that parameter view be a custom GUI.
For my part, I'd at least like the host to be able to specify where
the window should appear -- which it currently can't. Maybe that's
something worth considering already for DSSI.


Chris
Steve Harris
2004-06-09 10:02:50 UTC
Permalink
Post by Chris Cannam
Post by Dave Robillard
All we need IMHO is a way to have that parameter view be a custom GUI.
For my part, I'd at least like the host to be able to specify where
the window should appear -- which it currently can't. Maybe that's
something worth considering already for DSSI.
Maybe. I have no particular objections, but the UI should be free to
ignore it I think. The old-school X11 -geometry seems like a good starting
place. e.g. xclock -geometry +10+10

- Steve
t***@gmx.de
2004-06-09 12:06:05 UTC
Permalink
Post by Steve Harris
Post by Chris Cannam
Post by Dave Robillard
All we need IMHO is a way to have that parameter view be a custom GUI.
For my part, I'd at least like the host to be able to specify where
the window should appear -- which it currently can't. Maybe that's
something worth considering already for DSSI.
Maybe. I have no particular objections, but the UI should be free to
ignore it I think. The old-school X11 -geometry seems like a good starting
place. e.g. xclock -geometry +10+10
no this is not sufficient at all.
if i put a plugin onto the galan canvas and scroll it up and down, i
want the plugin to follow the scrolling.

for me its sufficient to get the XID of the window.
Embedding is possible with fluxbox and iceWM.

and i think i know why other window managers dont let me embed windows.
note that galan currently embeds VST windows.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Steve Harris
2004-06-09 09:57:52 UTC
Permalink
Post by Chris Cannam
An implementation disadvantage is the need to produce two separate
object files (the .so and the GUI), to ensure that they can both be
discovered by the host, and to keep them in sync -- for example to
make sure the GUI knows about the most up-to-date set of plugin
ports. Of course the GUI can always load the plugin and query it
itself, but most probably wouldn't want to do that.
I'm not convinced this is a problem:

1) its equivalent to having a plugin/library inconsistency, so the build
or packaging system should take care of it

2) plugins with the same UID are supposed to be port-compatible, though
due to developer lazyness this doesnt always happen *cough*

- Steve
Chris Cannam
2004-06-09 10:28:28 UTC
Permalink
Post by Steve Harris
2) plugins with the same UID are supposed to be port-compatible,
though due to developer lazyness this doesnt always happen *cough*
DSSI actually identifies the plugin to the UI by .so and label, not by
unique ID. And there's no such requirement for labels, is there?

The whole thing about unique IDs troubles me though, because they're
supposed to be globally unique, right? So what should you do if you
want to write a .so that could instantiate any number of plugins
dynamically, either by generating them according to some
configuration or by wrappering e.g. an existing directoryful of VST
plugins? You can't possibly guarantee global uniqueness if you don't
even know in advance how many plugins you'll be offering.


Chris
Steve Harris
2004-06-09 10:46:23 UTC
Permalink
Post by Chris Cannam
Post by Steve Harris
2) plugins with the same UID are supposed to be port-compatible,
though due to developer lazyness this doesnt always happen *cough*
DSSI actually identifies the plugin to the UI by .so and label, not by
unique ID. And there's no such requirement for labels, is there?
Ah, no true, I forgot we used .so + label. Still the packaging system
should take care of it.
Post by Chris Cannam
The whole thing about unique IDs troubles me though, because they're
supposed to be globally unique, right? So what should you do if you
want to write a .so that could instantiate any number of plugins
dynamically, either by generating them according to some
configuration or by wrappering e.g. an existing directoryful of VST
plugins? You can't possibly guarantee global uniqueness if you don't
even know in advance how many plugins you'll be offering.
The UID is not globally unique - I think the way it was defined was just a
mistake.

- Steve
Chris Cannam
2004-06-09 11:16:14 UTC
Permalink
Post by Steve Harris
The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect.

(jack-rack and Rosegarden at least currently use the unique ID to
index plugins and will reject plugins with duplicate IDs.)


Chris
Steve Harris
2004-06-09 11:09:04 UTC
Permalink
Post by Chris Cannam
Post by Steve Harris
The UID is not globally unique
Well, I would prefer that it wasn't, but unfortunately that does
contradict what ladspa.h specifies and what real hosts expect.
Nothing in ladspa.h says that UIDs are globally unique - just the .so +
label combination is guaranteed to be (system) unique.
Post by Chris Cannam
(jack-rack and Rosegarden at least currently use the unique ID to
index plugins and will reject plugins with duplicate IDs.)
Yep, and I think thier not alone. I only realised that UIDs were not
globally unique recently myself. Its kinda obvious when you think about
gnerated plugins, but its very confusing.

Using some kind of self-authorising, URI-like scheme would have been a
much better idea, but hey. Its a bit late now.

- Steve
Chris Cannam
2004-06-09 11:29:35 UTC
Permalink
Post by Steve Harris
Nothing in ladspa.h says that UIDs are globally unique
I think "Plugin programmers may reserve ranges of IDs from a central
body to avoid clashes" pretty strongly suggests it, don't you?


Chris
Steve Harris
2004-06-09 11:32:43 UTC
Permalink
Post by Chris Cannam
Post by Steve Harris
Nothing in ladspa.h says that UIDs are globally unique
I think "Plugin programmers may reserve ranges of IDs from a central
body to avoid clashes" pretty strongly suggests it, don't you?
eah, except that not all plugins are created by programmers, some are
created by programs. I also read may as in the IETF's SHOULD - which
doesn't have that strong a meaning, that would be MUST I think.

- Steve
Tim Orford
2004-06-09 10:58:21 UTC
Permalink
thanks for your good answer, Chris!
Post by Chris Cannam
Post by Tim Orford
is it possible to summarise the objections to the dssi approach
for ladspa?
One objection is that it completely avoids addressing the problem of
how to embed the GUI inside the host on-screen. Each GUI is
basically assumed to run up as a separate top-level window.
thereby remaining flexible and avoiding some extremely thorny issues
over differing toolkits and x event loops.

sure it would be nice to have the embedding option, but in
how many situations is that really neccesary? (Especially as
the gui is optional anyway)

and given that we have an unknown quantity of windows of varying
size, i cant see how that would work. But I personally have no user
experience of embedded plugin windows.
(I think galan does this, but i cant compile it)
Post by Chris Cannam
I could imagine some library support for re-parenting GUIs, but it
certainly isn't intrinsic to the current proposal. The problem is
exacerbated by the fact that GUIs that are most comfortable running
in entirely separate windows are likely to be the more complex ones
that are perhaps less amenable to being hosted plugins in the first
place -- if the GUI can happily run standalone, there's a stronger
argument for making the entire "plugin" a standalone JACK app.
surely standalones and plugins both have their place? I dont buy
the argument that complex fx should be standalones.
Post by Chris Cannam
A further conceptual criticism is that it will just encourage people
to produce GUIs that are inconsistent, inelegant, tasteless and hard
yes giving people freedom will cause "inconsistent, inelegant, tasteless
and hard to use" things to arise but it will also cause good things
too:-) As long as the gui's are optional, this surely cannot be a
problem. I'm also assuming that multiple alternative gui's can be made
available.
Post by Chris Cannam
to use -- i.e. it doesn't do anything to address the biggest problems
a plugin author might face when writing a GUI, namely what to build
the GUI from and how to design and organise it. A separate library
to help with that by wrapping basic toolkit widgets in forms likely
to be of use to audio plugins might be worth considering.
not from my point of view. Any special library is going to be very
limiting. I would hate to see linux hobbled by this in the same way as
vst is. I dont think anyone has mentioned in this thread that
presumably libvstgui is a significant factor in encouraging the use of
those cheesy bitmaps that most of us find unusable even if we can stomach
the looks.

and i dont think the plugin author should _have_ to worry about guis
at all. People who can do dsp code _and_ user interfaces are the
exception rather than the rule.

i would rather some ladspa template gui apps were made which encouraged
artists to use whatever tech they wanted. Eg Gtk, Qt, Svg, Flash,
GnomeCanvas, SDL, XUL, DHtml, OpenGl etc...
Post by Chris Cannam
An implementation disadvantage is the need to produce two separate
object files (the .so and the GUI), to ensure that they can both be
discovered by the host, and to keep them in sync -- for example to
make sure the GUI knows about the most up-to-date set of plugin
ports. Of course the GUI can always load the plugin and query it
itself, but most probably wouldn't want to do that.
cheers
--
Tim Orford
Chris Share
2004-06-08 16:42:42 UTC
Permalink
Thanks!

-----Original Message-----
From: linux-audio-dev-***@music.columbia.edu
[mailto:linux-audio-dev-***@music.columbia.edu] On Behalf Of Claudio
Mettler
Sent: 08 June 2004 12:33
To: The Linux Audio Developers' Mailing List
Subject: Re: [linux-audio-dev] Writing An ALSA Driver?
Post by Chris Share
I'd like to get a copy of Takashi Iwai's "Writing an ALSA Driver"
however most of the links to it seem to be broken.
Where can I get a copy of this article?
Google, less than 1 Minute:
http://www.alsa-project.org/documentation.php#Driver
e***@cableone.net
2004-06-08 17:43:20 UTC
Permalink
Post by Marek Peteraj
It all depends on how you perceive different controls (different knobs
in different sections etc) and how you learn ot perceive them, i.e. how
you get to know them and how you get used to them.
Aaaaaarrrrrggghhhh - knobs. One of my pet peeves. Knobs make absolutely no
sense in a GUI. There is no easy (or standard) way to control them. Note that
there are no knobs in JAMin. The parametric controls aren't even knobs. I think
this was the point he was making. Take a look at T-RackS. Lovely knobs and
litle glowing tube pictures - how lovely. But a major PITA to use. Trying to
make GUIs that look like some metal box is counterproductive. Just make the
thing work efficiently.
Post by Marek Peteraj
Virtual 3d guis copy the real world. Try to do it the other way around,
with widget sliders and one color for both sliders and background(most
cases). Imagine a hw which would look like that.
Why would I want to imagine hardware - we are talking about software aren't we?
Post by Marek Peteraj
Another such case is animations in UI. They improve usability aswell.
If carefully adjusted, they help to prevent sudden changes in the UI.
Animations are not just eye-candy.
Sometimes. Rarely. Usually they are just a way to sell a product.

Jan
Frank Barknecht
2004-06-08 18:16:08 UTC
Permalink
Hallo,
Post by e***@cableone.net
Aaaaaarrrrrggghhhh - knobs. One of my pet peeves. Knobs make absolutely no
sense in a GUI. There is no easy (or standard) way to control them. Note that
there are no knobs in JAMin. The parametric controls aren't even knobs. I think
this was the point he was making.
I actually wrote a knob GUI element for Pd, which normally only has
sliders. I see one good application for knobs: Visualizing things that
must not take up much screen space. Visualizing things like a clock
won't work with sliders. And if you make a knob settable by vertical
movement it's not that bad. But I agree, generally sliders are much
better to use.

Ciao
--
Frank Barknecht _ ______footils.org__
Chris Cannam
2004-06-08 19:03:10 UTC
Permalink
Post by Frank Barknecht
Post by e***@cableone.net
Aaaaaarrrrrggghhhh - knobs. One of my pet peeves.
I actually wrote a knob GUI element for Pd, which normally only has
sliders. I see one good application for knobs: Visualizing things
that must not take up much screen space.
They also have the advantage of a more obvious centre position than a
slider, I believe they can be significantly quicker to read, although
not to edit, and they can be placed in meaningful groups more easily.
I think they're a much better GUI element than people give them
credit for.

The problem is knowing when to use them. Rosegarden uses knobs for
all LADSPA port controls, and the results are not very satisfactory.
Jack-rack uses sliders for all LADSPA port controls, and IMHO the
results there are not satisfactory either, although they are
generally better. The ideal would be a mixture but I don't think the
host can reliably tell which should be which. I imagine the real
value of a custom GUI is in contextual and organisational details
like that. (Although I do think flashy graphics can be nice too.)


Chris
Steve Harris
2004-06-09 09:07:07 UTC
Permalink
Post by Chris Cannam
Post by Frank Barknecht
Post by e***@cableone.net
Aaaaaarrrrrggghhhh - knobs. One of my pet peeves.
I actually wrote a knob GUI element for Pd, which normally only has
sliders. I see one good application for knobs: Visualizing things
that must not take up much screen space.
They also have the advantage of a more obvious centre position than a
slider, I believe they can be significantly quicker to read, although
not to edit, and they can be placed in meaningful groups more easily.
I think they're a much better GUI element than people give them
credit for.
Agreed, or can be. The exat implementation can make a great deal of
difference to the usability. One of the nice features is that you can set
controls more accuratly that sliders without using vast ammounts of screen
realestate.
Post by Chris Cannam
The problem is knowing when to use them. Rosegarden uses knobs for
all LADSPA port controls, and the results are not very satisfactory.
Jack-rack uses sliders for all LADSPA port controls, and IMHO the
results there are not satisfactory either, although they are
generally better. The ideal would be a mixture but I don't think the
host can reliably tell which should be which. I imagine the real
value of a custom GUI is in contextual and organisational details
like that. (Although I do think flashy graphics can be nice too.)
My guess is that, often, knobs are better for LOG scaled things and
sliders btter for linear. Just a rule of thumb though.

- Steve
e***@cableone.net
2004-06-08 18:46:35 UTC
Permalink
Post by Chris Cannam
Post by Frank Barknecht
Post by e***@cableone.net
Aaaaaarrrrrggghhhh - knobs. One of my pet peeves.
I actually wrote a knob GUI element for Pd, which normally only has
sliders. I see one good application for knobs: Visualizing things
that must not take up much screen space.
They also have the advantage of a more obvious centre position than a
slider, I believe they can be significantly quicker to read, although
not to edit, and they can be placed in meaningful groups more easily.
I think they're a much better GUI element than people give them
credit for.
Right click on any slider in JAMin and it immediately goes to the default
position, whether center or zero. I did this to give you something that works
like a detent. They can be easier to read and they may take up less space than a
slider but why limit yourself to knobs and sliders. There are other ways to
graphically handle controls.

Jan
Chris Cannam
2004-06-08 19:22:24 UTC
Permalink
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes to
the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In Rosegarden
you double-click to zero a fader. I didn't think of right-clicking.

But what I meant about knobs having a more obvious centre position is
that (a) it's easier to see that one is centred, and (b) it's easier
to see that you're dealing with data that has a concept of a centre.
(Rosegarden of course craps all over this theoretical helpfulness by
using knobs for values that have no centre, as well as using knobs
whose central values are not at the top.)


Chris
Jan Depner
2004-06-08 21:22:19 UTC
Permalink
Post by Chris Cannam
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes to
the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In Rosegarden
you double-click to zero a fader. I didn't think of right-clicking.
It's in the context sensitive help.
Post by Chris Cannam
But what I meant about knobs having a more obvious centre position is
that (a) it's easier to see that one is centred, and (b) it's easier
to see that you're dealing with data that has a concept of a centre.
(Rosegarden of course craps all over this theoretical helpfulness by
using knobs for values that have no centre, as well as using knobs
whose central values are not at the top.)
Yes, it's definitely easier to see the position of a knob (usually).
The parametric sliders in the JAMin HDEQ are a result of my not wanting
to use knobs. I think there are probably other ways to replace them as
well.

Jan
Richard Bown
2004-06-09 06:30:49 UTC
Permalink
Post by Chris Cannam
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes to
the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In Rosegarden
you double-click to zero a fader. I didn't think of right-clicking.
Actually no - you right click in RG to center a fader. Double click doesn't
do anything AFAICT so maybe you dreamt that.

R
Chris Cannam
2004-06-09 07:32:58 UTC
Permalink
Post by Richard Bown
Post by Chris Cannam
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes
to the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In
Rosegarden you double-click to zero a fader. I didn't think of
right-clicking.
Actually no - you right click in RG to center a fader. Double
click doesn't do anything AFAICT so maybe you dreamt that.
Ah well here we go again then, an inconsistency. You certainly do
double-click to zero a fader, but (again I hadn't thought to try this
before, but now I just have) you right-click to centre a knob. And
that is centre, rather than reset to default, which seems odd.

(btw, in JAMin it seems you actually middle-click, not right-click, to
reset a fader. At least in the version I have here.)


Chris
e***@cableone.net
2004-06-08 18:54:44 UTC
Permalink
Post by Fons Adriaensen
- When I saw the collection of VST plugins that Paul Davis used
to show his VST hosting in Karlsruhe, I asked myself "My god,
do they all look that childish ?". This is just to say I terribly
dislike this eye-candy style, and given the choice between that
and a (maybe boring) set of standard toolkit sliders, I'd prefer
the latter. The ideal is somewhere in between, but certainly not
to the eye-candy side.
Amen!
Post by Fons Adriaensen
- Before everything went digital, multitrack mixing desks had
lots of controls and very little space to put them in. Good
layout was absolutely essential, and most of the big name
manufacturers mastered this quite well. It's done by
- observing elementary aesthetic rules (e.g. color
combinations),
Colors must always be configurable. The percentage of color blind people is
much higher than most people think.
Post by Fons Adriaensen
- removing all useless clutter,
- following the logic of the application, e.g. keeping
things that are related together,
- accepting culturally defined standards, such as that
a signal flows from left to right and from top to bottom.
Except in China ;-)
Post by Fons Adriaensen
- using hints that are picked up unconsciously, rather
than explicit labeling.
All of this is practically the inverse of eye-candy.
- Confucius says: When you see a piece of audio equipment
with the word "Professional" printed on it, then it probably
isn't.
- The typical VST plugin (talking about the serious ones)
corresponds more to a JACK application than a LADSPA plugin,
not because both have a GUI, but because of the complexity.
This is just a matter of naming. We could start calling a
JACK application a JACK 'plugin' but I'd vote against.
JAMIN is a good example of this.
- As to LADSPA plugins, we could probably give almost all
of them a very functional and nice GUI by defining a set
of a few dozens of 'widget types'. Then there are a few
1. the plugin specifies the dimensions and positions of
all the widgets,
2. the dimensions are standard, and the plugins specifies
the positions only,
3. the host keeps it own database of layouts indexed by
plugin ID.
Good idea but I'd think that could get real complicated very fast.

Jan
Jens M Andreasen
2004-06-09 08:10:22 UTC
Permalink
Post by e***@cableone.net
Colors must always be configurable. The percentage of color blind people is
much higher than most people think.
I think the percentage of colorblind males are about 10%

If you use the green/red metaphore (as in walk/stop) they will be in
some trouble. If you use the red/blue metaphore instead (as in hot/cold)
it will work just fine. If green is important, you can use a scale from
turquise thru violet to magenta. Add some variation in light intensity
and it will even make sense on B/W screen.
Post by e***@cableone.net
Post by Fons Adriaensen
- accepting culturally defined standards, such as that
a signal flows from left to right and from top to bottom.
Except in China ;-)
Last time I checked, rivers flew from the top of the mountains, thru the
valleys below, and out in the ocean. Even in China :)

/jens
Alfons Adriaensen
2004-06-09 10:11:27 UTC
Permalink
Post by Jens M Andreasen
Last time I checked, rivers flew from the top of the mountains, thru the
valleys below, and out in the ocean. Even in China :)
Even in countries that are upside down, such as Australia :-)
--
FA
CK
2004-06-09 10:21:36 UTC
Permalink
Post by Steve Harris
Post by Jan Depner
The problem is that it's not a word. Your understanding of it is
probably the best definition there is ;-)
I have to disagree with this - it may not be a german word, but it
certainly is an English one - its been in consistant use in scientific
literature for ~30 years.
as I pointed out earlier "Affordanz" _is_ a german word (if I would need to
make it up I'd come up with something more beautiful ;) and just like it's
english counterpart has been primarily used in psychology and related fields.
Post by Steve Harris
(UK) English is defined by usage - not a canonical dictionary, so it is a
word.
so is german (and I don't care if this is the official view).

regards,

x
--
***@lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
Paul Davis
2004-06-09 11:04:54 UTC
Permalink
Post by Richard Bown
Post by Chris Cannam
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes to
the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In Rosegarden
you double-click to zero a fader. I didn't think of right-clicking.
Actually no - you right click in RG to center a fader. Double click doesn't
do anything AFAICT so maybe you dreamt that.
and so here we have another wonderful (G)UI conundrum. i don't believe
any of the "HiG's" (Apple, GNOME etc) provide any specification for
such a thing. as a result, with just 3 apps we have:

JAMin: default value = button3 click
context menu = ??
Rosegarden: default value = button3 click
context menu = ??
Ardour: default value ctrl-button2 click
context menu = button3 click
Most *nix and win apps: context menu = button3 click

what to do?

--p
Chris Cannam
2004-06-09 11:31:05 UTC
Permalink
Post by Paul Davis
JAMin: default value = button3 click
context menu = ??
Rosegarden: default value = button3 click
context menu = ??
Rosegarden is internally inconsistent, because button3 click is for
context menu elsewhere in it. (That's probably why it had never
occurred to me to try using button3 on any of the controller widgets
there or in JAMin.) It's only on the knob widgets that button3
performs a reset.

As I said previously, double-click resets a fader in Rosegarden, so
there's a fourth alternative for your list. Actually I prefer that
to any of the above, but maybe I'm just keen on double-clicking. I
have known other people find double-click really hard to do.
Post by Paul Davis
Ardour: default value ctrl-button2 click
context menu = button3 click
Chris
Steve Harris
2004-06-09 11:30:08 UTC
Permalink
Post by Chris Cannam
Post by Paul Davis
JAMin: default value = button3 click
context menu = ??
Rosegarden: default value = button3 click
context menu = ??
Rosegarden is internally inconsistent, because button3 click is for
context menu elsewhere in it. (That's probably why it had never
occurred to me to try using button3 on any of the controller widgets
there or in JAMin.) It's only on the knob widgets that button3
performs a reset.
Middle button seems both reasonably logical and not used for anyting else
in this context (pasting into a slider?!).

I might expect double-click to open up a spinner dialogue, so I could
enter values by hand.

- Steve
Chris Cannam
2004-06-09 12:06:03 UTC
Permalink
Post by Steve Harris
Middle button seems both reasonably logical and not used for
anyting else in this context (pasting into a slider?!).
Dunno about other people but I find middle-click quite hard work with
a wheely mouse, at least without wheeling the wheel accidentally at
the same time.


Chris
Paul Davis
2004-06-09 11:52:21 UTC
Permalink
Post by Paul Davis
Ardour: default value ctrl-button2 click
context menu = button3 click
chris - heh, i am as bad as you! i got ardour's wrong :) default value
is shift-button1. ctrl-button2 initiate MIDI binding.
e***@cableone.net
2004-06-09 11:55:13 UTC
Permalink
No, I didn't dream it, I wrote it. I may have missed a slider or two but I think
I got most of them. Of course I am talking about the latest CVS not 0.8.0.

Jan
Post by Richard Bown
Post by Chris Cannam
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes to
the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In Rosegarden
you double-click to zero a fader. I didn't think of right-clicking.
Actually no - you right click in RG to center a fader. Double click doesn't
do anything AFAICT so maybe you dreamt that.
Chris Cannam
2004-06-09 12:30:43 UTC
Permalink
Post by e***@cableone.net
No, I didn't dream it, I wrote it.
He meant I dreamt what I said about Rosegarden. Not quite true
either, but closer.


Chris
e***@cableone.net
2004-06-09 12:13:18 UTC
Permalink
Sorry, you are correct. In JAMin it's center click. Jeez, I wrote it, I should
know these things :-\

Jan
Post by Chris Cannam
Post by Richard Bown
Post by Chris Cannam
Post by e***@cableone.net
Right click on any slider in JAMin and it immediately goes
to the default position, whether center or zero.
Ah, now I looked for that feature but didn't find it. In
Rosegarden you double-click to zero a fader. I didn't think of
right-clicking.
Actually no - you right click in RG to center a fader. Double
click doesn't do anything AFAICT so maybe you dreamt that.
Ah well here we go again then, an inconsistency. You certainly do
double-click to zero a fader, but (again I hadn't thought to try this
before, but now I just have) you right-click to centre a knob. And
that is centre, rather than reset to default, which seems odd.
(btw, in JAMin it seems you actually middle-click, not right-click, to
reset a fader. At least in the version I have here.)
Chris
Marek Peteraj
2004-06-09 14:42:31 UTC
Permalink
Post by Marek Peteraj
1. we'd need to centralize the LADSPA scene on the web, using the
www.ladspa.org site, building a unified ladspa directory, each entry
would describe the plugin(category, author, decription, purpose)
At least? :)

Marek
Loading...