date:20110222

On Mon, Feb 21, 2011 at 09:14:31PM -0500, Paul Davis wrote:
 On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen f...@linuxaudio.org wrote:
 
  This excludes Windows (TM), but again, I couln't care less.
 
 It also excludes OS X, which despite having X11 support isn't really
 what you mean by supports X11.

You can run X11 apps in OSX. So you can have the host side of a plugin
library that is an X11 client. 

But I think you are missing the point: it's not focussing on X11.
It is simply that the only interaction between a host and a plugin
(for what regards their visual integration) should be the lowest
common level between the toolsets each of then uses and not anything
that is a private type of either . For current toolkits (on Linux)
this an X11 window ID. It's all plugin needs in order to know where
on the screen it should go. And the rest it can do itself.

If the underlying layer is not X11 this is just the same. Every
system needs some abstraction of 'an area of the screen that is
managed as a basic unit'. In X11 that is represented by a window
ID, in other systems it will be something similar.

 at some point, focusing on X11 will  also start to exclude the next
 generation of linux UI systems which are not going to be X11 (even
 though they are re-using a lot of the internal code and can host X11
 windows). once you've seen them in action, i think that even you will
 be a believer :) I'm talking primarily about Wayland
 
 http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29

ATM it doesn't even provide network transparancy. Which means you can't
even do the equivalent of ssh -X. 


Ciao,

-- 
FA
 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Mon, Feb 21, 2011 at 09:26:09PM -0500, David Robillard wrote:
 
 It is obviously not useful to have hundreds of plugin UI windows open at
 once anyway.

Unless they are embedded instead of being separate top level windows.
 
 If you're on an X11 system, then you can use X11 as a base to support
 several toolkits in exactly the way you described (if those toolkits use
 X11, of course). The experiment you described is an implementation
 strategy, and possibly one we should use in the aforementioned library
 to avoid the out-of-process overhead. The source code would be useful.


 However, there is no need or even benefit to forcing UI and/or host
 authors to deal with X11 directly. That is simply a poor API design, and
 a nuisance for everyone.

I think you misunderstood things a bit. Neither the host nor the plugin
has to deal with X11 directly, each of them uses whatever toolkit they
like. The essential point is that what is exchanged (once) between
them is something that is common to both - an X window ID in the case
of X11 systems or the equivalent if the basic system is not X. The
plugin uses this as the  parent for its own window. Which means that
the plugin window's position, visibility, etc. are now under control
of the host. 

The code needed to do this can be part of a plugin support library on
both sides. 

Toolkits that can't 

* extract the underlying type (in this case a X window ID) from their
  own data structures or
* use such information as a parameter when creating a new window of
  their own type

are simply deficient.

Ciao,

-- 
FA


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb


 ATM it doesn't even provide network transparency. Which means you can't
 even do the equivalent of ssh -X. 

Does anybody even use this feature anymore?

It is another pet beef, though. Most Linux desktop distributions disable the
TCP connections to the X server anyway so the features of '-X' are rendered
obsolete.

There are naturally good reasons for this: if audio people are concerned about
system security aspects of RT_PRIO and SCHED_FIFO/RR then the TCP access
issues are an even greater concern. Based on the fact that a generation of
users don't see the point, windows doesn't do it, iOS doesn't do it then there 
is
not a lot of point that Linux carry the flag for a solution to a problem that 
people don't have anymore.

Regards, nick
  ___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Tom Szilagyi

On 22 February 2011 13:45, Nick Copeland nickycopel...@hotmail.com wrote:
 ATM it doesn't even provide network transparency. Which means you can't
 even do the equivalent of ssh -X.

 Does anybody even use this feature anymore?

All the time. It is an essential remote administration tool in the
UNIX (increasingly Linux) world. I have no idea how I could live
without it.


 It is another pet beef, though. Most Linux desktop distributions disable the
 TCP connections to the X server anyway so the features of '-X' are rendered
 obsolete.

And I always enable it back when this happens...

 There are naturally good reasons for this: if audio people are concerned
 about
 system security aspects of RT_PRIO and SCHED_FIFO/RR then the TCP access
 issues are an even greater concern. Based on the fact that a generation of
 users don't see the point, windows doesn't do it, iOS doesn't do it then
 there is
 not a lot of point that Linux carry the flag for a solution to a problem
 that
 people don't have anymore.

At least once in the recent past I used Ardour over ssh -X (over a
fast network) to make use of a relatively powerful remote machine I
was using for testing.

Security issues are IMO better handled by a separate firewall between
you and the internet - in your own LAN, why not enable TCP access? It
already saved my butt more than once. Windows doesn't do it - so what?
Are we going to downgrade all our tools? Mind you, Windows doesn't
even ship with a compiler.

Tom
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Tue, Feb 22, 2011 at 01:45:35PM +0100, Nick Copeland wrote:
 
  ATM it doesn't even provide network transparency. Which means you can't
  even do the equivalent of ssh -X. 
 
 Does anybody even use this feature anymore?
 
 It is another pet beef, though. Most Linux desktop distributions disable the
 TCP connections to the X server anyway so the features of '-X' are rendered
 obsolete.

You're mixing up thing here. Most systems do indeed disable direct connections
to the X server (for good reasons) and expect you to use ssh -X instead. 
 
 Based on the fact that a generation of users don't see the point,
 windows doesn't do it, iOS doesn't do it then there is
 not a lot of point that Linux carry the flag for a solution to a problem that 
 people don't have anymore.

So what do you do if you want to run apps on system A (probably headless)
and have it display on system B ? Dedicated 'remote' versions or web interfaces
(ROTFL) for each and every of them ? I'm writing this mail logged in to a 
system 
that is located in a different continent and I don't even notice it. 

If 'a generation of users' is any reference, we should just forget about
Linux, switch to Windows and call it a day. We should also eat only fast
food, believe everything the TV news and ads tell us, hate strangers and
homosexuals, and generally be ignorant about everything. There's probably
no argument more irrelevant than this sort of populist ones.

Ciao,

-- 
FA
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Tue, Feb 22, 2011 at 8:46 AM, Nick Copeland
nickycopel...@hotmail.com wrote:

 To come back to the original thread, X11 is very old in the tooth. It is
 based on
 assumptions that are not longer valid and the result is a pretty cumbersome
 solution. It was written before reasonable foundations for distributed
 computing
 were really put in place. People have been whitening its teeth and giving it
 a shave
 here and there to try and make it appear spruce but that does not detract
 from the
 fact that it is an ever older horse that at some point has to go to the
 knackers yard.

actually, the person most responsible for all that stuff (keith
packard) has a somewhat more nuanced view of it. his talk on 25 years
of X Window at the linux plumbers conf in 2009 was really an
astoundingly good mixture of an awareness of the shortcomings of X
when paired with modern graphics and input h/w but also the importance
and subtleties of moving on from X without losing its many strengths.
wayland is really an astonishing piece of work, if only because of the
way it manages to reuse almost all the low level driver code from X
without using the upper layers or even the basic concepts of X.

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Rui Nuno Capela

On 02/22/2011 05:38 PM, David Robillard wrote:
 
 Speaking of existing work, I vaguely recall mention of a plugin with a
 Qt GUI? Where is this, I need one for testing...
 

afaict, there's none

i recall there are only two lv2 ui (sub)extensions in use, to my
knowledge of course, and you probably know better:
1) lv2_gtk_ui (http://lv2plug.in/ns/extensions/ui#GtkUI)
2) lv2_external_ui (http://lv2plug.in/ns/extensions/ui#external)
nb. qtractor, honors 2) if a plugin exposes both, although i suspect
there's none in the wild. if there were a qt or, most generally a
*non-gtk* based lv2 plugin, it would be actually using 2)--no surprise
there as 2) is currently the only existing de facto toolkit agnostic
form ;)

cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb


 X11 hides the hardware and allows the app to be independent of it, just as do
 Jack for audio, sockets for networking, etc. Do you suggest that I should not
 use Jack or sockets because e.g. Windows doesn't have them (natively) ?

Actually yes, I am suggesting you don't use Jack or Sockets if you want your 
app to be
well written and portable.

Now, what has this really got to do with hardware? You design an app, it 
interfaces to some
libraries - you talk about hardware abstraction but all the library does is 
give you access
to some features you want. Applications which rely on X to 'distribute' 
themselves are now
totally dependent on the underlying library for that feature because they have 
no other
inherent method of doing it. They are totally dependent.

This is not abstracting any function, you have just moved your dependency from 
specific
hardware to specific software because you now need _that_ set of libraries to 
work. You
talk about badly written applications but with respect to distribution models, 
if your app
was not architected to support a feature then it was 'badly written' if you 
consider that
feature to be useful. Back to bristol - the engine implements its DSP code 
because I 
considered that to be a base requirement of the product, but it also abstracts 
itself to
support a distributed mode because I also consider that to be a base 
requirement. I did
not rely on X11 to provide this feature for me just as I did not rely on any 
DSP ASIC or
specific soundcard to provide my audio interface.

 And how does Bristol run remotely but with a local display if not by either
 X forwarding, or having some ad-hoc code to split the app into two parts ?
 The latter has to be redone for each and every application, if you ever
 want to use it remotely.

You are getting off the point here which was the dependency on X11 but I am 
really
honoured that you want to know so much about my software, I truly never realised
you were such a fan. I only mentioned it because it highlights that fact that 
you don't
need X to distribute an app but Fons, I would be happy to start another thread 
if you
are that interested in blowing smoke where it isn't supposed to go and suffice 
to say
bristol does not rely on any archaic windowing systems.

 You're mixing up thing here. Most systems do indeed disable direct connections
 to the X server (for good reasons) and expect you to use ssh -X instead

No, Fons, you are mixing things up. Most systems do not even run X servers. 
Most 
systems don't even run *nix.

Only a very tiny minority are still lumbered with this aged piece of code 
called X. In
my previous post I said that a majority of these systems were not using X in a 
distributed
fashion because it is either disabled, not available (firewalled) or plain 
uninteresting and 
I stand by that statement - a few users have replied that they use this feature 
and that
speaks for itself, either a few users of a low volume interest list use the 
feature or a whole
load of people use the list and don't use the feature.

Now I like X11 but again I am not going to be a fanboy since that smells a lot 
like every
Apple advocate who is blind to the limitations of their beloved products.

   If 'a generation of users' is any reference, we should just forget about
   Linux, switch to Windows and call it a day. We should also eat only fast
   food, believe everything the TV news and ads tell us, hate strangers and
   homosexuals, and generally be ignorant about everything. There's probably
   no argument more irrelevant than this sort of populist ones.

So here I agree with Paul - something like wayland is what we will all be on in 
a few
years.

If you are relying on features of X for anything that you consider to be useful 
in your
apps then you are likely to need some very fundamental changes to what is 
likely to be
the next way of interfacing with your hardware. Now you did ask about models to 
distribute
processing and asked me to quote them: go google it, there are already plenty of
very good models out there and they are being used. If you application is 
'badly written'
as you put it, relying on a given interface for a potentially critical feature 
then it
is going to have problems migrating. It has nothing to do with libraries that 
use X
window Id in their specification, nor apps that work or not with X over SSH. As 
you well
know, if you did not consider a given requirement before the fact then you are 
going to
have problems implementing it after the ract, and offloading a feature onto the 
X11 
libraries because as a fan boy you like the way it abstracts hardware means you 
are likely 
to be in for a world of hurt later. At least you do have a few years to put it 
straight but you
do need to drop the benefits of the -X switch.

Regards, nick.


we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Stefano D'Angelo

2011/2/22 David Robillard d...@drobilla.net:
On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
[...]
Hi David,

As a plugin developer, I'm very much looking forward to this,
especially since I proposed something similar to this a bit ago
(http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
:) But the fact that you're capable and willing to implement this
solution means a lot more than my confused half-baked ideas. I look forward
to the day when embedding and cross-toolkitedness walk hand in hand.

Right, what you describe here is more or less what I am getting at (it's
come up several times in the past), except rather than bundling it with
every UI (which is copy-paste code reuse and all sorts of nuisance
waiting to happen), I think it should just be a normal system library
that hosts can use to do the job.

We generally have the philosophy that if there is a choice, complexity
does not belong in the plugin (or UI). Putting the complexity in the
plugin is bad bad bad, plugins should be small and easy to write. In
this case, a plugin UI should just implement and expose its widget -
dealing with that widget is the host's problem.

In this case, we have a tricky enough complexity that we don't want it
duplicated in all the hosts either, so a library is definitely the way
to go. I call it Suil :)

I didn't follow the whole discussion, but I just want to toss out one
not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
at YUI.

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Gabriel M. Beddingfield




On Tue, 22 Feb 2011, Philipp Überbacher wrote:


I'm not sure it helps to talk about wayland, it seems to be very much
future music. It seems ubuntu and fedora talk about a year or so, but
after reading up about its current state (three years of development so


No, it's very much going to happen.  Several distros 
(including Ubuntu[1]) have made firm decisions that they 
will be moving to Wayland... at least for the mobile 
versions of their distro.


-gabriel

[1] http://www.markshuttleworth.com/archives/551___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Tue, Feb 22, 2011 at 1:50 PM, Stefano D'Angelo zanga.m...@gmail.com wrote:

 I didn't follow the whole discussion, but I just want to toss out one
 not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
 at YUI.

I wrote an XML schema for plugin GUIs, oh, about 8 years ago.

Plugin developers who write their own GUIs aren't interested in
learning another not-in-my-toolkit method of trying to get the thing
to look right. Either they don't care, and they leave it to the host,
or they do care, and these meta-toolkit methods are inadequate to meet
their goals.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

On Tue, Feb 22, 2011 at 07:32:58PM +0100, Nick Copeland wrote:
 
  X11 hides the hardware and allows the app to be independent of it, just as 
  do
  Jack for audio, sockets for networking, etc. Do you suggest that I should 
  not
  use Jack or sockets because e.g. Windows doesn't have them (natively) ?
 
 Actually yes, I am suggesting you don't use Jack or Sockets if you want your 
 app to be
 well written and portable.
 ...
 No, Fons, you are mixing things up. Most systems do not even run X servers. 
 Most 
 systems don't even run *nix.

OK, let's make a few thing clear. I write for Linux. This list
is called Linux Audio Developers. I don't care a second if my
apps are not portable to OSX, windows, or whatever you like.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Tue, 2011-02-22 at 18:32 +, Rui Nuno Capela wrote:
 On 02/22/2011 05:38 PM, David Robillard wrote:
  
  Speaking of existing work, I vaguely recall mention of a plugin with a
  Qt GUI? Where is this, I need one for testing...
  
 
 afaict, there's none
 
 i recall there are only two lv2 ui (sub)extensions in use, to my
 knowledge of course, and you probably know better:
 1) lv2_gtk_ui (http://lv2plug.in/ns/extensions/ui#GtkUI)
 2) lv2_external_ui (http://lv2plug.in/ns/extensions/ui#external)
 nb. qtractor, honors 2) if a plugin exposes both, although i suspect
 there's none in the wild. if there were a qt or, most generally a
 *non-gtk* based lv2 plugin, it would be actually using 2)--no surprise
 there as 2) is currently the only existing de facto toolkit agnostic
 form ;)

OK. If an existing one is not currently in use, I will add a URI for Qt
widget to the UI extension (which needs a new revision anyway for other
reasons).

I am not familiar with Qt. What should the definition be? IIRC Qt4 broke
a bunch of stuff, do we need different types for different versions of
Qt?

Thanks,

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote:
2011/2/22 David Robillard d...@drobilla.net:
On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
[...]
Hi David,

As a plugin developer, I'm very much looking forward to this,
especially since I proposed something similar to this a bit ago
(http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
:) But the fact that you're capable and willing to implement this
solution means a lot more than my confused half-baked ideas. I look
forward to the day when embedding and cross-toolkitedness walk hand in
hand.

In this case, we have a tricky enough complexity that we don't want it
duplicated in all the hosts either, so a library is definitely the way
to go. I call it Suil :)

I didn't follow the whole discussion, but I just want to toss out one
not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
at YUI.

I don't think it's stupid at all. Saying using browser technology for UI
is stupid these days is the height of short-sightedness. That's clearly
where everything is headed.

I have a working plugin (called dirg) that provides a UI by hosting a
web server which you access in the browser. It provides a grid UI either
via a Novation Launchpad, or in the browser if you don't have a
Launchpad. Web UIs definitely have a ton of wins (think tablets, remote
control (i.e. network transparency), etc.)

I also have a complete LV2 message system based on Atoms which is
compatible with / based on the event extension. Atoms, and thus
messages, can be serialised to/from JSON (among other things,
particularly Turtle). This IMO definitely The Way Forward for more
advanced communication between UI and plugin: float control ports really
don't cut it, and instance-access is evil. This kind of thing is why I
have always strongly advocated the 'host handled' communication between
plugin and UI. Instance-access was designed to kludge VST UIs into LV2,
but really should not be used in new code. This is the other high
priority alarming LV2 situation right now.

Currently dirg provides the web server on its own with no host
involvement, but every plugin doing this obviously doesn't scale, so
some day we should figure this out... first we need an appropriately
high-level/powerful communication protocol within LV2 land (hence the
messages stuff).

-dr

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb


  I didn't follow the whole discussion, but I just want to toss out one
  not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
  at YUI.
 
 I don't think it's stupid at all. Saying using browser technology for UI
 is stupid these days is the height of short-sightedness. That's clearly
 where everything is headed.
 
 I have a working plugin (called dirg) that provides a UI by hosting a
 web server which you access in the browser. It provides a grid UI either
 via a Novation Launchpad, or in the browser if you don't have a
 Launchpad. Web UIs definitely have a ton of wins (think tablets, remote
 control (i.e. network transparency), etc.)

This concept made Fons ROTFL, no fons?

Regards, nick.
  ___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Tue, 2011-02-22 at 13:55 -0500, Paul Davis wrote:
 On Tue, Feb 22, 2011 at 1:50 PM, Stefano D'Angelo zanga.m...@gmail.com 
 wrote:
 
  I didn't follow the whole discussion, but I just want to toss out one
  not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
  at YUI.
 
 I wrote an XML schema for plugin GUIs, oh, about 8 years ago.
 
 Plugin developers who write their own GUIs aren't interested in
 learning another not-in-my-toolkit method of trying to get the thing
 to look right. Either they don't care, and they leave it to the host,
 or they do care, and these meta-toolkit methods are inadequate to meet
 their goals.

HTML/etc. is a very different thing from some random XML format for a
particular purpose. It is the most widely known, deployed, and portable
UI technology by a very, very, very wide margin, and this is only going
to get more true over time. Nobody ever got fired for buying HTML, so to
speak.

(Within LV2, as far as host generated UIs go, it makes more sense to
define that data in Turtle, but that's a different approach entirely
than making a UI in the toolkit sense).

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb


 OK, let's make a few thing clear. I write for Linux. This list
 is called Linux Audio Developers. I don't care a second if my
 apps are not portable to OSX, windows, or whatever you like.

So lets make a few other things clear:

Maemo is Linux and a bog standard X app would perhaps just work. Android is 
linux and it would not with out a lot of changes. As has been mentioned, Ubuntu
on mobile devices will not run X so they will not be portable.

You write for Linux? Which (antiquated) version would that be? Now you asked
about bristol - it runs on all of these. And distributed if you want, with the 
dumb
-X option.

There are a _lot_ of changes taking place in Linux at the moment. I mean you 
mouth of about using 'ssh -X' to write email from one side of the planet and, 
like,
Fons, can you do that? If I had not been doing it 20 years ago I would not have
believed it to be possible. It is old hat, move on fella.

Regards, nick.___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

On Tue, Feb 22, 2011 at 3:36 PM, Nick Copeland
nickycopel...@hotmail.com wrote:

 [  ]

does this (sub)dialog need to be so ... personal? so exclusive? so
full of the righteousness of its proponents' viewpoints that there's
no room for plurality, or doubt?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Philipp Überbacher

Excerpts from Paul Davis's message of 2011-02-22 17:57:44 +0100:
 On Tue, Feb 22, 2011 at 11:48 AM, Philipp Überbacher
 hollun...@lavabit.com wrote:
  I'm not sure it helps to talk about wayland, it seems to be very much
  future music. It seems ubuntu and fedora talk about a year or so, but
  after reading up about its current state (three years of development so
  far, pretty much proof of concept, working with some drivers only,
  crashing all over the place in the video demos) it seems to me that five
  years is a more realistic estimate (rather longer if we talk about
  replacing X). Just my guess, but it seems far from being in a reliably
  working state, so it's future music.
  Also, I don't see what's supposed to be so great about it, besides
  removing X11 cruft.
 
 it does a lot more than remove xcruft. it moves *nix display
 technology into a modern era in which everything is just a drawing
 surface that gets composited and along the way can be subject to
 arbitrary transformation. rather than insist on the type of h/w
 abstraction that X uses, which is fundamentally based on display
 technology from 20 years ago, it uses an abstraction that is largely
 h/w independent even if it relies on h/w to get the best performance
 from the rendering model. you are not drawing to windows, and you
 don't have a rectangle on the screen under your control: you render
 to a surface which will be composited into the frame buffer (possibly
 with vblank sync, a concept that X really cannot export because of
 network transparency).
 
 another way to look at it is to take any sensible drawing API: Cairo,
 PostScript, CoreDraw ... extract the core concepts behind the way they
 relate drawing to a result ... now make that into the display server.
 like JACK, don't provide very much access to the h/w concepts at all,
 but instead provide a powerful, abstract model that is actually *more*
 capable and flexible than working at the level of what the hardware
 does.
 
 of course, you have to add event handling too, but wayland's approach
 to this is also much more in line with contemporary technology than
 X's fundamental models of input devices and so forth.
 
 i agree that its a way from becoming the standard thing, but i'm
 convinced that something like wayland is what we will all be on in a
 few years.
 
 --p

The 'remove X cruft' is the most tangible aspect for me (if it means
actually reducing complexity).

The rest sounds nice, and it might well be that X has become old, but I
don't see the big improvement coming up. Windows are called surfaces
now, can have different shapes and are more flexible, compositing,
transformations, I got that bit, but I don't see the UI improvement.
I've seen the demos with shapes flying around the desktop, I've seen
the conventional compositing window managers and wayland will probably
do all that and more, but I don't see the improvement in User
Interfaces. I see fancy effects that are good for a couple of 'wow,
looks cool' moments, but I can't see an improvement in usability coming
up. Maybe I'm just not enough of a visionary to see the great things
that will be possible but I'd sure like to see examples of User
Interfaces that will really benefit from it. I want to see things that
weren't possible before, real improvements for the user, not just
eye candy.

Again, I do hope that it will reduce complexity, code complexity,
difficulties with UI coding, etc. rather than increasing them. If it
will achieve that then it will be an improvement. Sadly though things
tend to become more complex. We'll see how it'll pan out, wayland in ~5
years or X for another decade. I haven't made many predictions yet, I
still dare to make them :).

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

2011-02-22 Thread Arnold Krille

On Tuesday 22 February 2011 21:36:11 Nick Copeland wrote:
  OK, let's make a few thing clear. I write for Linux. This list
  is called Linux Audio Developers. I don't care a second if my
  apps are not portable to OSX, windows, or whatever you like.
 
 So lets make a few other things clear:
 
 Maemo is Linux and a bog standard X app would perhaps just work. Android is
 linux and it would not with out a lot of changes. As has been mentioned,
 Ubuntu on mobile devices will not run X so they will not be portable.

ubuntu will use wayland on all platforms according to mister shuttleworth, not 
just the mobile platforms. (What is a mobile-platform anyway? Your phone, yes. 
Your tabled? Your netbook? Your thin-client featuring the same hardware as the 
netbook? Your big workstation using the acceleration of wayland? And then 
there are these 'freaks' running linux on an atmel with framebuffer...)

Have fun,

Arnold


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb


 does this (sub)dialog need to be so ... personal? so exclusive? so
 full of the righteousness of its proponents' viewpoints that there's
 no room for plurality, or doubt?

This list as far as I can remember has always been full of righteous
opinions, and by pretty much all of its subscribers, Paul.

Regards, nick.
  ___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

On Tue, 2011-02-22 at 19:48 +, Fons Adriaensen wrote:
 On Tue, Feb 22, 2011 at 07:32:58PM +0100, Nick Copeland wrote:
  
   X11 hides the hardware and allows the app to be independent of it, just 
   as do
   Jack for audio, sockets for networking, etc. Do you suggest that I should 
   not
   use Jack or sockets because e.g. Windows doesn't have them (natively) ?
  
  Actually yes, I am suggesting you don't use Jack or Sockets if you want 
  your app to be
  well written and portable.
  ...
  No, Fons, you are mixing things up. Most systems do not even run X servers. 
  Most 
  systems don't even run *nix.
 
 OK, let's make a few thing clear. I write for Linux. This list
 is called Linux Audio Developers. I don't care a second if my
 apps are not portable to OSX, windows, or whatever you like.

Portability is an explicit goal of LV2 for obvious reasons.

You are free to implement a particular host or plugin only for a
particular platform, but making the spec itself non-portable is just
straight up crap design with no benefit. It's silly to argue otherwise.
That portability is a necessary goal for a successful audio plugin API
is self-evident. You don't personally care? That's nice. Speaking of
things people don't care about... ;)

In other words, I don't care about portability is a valid perspective
for an implementer. It's (worse than) worthless noise in a conversation
about plugin interface design. Portability will not hurt you whatsoever,
but it will increase adoption of LAD technology. Do you have any actual
argument against it?

As far as I am concerned, this is all about Libre audio software anyway,
and I disagree with the name of this list/site (who actually cares about
the specific kernel?). Getting e.g. OSX people on board is a part of
making the LAD 'platorm' a success. If people on proprietary platforms
start using free plugins, and they start using free hosts, eventually
they're using free everything (e.g. a Jack/LV2 based music platform) and
that's when they can switch to Lignux. Otherwise, they simply won't, and
that is obviously not a win for LAD, Linux, Open Source, GNU, Free
Software, or whatever label you prefer to rally behind.

Maybe you don't care. Fine. You're obviously not the person to be
designing our plugin API, then.

Old persnickety grey-bearded UNIX administrators aren't exactly a
significant or compelling market for music software. Perhaps for you and
me, using Lignux is a given, and doing music stuff is something you may
want to tinker with. For the overwhelmingly vast majority of people who
use music software, it is the other way around.

Put simply:

I don't care about portability == Nobody cares about my software.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

2011-02-22 Thread Philipp Überbacher

Excerpts from David Robillard's message of 2011-02-22 22:12:56 +0100:

--snip--

 Put simply:
 
 I don't care about portability == Nobody cares about my software.
 
 -dr

Simply not true. I do agree however that portability (==OS independence)
is a good idea for a plugin API. However, we all know that the currently
successful audio plugin APIs are OS dependent.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] the future of display/drawing models (Was: Re: [ANN] IR: LV2 Convolution Reverb)

On Tue, Feb 22, 2011 at 3:49 PM, Philipp Überbacher
hollun...@lavabit.com wrote:

 The rest sounds nice, and it might well be that X has become old, but I
 don't see the big improvement coming up. Windows are called surfaces
 now, can have different shapes and are more flexible, compositing,
 transformations, I got that bit, but I don't see the UI improvement.
 I've seen the demos with shapes flying around the desktop, I've seen
 the conventional compositing window managers and wayland will probably
 do all that and more, but I don't see the improvement in User
 Interfaces.

what its going to do,i think, is two-fold:

1) promote more and more toolkit design that makes everything just a
compositing stack. GTK has already moved significantly in this
direction, but could go a lot further. Qt is in a similar position.
the more this happens, the easier it is to reason and create new GUI
widgets that do cool things, easily and simply, because its all part
of a very simple model: you draw to your surface, it will be
composited onto the screen in ways that you don't have to worry about.
sounds a bit like X ... except that X is explicitly *not* a
compositing model. for a simpler explanation of the kind of thing i
mean, consider the difference in ardour between the main tracks area
of the editing window and all the widgets around it. its fundamentally
impossible to implement the tracks with widgets - it uses a canvas
object instead which embodies idea like z-axis stacking, transparency
and so forth. but likewise at present it would be a lot of work to
implement all the widgets as canvas items. now fast forward a few
years, and find a spot where the drawing model for the canvas, the
button widgets, the tree/listviews, for everything *inside* the
program is the same as the model for everything *outside* the program.
drawing a particular thing on any other thing becomes identical,
whether the other thing is a window, a button, a cell of a
listview, etc, etc.

2) more and more apps able to take advantage of v-blank sync to reduce
computational load due to unnecessary redraws. instead, the whole
system will be a lot like a video-framebuffer version of JACK: the
vblank interrupt arrives. everything with a surface gets a chance to
redraw if it needs to, the surfaces are composited together, and boom,
its on the display. no more guessing how often to redraw stuff, no
more wierd ass hacks to get smooth animation, etc. if you think this
sounds like special effects, i suggest a few minutes playing with a
relevant iPod/iPhone/iPad app where these smooth transformations of
what is on the screen is a central metaphor in how the UI's work.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

2011-02-22 Thread Devin Anderson

On Tue, Feb 22, 2011 at 1:11 PM, Nick Copeland
nickycopel...@hotmail.com wrote:

 This list as far as I can remember has always been full of righteous
 opinions, and by pretty much all of its subscribers, Paul.

I think you're projecting.  I love what you do for the audio
community, but your demeaning behavior makes you look like an ass.
Please stop.

-- 
Devin Anderson
devin (at) charityfinders (dot) com

CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Jörn Nettingsmeier


On 02/22/2011 01:45 PM, Nick Copeland wrote:

  ATM it doesn't even provide network transparency. Which means you can't
  even do the equivalent of ssh -X.

Does anybody even use this feature anymore?



fwiw, 50% of my audio work happens on a laptop that i use to ssh into my 
audio workstation. (i find a laptop with wlan to be the tranzport as god 
intended it to be :-D).


about 80% of the unix systems administration i have done in the past 
happened over ssh, and i always had xforwarding enabled to be able to 
quickly start xosview or other metering tools.


x bashing is all very cool, but it's what we have and it works.

i wonder:  you are obviously willing to design for future graphical 
abstraction layers which are not yet available. good, but possibly a lot 
of extra (guess-)work. will it be that much worse to just design for x11 
today, and invest some extra work to port to future graphics layers in a 
few years? well-designed software should be easy to port to new 
graphical paradigms, and being lazy today prevents over-engineering.
heck, if your software kicks ass, chances are other people will do the 
porting ;)


fons is obviously being grumpy, but i can't help noticing that we've had 
an awful lot of innovation in linux lately that may or may not prove 
useful in the long term, but it definitely did invalidate a lot of 
sysadmin expertise. nobody seems to be factoring that into the equation.
and it's definitely true that most of the innovative replacements to 
traditional unix mechanisms we have seen are focusing on single-user 
desktop or mobile computing. if your usecase differs, you get many 
headaches without much tangible benefit.


so hooray for getting rid of decades of x11 cruft, but let's not throw 
out the baby with the bathwater (even though it's biodegradable).

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] IR: LV2 Convolution Reverb

2011-02-22 Thread Jörn Nettingsmeier


On 02/22/2011 10:12 PM, David Robillard wrote:

As far as I am concerned, this is all about Libre audio software anyway,
and I disagree with the name of this list/site (who actually cares about
the specific kernel?). Getting e.g. OSX people on board is a part of
making the LAD 'platorm' a success. If people on proprietary platforms
start using free plugins, and they start using free hosts, eventually
they're using free everything (e.g. a Jack/LV2 based music platform) and
that's when they can switch to Lignux. Otherwise, they simply won't, and
that is obviously not a win for LAD, Linux, Open Source, GNU, Free
Software, or whatever label you prefer to rally behind.


agreed.


Maybe you don't care. Fine. You're obviously not the person to be
designing our plugin API, then.

Old persnickety grey-bearded UNIX administrators aren't exactly a
significant or compelling market for music software. Perhaps for you and
me, using Lignux is a given, and doing music stuff is something you may
want to tinker with. For the overwhelmingly vast majority of people who
use music software, it is the other way around.

Put simply:

I don't care about portability == Nobody cares about my software.


compelling argument, but not totally true. i'm not really disagreeing 
with your earlier statements, but i think there are some interesting 
aspects to the old greybearded unix wizard approach that fons apparently 
stands for.


here's a bunch of software that uses static, totally non-cross-platform 
makefiles that won't work out-of-the-box on 90% of all architectures.

but they are dead easy to fix.
it uses a custom x11 toolkit, custom thread library wrapper, and other 
idiosyncrasies. but it doesn't depend on sixteen other packages. which 
actually makes the stuff quite portable to osx, if you are willing to 
run x11 on top of it, without going through dependency hell.
it has one heck of a large userbase, and some parts are considered 
reference implementations in their respective fields.

it also tends to just work.

i guess the argument is grand-unified-abstraction-meta-api vs. 
potentially limited but _focused_ software.
you can use a rack full of kickass midi gear with crossbars, mappers, 
generic controllers, whatnot. or you can have a hot soldering iron at 
the ready on top of your organ at all times and just rewire it as needed :)


the former approach will impose fewer limitations. but the latter allows 
you to make some noise right now.

both are very valid imho.




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] the future of display/drawing models (Was: Re: [ANN] IR: LV2 Convolution Reverb)

On Tue, Feb 22, 2011 at 04:38:05PM -0500, Paul Davis wrote:

 what its going to do,i think, is two-fold:
 
 1) promote more and more toolkit design that makes everything just a
 compositing stack. GTK has already moved significantly in this
 direction, but could go a lot further.
 

Makes perfect sense. And indeed X is old, large parts of it 
have become more or less useless, and there is certainly room
for something new. If and when that arises and gets 50% of the
maturity of X then I'll be happy to use it. Meanwhile I see no
reason to do so, certainly not if the only thing gained is to
make my software run on smartphones and other toys. It's just
not meant for that market.

 2) more and more apps able to take advantage of v-blank sync to reduce
 computational load due to unnecessary redraws. instead, the whole
 system will be a lot like a video-framebuffer version of JACK: the
 vblank interrupt arrives. everything with a surface gets a chance to
 redraw if it needs to, the surfaces are composited together, and boom,
 its on the display.

Two remarks on this:

1. Syncing updates to the video frame rate of course makes sense,
and there is no reason why it couldn't be done in X. All it takes
is some support from the driver to generate an event at the right
time.

2. But at the same time this is sort of backwards. There is no reason
today why a computer display should be driven by a 'video' signal that
refreshes the complete screen at a fixed rate. *That* itself is very
old technology and completely useless in this age.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Paul Giblock

Dave,

I do some work in Qt. Primarily helping to port Lmms to Qt4.  I am now
working on a successor. This host is in Qt4 and uses lv2 as the primary
plugin api. I desire embedded plugins, so this topic is close to my heart.

Anyways, I would name the URI after Qt4 instead of simply Qt. Qt breaks some
ABI compatibility in major releases. So, including the 4 in the name should
protect us when 5 is released.

Regards
Paul
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

2011-02-22 Thread Philipp Überbacher

Excerpts from David Robillard's message of 2011-02-22 21:28:03 +0100:
On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote:
2011/2/22 David Robillard d...@drobilla.net:
On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
[...]
Hi David,

As a plugin developer, I'm very much looking forward to this,
especially since I proposed something similar to this a bit ago
(http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
:) But the fact that you're capable and willing to implement this
solution means a lot more than my confused half-baked ideas. I look
forward to the day when embedding and cross-toolkitedness walk hand in
hand.

In this case, we have a tricky enough complexity that we don't want it
duplicated in all the hosts either, so a library is definitely the way
to go. I call it Suil :)

I didn't follow the whole discussion, but I just want to toss out one
not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
at YUI.

I don't think it's stupid at all. Saying using browser technology for UI
is stupid these days is the height of short-sightedness. That's clearly
where everything is headed.

I disagree, it is short-sightedness. It's hard to miss that this is the
current hype, but this doesn't mean it's a good idea.

Again I disagree, in my opinion web UIs have exactly one benefit and
many drawbacks. The benefit is that they can be accessed from anywhere
with an internet connection and sufficiently capable browser (which is
pretty much everywhere these days) without installing anything. The
drawbacks are too many to list really but I'll try to show some with an
example or two:

Example number one is the CUPS web interface, accessible using the
obvious address http://localhost:631. First of all it gives me the
creeps every time I have to use it, because I have to use the browser to
modify my system. I even have to type in my root password. Yes, typing
the root password into some browser popup
(http://www.cups.org/articles.php?L274). I know that the web is a big
and scary place and that the browser is the way to access it, and that
it's a big pile of crap full of bugs and security vulnerabilities. The
barrier between the big scary web and root seems to be very very low.
Besides that the interface is slow and buggy, despite running on the
same machine. I wouldn't call it a good interface in general.

The other example is google docs/spreadsheet which I have to use
sometimes. There are the obvious privacy concerns, it should be clear
that giving your possibly sensitive data to what's probably the worlds
biggest Ad company isn't a good idea. They basically own the web these
days, they want you to do everything on the web, they know how to create
web UIs, and that's why this example is so good. It shows that the
browser, besides being a huge security and privacy problem, also gets in
the way of the user interface. You want keyboard shortcuts to make your
life easier? Forget it, chances are the browser will chew them, all you
get is the mouse. Right-click somewhere and you most likely get
completely nonsensical options, your browsers default, made for web
pages. Scrolling a few rows shouldn't be a problem, but try it and see
it stutter along. Trying to squish a program into a program that was
made for viewing web pages simply is a bad idea, the user experience
won't ever be great.
Accessibility? Forget it, text browser don't do JS. Sorry, I could rant
on forever. Web UIs have their uses but I simply don't thing they're a
good idea in general.

Google do it because their business model is deeply rooted in the web,
others do it because it's the current hype.

--snip--

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] the future of display/drawing models (Was: Re: [ANN] IR: LV2 Convolution Reverb)

On Tue, Feb 22, 2011 at 5:11 PM, Fons Adriaensen f...@linuxaudio.org wrote:
 On Tue, Feb 22, 2011 at 04:38:05PM -0500, Paul Davis wrote:

 what its going to do,i think, is two-fold:

 1) promote more and more toolkit design that makes everything just a
 compositing stack. GTK has already moved significantly in this
 direction, but could go a lot further.
 

 Makes perfect sense. And indeed X is old, large parts of it
 have become more or less useless, and there is certainly room
 for something new. If and when that arises and gets 50% of the
 maturity of X then I'll be happy to use it.

this model is actually already about as old as X. from my perspective
Display PostScript is a precursor to all these new ideas, in some deep
sense. as for the technology involved, most of wayland is evolving
alongside X, rather than separately, since they share GPU drivers etc.
etc., and toolkits like Qt and GTK simply come with different
backends. you could run more or less any GTK app on a wayland display
right now, and most of the issues will be identical to issues with the
app on other display platforms. there really isn't going to be a
catchup period - more of a co-evolution accompanied (probably) by a
slow drift of more and more basic platform technologies to a
wayland-style model. an awful lot of the maturity in X relates to
the network model and things like ICCCM, rather than the drawing 
event models, which were finalized in very closed to finished form a
long long time ago and didn't really require much maturation. wayland
drops the network model, and right now i forget quite how it handles
the sorts of issues that ICCCM addresses.

 2. But at the same time this is sort of backwards. There is no reason
 today why a computer display should be driven by a 'video' signal that
 refreshes the complete screen at a fixed rate. *That* itself is very
 old technology and completely useless in this age.

very true. on the other hand, think of it as an equivalent of a
non-periodic, but still completely synchronous version of JACK. the
timing can come from applications own needs rather than the h/w, but
having a central dispatcher avoids some of the ugliness that people
dealing with video and animation have faced with X from the beginning.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] On LAD (WAS: Re: [OT] IR: LV2 Convolution Reverb)

Unless you're interested in a long-winded rant mostly about me and my
perspective on LAD in general, skip this one. Otherwise, here goes:

On Tue, 2011-02-22 at 22:31 +0100, Philipp Überbacher wrote:
 Excerpts from David Robillard's message of 2011-02-22 22:12:56 +0100:
 
 --snip--
 
  Put simply:
  
  I don't care about portability == Nobody cares about my software.
  
  -dr
 
 Simply not true.

Maybe not true with blinders on, pretending that this community is
actually a significant portion of musicdom and not the tiny niche of
nerdery that is really is.

How many music events have you been to? At how many did you see Linux
being used?

How many albums have you listened to? How many were produced with Linux?

How many music producers do you know? How many use Linux?

For the vaast majority of music people out there the answers to each
of these are lots and almost none (or what's Linux?).

Sure, people here obviously care - but people here are an insignificant
shred of musicdom, and designing tech exclusively for that insigificant
shred of musicdom is... well, insignificant.

Maybe you'd consider LAD a success because some bedroom nerd made a bonk
he thinks is neat. Fair enough - most of us, myself included, are such
bedroom dorks. If, however, you're going to invest a LOT of time into
this (like, dedicate my life to kind of time), the bar needs to be set
a little higher to justify it:

I will consider LAD a success when going to a show and seeing it being
used isn't an extremely unlikely and noteworthy occurrence like it is
now.

I want to see/hear Ardour on a regular basis - not Ableton and Logic.

I want to see innovation in Ingen on a regular basis - not Max/MSP.

I want to see/hear LV2 plugins on a regular basis - not VST and AU.

I have no problem describing the current situation where the
overwhelming majority of music producers have absolutely no idea what
any of this technology even is as nobody cares. I love Lignux nerdery
as much as the next guy who grew up in it, but in the greater world of
musicdom, we are, alas, still nobody.

Do I personally want to deal with porting things to OSX or Windows? Hell
no (though I may start soon, for the reasons below). Is it important to
be sure that somebody can, and would it be a good thing if they do? Hell
yes.

Also, from the perspective of a developer trying to actually support
themselves doing this, a handful of bedroom Linux audio nerds do not
donate enough to pay the rent ;). Convincing yourself that working
exclusively for the handful of nerds on this list is unsustainable (both
economically and psychologically). Former LAD developers working in
cubes on Enterprise Java do not write LAD software any more :)

  I do agree however that portability (==OS independence)
 is a good idea for a plugin API. However, we all know that the currently
 successful audio plugin APIs are OS dependent.

Bingo. LV2 is competing with audio plugin APIs that /are/ portable, and
it will never successfully compete with them unless/until it is as well.
Lignux will never replace OSX as The music production platform until our
plugin technology is at least as capable. A plugin that only works on
Lignux is a plugin you're probably never going to hear, is a plugin that
nobody cares about. Likewise for the plugin specification itself. The
end goal may be to get everyone here, but portability is a necessary
step along the way, or they'll just stick with what works. Right now,
though it pains me to say it, using Lignux to become a successful
producer is like trying to win the Tour de France on a plastic tricycle.
We're getting better all the time, which is definitely exciting, but
we're still a long way away.

Shouldn't we be working to make people care? Shouldn't we be working to
make the above a reality, replacing those closed and limiting
technologies with open alternatives, liberating artists? I sure think
so. I support some are more into programmatic wankery, or convincing
themselves they're super cool for running Unix since 1980, or...
whatever. Fair enough; enjoy your superior irrelevance.

All I know is that we now have real, actual, working plugins with MIDI
in/out, GUIs, waveforms, etc. and soon we'll have plugins doing things
VST couldn't dream of. Every single solitary line of code put into those
improvements to the LAD platform came out of non-hierarchical
cooperation of many  people, and nobody had to cram anything down anyone
else's throat to make it happen. The proof is in the pudding.

Of course, the pudding is never perfect. Right now we have a little
toolkit compatibility problem in practise, and that's going to be solved
with more of the same thing. That same thing that is the entire reason
we have a free OS at all - despite the peanut gallery.

We'll get there, sooner or later. Help, or - please - get out of the
way.

Apologies for taking things a bit meta and personal here, but at least
it's not a big pathetic ego war :) A little optimism and hope sure as

Re: [LAD] [ANN] IR: LV2 Convolution Reverb