13 Jan
2011
13 Jan
'11
7:37 p.m.
Hi all,
Standing on the shoulders of giants[*], I am pleased to announce the
public release of IR, a convolution reverb in the LV2 plugin format.
Released as free software under the GNU GPL, this easy to use plugin
has been created to open the fascinating world of convolution reverb
to Linux-based audio engineers. If you use Ardour to create, mix &
produce music, you will most probably want to check out this plugin.
Assorted features:
* Zero-latency operation
* Support for mono, stereo and 'True Stereo' (4-channel) impulses
* Realtime operation
* Very reasonable CPU consumption
* Maximum impulse length: 1M samples (~22 seconds @ 48kHz)
* Loads a large number of audio file formats
* High quality sample rate conversion of impulse responses
* Stretch control (via high quality SRC in one step integrated with
impulse loading)
* Pre-delay control (0-2000 ms)
* Stereo width control of input signal & impulse response (0-150%)
* Envelope alteration with immediate visual feedback: Attack
time/percent, Envelope, Length
* Reverse impulse response
* Autogain: change impulses without having to adjust 'Wet gain'
* Impulse response visualization (linear/logarithmic scale, peak & RMS)
* Easy interface for fast browsing and loading impulse responses
IR should work on Linux with Ardour 2.8.x (x >= 11) and 3.
For further info and source code download, please visit the plugin's
homepage: http://factorial.hu/plugins/lv2/ir
Thanks,
Tom
[*] Fons Adriaensen (zita-convolver), Erik de Castro Lopo (libsndfile,
libsamplerate)
9:59 p.m.
On 01/13/2011 09:38 PM, fons(a)kokkinizita.net wrote:
On Thu, Jan 13, 2011 at 07:37:21PM +0100, Tom Szilagyi
wrote:
Here too :-(
On both 2.8.11 and 3. I'm running 64-bit Ubuntu 10.04.
It crashes as soon as GUI opens, you can see something
for a short moment.
If I motify the ttl file for not using the GUI it does something:
At least the Dry meters are moving in Ardours native interface!
Hope to see IR at work soon ;-)
The screenshot looks really promising.
Ciao,
Michael
IR should work on Linux with Ardour 2.8.x (x>=
11) and 3.
Here it makes ardour 2.8.11 crash.
Ciao,
14 Jan
14 Jan
9:44 a.m.
Excerpts from Tom Szilagyi's message of 2011-01-13 19:37:21 +0100:
Hi all,
Standing on the shoulders of giants[*], I am pleased to announce the
public release of IR, a convolution reverb in the LV2 plugin format.
Released as free software under the GNU GPL, this easy to use plugin
has been created to open the fascinating world of convolution reverb
to Linux-based audio engineers. If you use Ardour to create, mix &
produce music, you will most probably want to check out this plugin.
Assorted features:
* Zero-latency operation
* Support for mono, stereo and 'True Stereo' (4-channel) impulses
* Realtime operation
* Very reasonable CPU consumption
* Maximum impulse length: 1M samples (~22 seconds @ 48kHz)
* Loads a large number of audio file formats
* High quality sample rate conversion of impulse responses
* Stretch control (via high quality SRC in one step integrated with
impulse loading)
* Pre-delay control (0-2000 ms)
* Stereo width control of input signal & impulse response (0-150%)
* Envelope alteration with immediate visual feedback: Attack
time/percent, Envelope, Length
* Reverse impulse response
* Autogain: change impulses without having to adjust 'Wet gain'
* Impulse response visualization (linear/logarithmic scale, peak & RMS)
* Easy interface for fast browsing and loading impulse responses
IR should work on Linux with Ardour 2.8.x (x >= 11) and 3.
For further info and source code download, please visit the plugin's
homepage: http://factorial.hu/plugins/lv2/ir
Thanks,
Tom
[*] Fons Adriaensen (zita-convolver), Erik de Castro Lopo (libsndfile,
libsamplerate)
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2.
11:29 a.m.
On 14 January 2011 09:44, Philipp Überbacher <hollunder(a)lavabit.com> wrote:
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2.
IR is not really Ardour specific. Its just that 1) it relies on two
basic LV2 extensions (listed on its homepage), one for the GTK UI and
the other for a close in-process coupling between the UI and the
plugin via shared memory. 2) I personally don't have any interest in
using other hosts. But if an LV2 host provides the required
extensions, the plugin should work fine.
Tom
11:05 p.m.
On Fri, Jan 14, 2011 at 11:29:06AM +0100, Tom Szilagyi wrote:
On 14 January 2011 09:44, Philipp Überbacher
<hollunder(a)lavabit.com> wrote:
Given how easy it is to embded a window from app B into one of app A
I wonder why LV2 (or any plugin standard) would bother with GUI-toolkit
specific extensions at all.
I just did a simple test:
* added a few lines (< 10) of code to jaaa,
* started Ardour and opened its 'Locations' window,
* and had jaaa running within it in seconds.
And that's wihout any cooperation from Ardour. A plugin could use
whatever X11 toolkit it likes and with minimal support from the host
do the same. Apart from that it would need some cooperation to transfer
data between the dsp code and the GUI, but this can be made almost
transparent to the host.
Ciao,
--
FA
There are three of them, and Alleline.
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2.
IR is not really Ardour specific. Its just that 1) it relies on two
basic LV2 extensions (listed on its homepage), one for the GTK UI and
the other for a close in-process coupling between the UI and the
plugin via shared memory. 2) I personally don't have any interest in
using other hosts. But if an LV2 host provides the required
extensions, the plugin should work fine. 
21 Feb
21 Feb
8:32 p.m.
On Fri, 2011-01-14 at 23:05 +0100, fons(a)kokkinizita.net wrote:
On Fri, Jan 14, 2011 at 11:29:06AM +0100, Tom Szilagyi
wrote:
It doesn't really, except where "extension" means a trivial thing that
literally just defines a URI for a particular toolkit.
On 14 January 2011 09:44, Philipp Überbacher
<hollunder(a)lavabit.com> wrote:
Given how easy it is to embded a window from app B into one of app A
I wonder why LV2 (or any plugin standard) would bother with GUI-toolkit
specific extensions at all.
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2.
IR is not really Ardour specific. Its just that 1) it relies on two
basic LV2 extensions (listed on its homepage), one for the GTK UI and
the other for a close in-process coupling between the UI and the
plugin via shared memory. 2) I personally don't have any interest in
using other hosts. But if an LV2 host provides the required
extensions, the plugin should work fine. I just did a simple test:
* added a few lines (< 10) of code to jaaa,
* started Ardour and opened its 'Locations' window,
* and had jaaa running within it in seconds.
And that's wihout any cooperation from Ardour. A plugin could use
whatever X11 toolkit it likes and with minimal support from the host
do the same. Apart from that it would need some cooperation to transfer
data between the dsp code and the GUI, but this can be made almost
transparent to the host.
This is currently a possibility, but it throws away the ability to do
things possible when the toolkits do match (notably embedding the GUI in
another window, such as the presets/etc bar ardour adds to the top). It
is also not portable (depends on X11), assumes the concept of "window"
always makes sense(*), and has other problems.
In other words, this is a perfectly valid _implementation_ choice, but a
very poor _interface_ to define for plugin UIs. See my other recent
reply in this thread for details.
Peace,
-dr
(* Think text-based UIs, UIs that draw to an existing drawable such as
Cairo or GL, etc)
9:56 p.m.
On Mon, Feb 21, 2011 at 02:30:25PM -0500, David Robillard wrote:
Embedding the GUI in whatever window you like (e.g. a channel strip)
is just the same thing. The changes I made to jaaa made it accept a
window ID instead of its own top level parent window. It could equally
well accept parameters that define a rectangle in a host's window. And
if the host doesn't trust the plugin not to go outside its assigned
area it can just create a window for the plugin to use and have peace.
I just did a
simple test:
* added a few lines (< 10) of code to jaaa,
* started Ardour and opened its 'Locations' window,
* and had jaaa running within it in seconds.
And that's wihout any cooperation from Ardour. A plugin could use
whatever X11 toolkit it likes and with minimal support from the host
do the same. Apart from that it would need some cooperation to transfer
data between the dsp code and the GUI, but this can be made almost
transparent to the host.
This is currently a possibility, but it throws away the ability to do
things possible when the toolkits do match (notably embedding the GUI in
another window, such as the presets/etc bar ardour adds to the top). It is also not portable (depends on X11),
I don't care about any system that doesn't support X11. I don't even
care about some that do.
assumes the concept of "window" always
makes sense(*),
If it doesn't you can create a window that makes sense, see above.
and has other problems.
Such as ?
Ciao,
--
FA
11:58 p.m.
On Mon, 2011-02-21 at 20:56 +0000, Fons Adriaensen wrote:
On Mon, Feb 21, 2011 at 02:30:25PM -0500, David
Robillard wrote:
Embedding the GUI in whatever window you like (e.g. a channel strip)
is just the same thing. The changes I made to jaaa made it accept a
window ID instead of its own top level parent window. It could equally
well accept parameters that define a rectangle in a host's window. And
if the host doesn't trust the plugin not to go outside its assigned
area it can just create a window for the plugin to use and have peace.
Which is why yours is a poor solution. It loses much, and gains little
if anything. Making a UNIX only plugin or UI is fine. Making a UNIX
only plugin API is (in this case) stupid.
You /can/ implement "I don't give a damn about anything but <toolkit
X>"
plugin UIs (or hosts) right now, by design. I have always strongly
advocated this. You can't, however, use some nonexistent authority to
force all the other developers to agree - many (and in this case
virtually all) don't. Try and make a monolithic kitchen sink plugin API
like that and watch as everyone outright rejects the entire thing
instead of little replaceable slivers of it...
Yours is a valid perspective for UI and host authors. It is a terrible
one from the API designer perspective. The good design lets you and
others work only with your preferred technology - and interoperate with
others with different tastes. This is possible, feasible, and makes
more developers and users happy. It is, in other words, an objectively
much better solution.
-dr
I just
did a simple test:
* added a few lines (< 10) of code to jaaa,
* started Ardour and opened its 'Locations' window,
* and had jaaa running within it in seconds.
And that's wihout any cooperation from Ardour. A plugin could use
whatever X11 toolkit it likes and with minimal support from the host
do the same. Apart from that it would need some cooperation to transfer
data between the dsp code and the GUI, but this can be made almost
transparent to the host.
This is currently a possibility, but it throws away the ability to do
things possible when the toolkits do match (notably embedding the GUI in
another window, such as the presets/etc bar ardour adds to the top). It is also not portable (depends on X11),
I don't care about any system that doesn't support X11. I don't even
care about some that do.
22 Feb
22 Feb
12:12 a.m.
On Mon, Feb 21, 2011 at 05:56:58PM -0500, David Robillard wrote:
Which is why yours is a poor solution. It loses much, and gains little
if anything. Making a UNIX only plugin or UI is fine. Making a UNIX
only plugin API is (in this case) stupid.
Here we clearly don't agree. The method I proposed allows any combination
of host and plugin toolkits, as long as the common factor is X11, and it
doesn't require the host or plugin to know about each others toolkits or
to link with them (which seems to be problem with existing plugins, see
other posts in this thread).
This excludes Windows (TM), but again, I couln't care less.
The only other alternative seems to be that each plugin is either
using the same toolkit as the host, or it becomes a separate app.
The latter doesn't scale. A real-life DAW session could easily have
a hundred plugins. I'm not waiting to see that work.
Ciao,
--
FA
It is also not portable (depends on X11),
I don't care about any system that doesn't support X11. I don't even
care about some that do. 
3:14 a.m.
On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen <fons(a)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".
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
it also excludes GL based systems, which to be perfectly honest appear
to be have been a MUCH better starting point if you writing a GUI at
any point in the last 12 years than X. i deeply regret not basing
ardour on a toolkit that sat on top of GL rather than X11 - GL is more
portable, and has lots of nice features that don't show up in a lot of
programs but are real nonetheless.
4 a.m.
On Mon, 2011-02-21 at 21:14 -0500, Paul Davis wrote:
On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
It also excludes framebuffer based toolkits (which Gtk can be), which is
a good solution for embedded stuff, or what we call "hardware" here in
music land... not to mention smart phones / tablets / etc, which at this
point is hilariously short-sighted to exclude at the outset.
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".
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 it also excludes GL based systems, which to be
perfectly honest appear
to be have been a MUCH better starting point if you writing a GUI at
any point in the last 12 years than X. i deeply regret not basing
ardour on a toolkit that sat on top of GL rather than X11 - GL is more
portable, and has lots of nice features that don't show up in a lot of
programs but are real nonetheless.
Yep.. boy do I wish I just did everything in GL...
-dr
1:18 p.m.
On Mon, Feb 21, 2011 at 09:14:31PM -0500, Paul Davis wrote:
On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
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.
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". 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
1:45 p.m.
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
2:07 p.m.
On 22 February 2011 13:45, Nick Copeland <nickycopeland(a)hotmail.com> wrote:
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.
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.
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
2:11 p.m.
On Tue, Feb 22, 2011 at 01:45:35PM +0100, Nick Copeland wrote:
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.
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. 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
2:46 p.m.
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.
Sarky today. My point is that a generation of users is used to not having to rely
on as banal and cumbersome a method as that offered by X11 to distribute their
processing - there are other ways it is being done.
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.
And you are busy putting down the initiatives that may offer an eventual alternative
by unencumbering themselves? So now who is proposing ignorant arguments? There
is a whole load of changes taking place at the moment and adopting them is going to
be more a effective solution than sitting there like King Canute.
Kind regards, nick.
2:50 p.m.
On Tue, Feb 22, 2011 at 8:46 AM, Nick Copeland
<nickycopeland(a)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
5:01 p.m.
On Tue, Feb 22, 2011 at 02:46:35PM +0100, Nick Copeland wrote:
How ?
Ciao,
--
FA
Fons, you are tripping up over your own arguments
here. Firstly you state that a
well written app should divorce itself from the underlying medium, then you are
arguing that they actually should be using the underlying X11 to be able to be a
distributed app.
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) ?
This is a contradiction
It isn't. X does abstract the HW. And even more.
and, for example, just because I know
about this app and how it works, bristol can work headless without X11 as it takes
an abstract transport layer in a similar way to the one you are arguing both for and
against. You simply do not need X11 for distributed processing or at least if you are
dependent on it then, as you state yourself, your solution is badly written.
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.
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.
Sarky today. My point is that a generation of users is used to not having to rely
on as banal and cumbersome a method as that offered by X11 to distribute their
processing - there are other ways it is being done.
7:33 p.m.
New subject: [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
8:48 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
On Tue, Feb 22, 2011 at 07:32:58PM +0100, 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.
Ciao,
--
FA
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.
9:36 p.m.
New subject: [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.
9:41 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
On Tue, Feb 22, 2011 at 3:36 PM, Nick Copeland
<nickycopeland(a)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?
10:11 p.m.
New subject: [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.
10:43 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
On Tue, Feb 22, 2011 at 1:11 PM, Nick Copeland
<nickycopeland(a)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/
9:59 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
On Tuesday 22 February 2011 21:36:11 Nick Copeland wrote:
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
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.
10:14 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
On Tue, 2011-02-22 at 19:48 +0000, Fons Adriaensen wrote:
On Tue, Feb 22, 2011 at 07:32:58PM +0100, 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.
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
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.
10:31 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
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.
23 Feb
23 Feb
2:10 a.m.
New subject: 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--
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 vaaaaaast 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 :)
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.
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
hell isn't going to hurt this place anyway. Anyway, talk is cheap, and
at the end of the day the ratio between actual decent work done and
amount of time spent irritating people on mailing lists says a lot about
any given developer. Mine has taken enough of a dent for one day; I'll
get back to that doing thing now.
Peace (really),
-dr
10:40 a.m.
New subject: On LAD (WAS: Re: [OT] IR: LV2 Convolution Reverb)
On 2/23/11, David Robillard wrote:
Lignux will never replace OSX as The music production
platform until our
plugin technology is at least as capable.
That makes it sound as if plug-ins were the only obstacle :) You
probably didn't intend to mean it :)
Also, the notion of replacing Mac with Linux is somewhat, er, weird.
Do we really do all this to get Mac out of theway, or do we do things,
because we happen to have our own ideas we want to try? I'd say. the
latter.
Other than that, completely agreed.
Alexandre Prokoudine
http://libregraphicsworld.org
11:29 a.m.
New subject: On LAD (WAS: Re: [OT] IR: LV2 Convolution Reverb)
Unless you're interested on somewhat more 'user-oriented' reflections
triggered by David's long-winded rant... :) also skip.
Not a real developer here, so some reflections from a more user-oriented
point of view maybe.
Excerpts from David Robillard's message:
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 vaaaaaast majority of music people out there the answers to each
of these are "lots" and "almost none" (or "what's
Linux?").
So what. Really. I don't think the point here is to conquer the
world.
Having switched to Linux for me was the best move I made for my musical,
technical and I should say personal experience. Is it a bit harder and
challenging than other environments at times? Maybe but who cares really.
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 personally consider this and the LAU communities great communities and
feel thankful to the hard work every developer puts in FLOSS audio
software each day. Sorry if it sounds rhetoric but I really think it.
The first 'full project' I did entirely in Linux was a big satisfaction
for me, and by the way the workflow *was* better than in windows (which
I used before) for me, all the credit for this cool software goes to the
developers and users communities. IMHO.
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 ;).
That's a tough and sensitive point to comment
on.. Let me just say that
for many musicians trying to do something 'different' the situation is
very similar and their day-jobs, which pay bills, often don't involve
music at all.
...
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?
Yes I personally think we
should... I try to advocate about FLOSS more
in practice by showing what can be done, than with words... It's not
easy, but slowly we'll get there I think. (and yes, I often do turn
compiz with all the cool desktop effects on at times when showing off)
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.
At a more basic level, imagining myself working without
JACK, with those
monolithic 'do it all' windows VST-clogged applications seems to me a
nightmare and I regret not having got into this sooner, especially when
I was a student-only and had much more free time than now.
We'll get there, sooner or later. Help, or -
please - get out of the
way.
He he :) yes
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
hell isn't going to hurt this place anyway. Anyway, talk is cheap, and
at the end of the day the ratio between actual decent work done and
amount of time spent irritating people on mailing lists says a lot about
any given developer. Mine has taken enough of a dent for one day; I'll
get back to that doing thing now.
People can skip the email if they don't want
to read it, and you even
put a disclaimer so.. ;)
Lorenzo.
22 Feb
22 Feb
11:10 p.m.
New subject: [OT] IR: LV2 Convolution Reverb
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.
6:06 p.m.
On Feb 22, 2011, at 4:45 AM, Nick Copeland wrote:
Of course. I very rarely even turn on the monitor of my linux box.
Usually
I'm using it via an 'ssh -X' session on my laptop, from the other
side of the
room, if not elsewhere in the house.
-Sean
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?
10:55 p.m.
On 02/22/2011 01:45 PM, Nick Copeland wrote:
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).
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?
22 Feb
22 Feb
2:46 p.m.
On Tue, Feb 22, 2011 at 7:18 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Mon, Feb 21, 2011 at 09:14:31PM -0500, Paul Davis
wrote:
it will not be able interact in a direct way with any windows created
with Cocoa.
On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
You can run X11 apps in OSX. So you can have the host side of a plugin
library that is an X11 client. 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". 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.
this was actually precisely my point. but you indicated that you
didn't care about anything that wasn't X11. my point was that X11 is
not an appropriate "abstraction" for this purpose, whereas what you
just described is.
ATM it doesn't even provide network transparancy. Which means you can't
even do the equivalent of ssh -X.
AFAIU, there are no plans for it to do so. Since X clients can be
hosted by a rootless X server running on top of Wayland, the plan is
to continue to allow X to be used when network transparency matters,
thus allowing Wayland to focus on a efficiently and productively
implementing a drawing/display/rendering model that doesn't make very
much sense across a network (in a word: compositing).
5:48 p.m.
Excerpts from Paul Davis's message of 2011-02-22 03:14:31 +0100:
On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
--snip--
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.
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".
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
5:57 p.m.
On Tue, Feb 22, 2011 at 11:48 AM, Philipp Überbacher
<hollunder(a)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
9:50 p.m.
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
<hollunder(a)lavabit.com> wrote:
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 :).
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 
7:54 p.m.
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
3:27 a.m.
On Mon, 2011-02-21 at 23:12 +0000, Fons Adriaensen wrote:
On Mon, Feb 21, 2011 at 05:56:58PM -0500, David
Robillard wrote:
Which is why yours is a poor solution. It loses much, and gains little
if anything. Making a UNIX only plugin or UI is fine. Making a UNIX
only plugin API is (in this case) stupid.
Here we clearly don't agree. The method I proposed allows any combination
of host and plugin toolkits, as long as the common factor is X11, and it
doesn't require the host or plugin to know about each others toolkits or
to link with them (which seems to be problem with existing plugins, see
other posts in this thread).
This excludes Windows (TM), but again, I couln't care less.
Yes, I do not agree that portability does not matter, and that X11
everywhere is an acceptable design choice. There is certainly no
shortage of people who don't agree with you on that one, including every
single developer who has implemented an LV2 host or UI, who have always
been free to do it that way ;) Market, spoken, etc.
So far, I see only cons to your solution. Are there pros?
It is also not portable (depends on X11),
I don't care about any system that doesn't support X11. I don't even
care about some that do. The only other alternative seems to be that each
plugin is either
using the same toolkit as the host, or it becomes a separate app.
The latter doesn't scale. A real-life DAW session could easily have
a hundred plugins. I'm not waiting to see that work.
It is obviously not useful to have hundreds of plugin UI windows open at
once anyway.
The real problem here is one of design, namely that all of this crap
needs to not be a burden on host and plugin authors. There is another
alternative, namely the one I have been describing (see my latest
replies to Rui in this thread).
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.
-dr
1:43 p.m.
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
6:52 p.m.
On Tue, 2011-02-22 at 12:43 +0000, Fons Adriaensen wrote:
On Mon, Feb 21, 2011 at 09:26:09PM -0500, David
Robillard wrote:
Bingo. You said yourself, "or the equivalent if the basic system is not
X". In other words, the UI API should not be X11 based. In other other
words, the UI API needs to be toolkit agnostic, which it is. Yay.
I fully agree with everything you have said here, otherwise.
-dr
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. 
15 Jan
15 Jan
1:22 p.m.
On Fri, 2011-01-14 at 09:44 +0100, Philipp Überbacher wrote:
Excerpts from Tom Szilagyi's message of 2011-01-13
19:37:21 +0100:
I'm a Qtractor user and I like Fon's reverb, excepted of it's GUI ;D.
I'll test this new convolution reverb ASAP with Qtractor. Sorry, I'm
short in time now ... perhaps somebody from the Qtractor mailing list
can test it ;). Huhu Rui :p.
Ralf
Hi all,
Standing on the shoulders of giants[*], I am pleased to announce the
public release of IR, a convolution reverb in the LV2 plugin format.
Released as free software under the GNU GPL, this easy to use plugin
has been created to open the fascinating world of convolution reverb
to Linux-based audio engineers. If you use Ardour to create, mix &
produce music, you will most probably want to check out this plugin.
Assorted features:
* Zero-latency operation
* Support for mono, stereo and 'True Stereo' (4-channel) impulses
* Realtime operation
* Very reasonable CPU consumption
* Maximum impulse length: 1M samples (~22 seconds @ 48kHz)
* Loads a large number of audio file formats
* High quality sample rate conversion of impulse responses
* Stretch control (via high quality SRC in one step integrated with
impulse loading)
* Pre-delay control (0-2000 ms)
* Stereo width control of input signal & impulse response (0-150%)
* Envelope alteration with immediate visual feedback: Attack
time/percent, Envelope, Length
* Reverse impulse response
* Autogain: change impulses without having to adjust 'Wet gain'
* Impulse response visualization (linear/logarithmic scale, peak & RMS)
* Easy interface for fast browsing and loading impulse responses
IR should work on Linux with Ardour 2.8.x (x >= 11) and 3.
For further info and source code download, please visit the plugin's
homepage: http://factorial.hu/plugins/lv2/ir
Thanks,
Tom
[*] Fons Adriaensen (zita-convolver), Erik de Castro Lopo (libsndfile,
libsamplerate)
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2.
1:30 p.m.
On Sat, 2011-01-15 at 13:22 +0100, Ralf Mardorf wrote:
On Fri, 2011-01-14 at 09:44 +0100, Philipp Überbacher
wrote:
Pardon :(, there already is a thread for the Qtractor list :(.
To be fair, latest version of Qtractor I tested (I won't reboot now,
from Dez or Jan), also crashed when closing fluidsynth-dssi GUI on my
Ubuntu Studio Lucid 64 bit.
-------- Forwarded Message --------
From: Jeremy Jongepier <jeremy(a)autostatic.com>
To: qtractor-devel(a)lists.sourceforge.net
Subject: Re: [Qtractor-devel] IR LV2 plugin qtractor crash on closing
GUI
Date: Fri, 14 Jan 2011 15:29:29 +0100
On 01/14/2011 02:23 PM, Jiří Procházka wrote:
Excerpts from Tom Szilagyi's message of
2011-01-13 19:37:21 +0100:
I'm a Qtractor user and I like Fon's reverb, excepted of it's GUI ;D.
I'll test this new convolution reverb ASAP with Qtractor. Sorry, I'm
short in time now ... perhaps somebody from the Qtractor mailing list
can test it ;). Huhu Rui :p.
Ralf Hi all,
Standing on the shoulders of giants[*], I am pleased to announce the
public release of IR, a convolution reverb in the LV2 plugin format.
Released as free software under the GNU GPL, this easy to use plugin
has been created to open the fascinating world of convolution reverb
to Linux-based audio engineers. If you use Ardour to create, mix &
produce music, you will most probably want to check out this plugin.
Assorted features:
* Zero-latency operation
* Support for mono, stereo and 'True Stereo' (4-channel) impulses
* Realtime operation
* Very reasonable CPU consumption
* Maximum impulse length: 1M samples (~22 seconds @ 48kHz)
* Loads a large number of audio file formats
* High quality sample rate conversion of impulse responses
* Stretch control (via high quality SRC in one step integrated with
impulse loading)
* Pre-delay control (0-2000 ms)
* Stereo width control of input signal & impulse response (0-150%)
* Envelope alteration with immediate visual feedback: Attack
time/percent, Envelope, Length
* Reverse impulse response
* Autogain: change impulses without having to adjust 'Wet gain'
* Impulse response visualization (linear/logarithmic scale, peak & RMS)
* Easy interface for fast browsing and loading impulse responses
IR should work on Linux with Ardour 2.8.x (x >= 11) and 3.
For further info and source code download, please visit the plugin's
homepage: http://factorial.hu/plugins/lv2/ir
Thanks,
Tom
[*] Fons Adriaensen (zita-convolver), Erik de Castro Lopo (libsndfile,
libsamplerate)
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2. Hi Tom,
first I have to say thanks for the awesome plugin, it is the best of
convolution tools I used and very good both performance and UI-wise.
I use qtractor and unfortunatly when closing the GUI, qtractor crashes.
I am using the plugin version 1.0, qtractor 0.4.7.68 (latest svn, dubbed
'qq' in my system) compiled with --enable-debug gives following output
on closing the GUI window, hope it will help to solve the issue (which
doesn't happen with Calf LV2 GUI plugins):
Same here with Qtractor 0.4.7.68 :(
The plug-in does work well but crashes when I close its GUI.
This is on a 32-bits system btw.
Best,
Jeremy
1:56 p.m.
On Sat, 2011-01-15 at 13:30 +0100, Ralf Mardorf wrote:
On Sat, 2011-01-15 at 13:22 +0100, Ralf Mardorf
wrote:
FWIW until now I used JACK2, because I had issues with JACK1, but for
this install I used latest official version of JACK1 + JACK session
support for Qtractor. Btw. fluidsynth-dssi always was a PITA for my
Qtractor installs, but last time it was über-annoying. So, perhaps it is
an issue for any plugs, LV2 and DSSI, regarding to some GUI libs?!
On Fri, 2011-01-14 at 09:44 +0100, Philipp
Überbacher wrote:
Pardon :(, there already is a thread for the Qtractor list :(.
To be fair, latest version of Qtractor I tested (I won't reboot now,
from Dez or Jan), also crashed when closing fluidsynth-dssi GUI on my
Ubuntu Studio Lucid 64 bit. Excerpts from Tom Szilagyi's message of
2011-01-13 19:37:21 +0100:
I'm a Qtractor user and I like Fon's reverb, excepted of it's GUI ;D.
I'll test this new convolution reverb ASAP with Qtractor. Sorry, I'm
short in time now ... perhaps somebody from the Qtractor mailing list
can test it ;). Huhu Rui :p.
Ralf Hi all,
Standing on the shoulders of giants[*], I am pleased to announce the
public release of IR, a convolution reverb in the LV2 plugin format.
Released as free software under the GNU GPL, this easy to use plugin
has been created to open the fascinating world of convolution reverb
to Linux-based audio engineers. If you use Ardour to create, mix &
produce music, you will most probably want to check out this plugin.
Assorted features:
* Zero-latency operation
* Support for mono, stereo and 'True Stereo' (4-channel) impulses
* Realtime operation
* Very reasonable CPU consumption
* Maximum impulse length: 1M samples (~22 seconds @ 48kHz)
* Loads a large number of audio file formats
* High quality sample rate conversion of impulse responses
* Stretch control (via high quality SRC in one step integrated with
impulse loading)
* Pre-delay control (0-2000 ms)
* Stereo width control of input signal & impulse response (0-150%)
* Envelope alteration with immediate visual feedback: Attack
time/percent, Envelope, Length
* Reverse impulse response
* Autogain: change impulses without having to adjust 'Wet gain'
* Impulse response visualization (linear/logarithmic scale, peak & RMS)
* Easy interface for fast browsing and loading impulse responses
IR should work on Linux with Ardour 2.8.x (x >= 11) and 3.
For further info and source code download, please visit the plugin's
homepage: http://factorial.hu/plugins/lv2/ir
Thanks,
Tom
[*] Fons Adriaensen (zita-convolver), Erik de Castro Lopo (libsndfile,
libsamplerate)
Is it really ardour-specific? Would be a pity.
I'm aware that there's a lack of hosts, but if it's already so bad
that a plugin is only supported in a single host, well, good night LV2.
14 Jan
14 Jan
9:29 p.m.
Hi all,
after a day of intense work and testing, I present you a corrected
version of IR. Version 1.1 contains these important fixes:
* really use the user's homedir for storing the .ir_save file
* proper GType and GThread initialization, at the proper place
(loading of the plugin shared library)
* fix ir.ttl: add missing namespace prefix "rdf"
* fix usage of zita-convolver (proper stopping and deallocating of
Convproc instances). Thank you Fons for checking out my code and
instructing me.
* fix crash when removing a never-unbypassed plugin instance
There are two known issues with IR 1.1:
* When a plugin instance is created bypassed in Ardour (for example
when copy&pasting from another IR instance), you have to un-bypass the
new instance to be able to configure it.
* Removing a plugin instance from Ardour while the plugin is in the
middle of a lengthy resampling operation (waveform display reads
"Loading" or "Calculating") will crash. It is easy to avoid this;
please do so. A fix for this is planned in a future version of IR.
Regarding LV2 hosts other than Ardour: the second in the above list of
fixes should help, however please be aware that IR is at the moment
really not usable without its own GTK UI. In future versions I may
manage to switch to using an external-process LV2 UI which would
result in the plugin UI being completely host toolkit agnostic.
Please, by all means upgrade to this new version. It is downloadable
from the same location as before: http://factorial.hu/plugins/lv2/ir
I would like to thank everyone for the overwhelming feedback, both on-
and offlist.
Thanks,
Tom
9 Feb
9 Feb
5:50 p.m.
On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi wrote:
Hi all,
after a day of intense work and testing, I present you a corrected
version of IR. Version 1.1 contains these important fixes:
* really use the user's homedir for storing the .ir_save file
* proper GType and GThread initialization, at the proper place
(loading of the plugin shared library)
* fix ir.ttl: add missing namespace prefix "rdf"
* fix usage of zita-convolver (proper stopping and deallocating of
Convproc instances). Thank you Fons for checking out my code and
instructing me.
* fix crash when removing a never-unbypassed plugin instance
There are two known issues with IR 1.1:
* When a plugin instance is created bypassed in Ardour (for example
when copy&pasting from another IR instance), you have to un-bypass the
new instance to be able to configure it.
* Removing a plugin instance from Ardour while the plugin is in the
middle of a lengthy resampling operation (waveform display reads
"Loading" or "Calculating") will crash. It is easy to avoid this;
please do so. A fix for this is planned in a future version of IR.
Regarding LV2 hosts other than Ardour: the second in the above list of
fixes should help, however please be aware that IR is at the moment
really not usable without its own GTK UI. In future versions I may
manage to switch to using an external-process LV2 UI which would
result in the plugin UI being completely host toolkit agnostic.
FWIW, I would not do this. The external UI extension is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...
The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
-dr
(* and it has recently come up that it seems impossible to get certain
window related things right with the current scheme...)
8:59 p.m.
On 02/09/2011 04:49 PM, David Robillard wrote:
On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi
wrote:
your words, Dave, are wise, but... until that (yours?) lib gets ever
real, the lv2-external-ui extension won't ever be wrong. sorry to tell
what has, and still is, outrageously wrong is that utter cannot-say-what
stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
lock-in disease--mostly due on ardour being a top reference as a plugin
host, nevermind being a gtk based one (and damn good at several other
things too;)
please, don't give me nice talks about xembed and that stuff about gtk
and qt widgets being reciprocally embeddable. it just doesn't work for
the masses. well, in practice, unless you're in some kind ivory tower
and aim for a very special case or tight coupled application, that is...
im kind of serious on this stuff. i've been there, done that, and
failed--you guess where :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Regarding LV2 hosts other than Ardour: the second in the above list of
fixes should help, however please be aware that IR is at the moment
really not usable without its own GTK UI. In future versions I may
manage to switch to using an external-process LV2 UI which would
result in the plugin UI being completely host toolkit agnostic.
FWIW, I would not do this. The external UI extension is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...
The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
21 Feb
21 Feb
8:22 p.m.
On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:
On 02/09/2011 04:49 PM, David Robillard wrote:
Just because something right has not been implemented does not mean the
existing thing is right... (as your Gtk gripes illustrate)
Yes, clearly right now (excluding actually implementing the library),
using it is the pragmatic decision if you want a UI that works in a host
of any toolkit (and you don't need to embed UIs). This situation,
however, is crap, and needs fixing.
On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi
wrote:
your words, Dave, are wise, but... until that (yours?) lib gets ever
real, the lv2-external-ui extension won't ever be wrong. sorry to tell
Regarding LV2 hosts other than Ardour: the second in the above list of
fixes should help, however please be aware that IR is at the moment
really not usable without its own GTK UI. In future versions I may
manage to switch to using an external-process LV2 UI which would
result in the plugin UI being completely host toolkit agnostic.
FWIW, I would not do this. The external UI extension is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...
The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
what has, and still is, outrageously wrong is that
utter cannot-say-what
stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
lock-in disease--mostly due on ardour being a top reference as a plugin
host, nevermind being a gtk based one (and damn good at several other
things too;)
What? The LV2 UI extension is toolkit agnotic. It is not gtk based
whatsoever. Permit me a bit of yelling for emphasis:
PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK
BASED, OR BASED ON ANY OTHER TOOLKIT. IT IS NOT, HAS NEVER BEEN, AND
NEVER WILL BE.
Sure, you (as a Qt person) don't like that most existing UIs happen to
have been implemented in Gtk. This is a problem with how we have
implemented UIs though, and not a problem with the UI extension itself.
That is, this is precisely the sort of problem that shows we need a
library to abstract this stuff (i.e. you are perfectly free to implement
Qt UIs, but then Gtk host authors have the same gripes).
I fully agree host authors should not have to deal with this (I
certainly don't want a bunch of Qt crap in my Gtk hosts either), that's
the entire point. I take it further and don't believe plugin UI authors
should have to deal with it either.
We can get all the wins without:
* Throwing out UI embedding, which really sucks for a lot of potential
UI designs (window hell sucks).
* Forcing a particular toolkit, which will inevitably piss off everyone
who doesn't like that particular toolkit, again really suck for a lot of
potentially neat UI designs, and thus severely hurt adoption
* Making plugin or host authors
Why throw out nice things if we don't have to? Kludges in
implementations are fine, but kludges that affect what interfaces we
cooperate using are dangerous, particularly in the long term...
please, don't give me nice talks about xembed and
that stuff about gtk
and qt widgets being reciprocally embeddable. it just doesn't work for
the masses. well, in practice, unless you're in some kind ivory tower
and aim for a very special case or tight coupled application, that is...
I am told it can work these days, unlike in the past. Torben has some
experiments along those lines that work for him and at least some
others, but one direction (I can't remember which) didn't work for me.
Maybe it is indeed unrealistic, at least in some situations. It doesn't
really matter regardless, the design decision of where the
embed/external/whatever stuff belongs is orthogonal.
In other words, maybe embedding toolkit X in toolkit Y can work, maybe
it can not. I am not sure, nor do I really care so much. My point is
definitely not that we should all depend on cross-toolkit embedding
working; the important point is that this problem (e.g. using a Gtk UI
in a Qt host) needs solving once, not a million kludgey times in every
host and UI implementation.
I do intend to write said library myself soon (I don't often talk about
what I/we "will" do, but this is something of an LV2 UI state of the
union). It is a high, but not top, priority for me right now (somewhere
after releasing LV2r4, the new librdf-free slv2, and the LV2 persist
extension).
The important part, that I am suggesting very much needs doing ASAP, is
that getting a library interface implemented, so people can start using
it. This does not depend on making embedding working, since the
fallback will be making an external windows. We simply need something
like (obviously a simplification):
OpaqueWidget
lv2_ui_lib_load(ToolkitType requested_toolkit,
UI plugin_ui)
Which will return a widget of the requested toolkit type, regardless of
the toolkit the UI is implemented. There's a few possibilities:
1) Hooray, the toolkits match, and this will directly return the UI
widget, which you can embed or do whatever else you want with.
2) The toolkits do not match, and the library can implement
cross-toolkit embedding. This will return a widget in the requested
toolkit that from the caller's perspective is the same as case 1.
3) The toolkits do not match, and cross-toolkit embedding is not
possible. This will do the external UI thing (i.e. make a window, and
return a corresponding widget).
There are, in general, the 3 cases. The jist of the current problem is
that implementers must make a decision that mandates an interface on
other implementers. The library will make this problem go away, and
make these cases implementation details as they should be.
This is very much a pragmatic path, and not at all an ivory tower / pie
in the sky situation: whether or not a case (particularly 2) can work in
a given situation doesn't really matter - we have gained graceful
degradation and interface stability. The first version will simply
implement cases 1 and 3 - providing the interface is the important part
that will solve the pressing problems with this situation.
Hopefully someone will figure out and contribute case 2, but this is not
a pressing (i.e. API related / community fragmenting) problem - just a
nicety.
Peace,
-dr
9:27 p.m.
On 02/21/2011 07:20 PM, David Robillard wrote:
On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela
wrote:
Dave,
please,
you certainly know that most lv2 gtk plugins out there do break this
whole "agnostic" paradigm--tell me one which doesn't? yep. the ones on
lv2_external_ui. shall i rest my case? no.
if you look closer most of those ill-behaved lv2 gtk plugins, the ones i
brag about, are committing the mortal sin of realizing a gtk(mm) widget,
hardly Xembed-dable. look, it's not even a toplevel window for X sake
(nb. the X is for X, not for Christ)--this seems to be a gross mistake
from all early lv2 ui extension times when most people involved just
wanted to pull up a proof-of-concept gui or something. it turned out the
code base has spread like amoeba (i'm avoiding "viral" intentionally:)
i'm not, and never was, against plugin developers doing their guis with
whatever toolkit they like. it's just that the way they've been doing,
and i suspect spreading like a "copy-paste" anti-pattern somehow, is a
lot more wrong than using Nedko's lv2_external_ui extension.
alas, for some reason, calf and linuxdsp are using it and with great
success. should i say more? maybe not.
anyway, i do acknowledge and really do empower your ideas, which i also
believe will get to a better solution. i just don't take it so lightly,
just like you said, like a "Qt guy" shoudln't -- yes, our notion of
"crap" is reciprocal, trust me ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 02/09/2011 04:49 PM, David Robillard wrote:
Just because something right has not been implemented does not mean the
existing thing is right... (as your Gtk gripes illustrate)
Yes, clearly right now (excluding actually implementing the library),
using it is the pragmatic decision if you want a UI that works in a host
of any toolkit (and you don't need to embed UIs). This situation,
however, is crap, and needs fixing.
On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi
wrote:
your words, Dave, are wise, but... until that (yours?) lib gets ever
real, the lv2-external-ui extension won't ever be wrong. sorry to tell
Regarding LV2 hosts other than Ardour: the second in the above list of
fixes should help, however please be aware that IR is at the moment
really not usable without its own GTK UI. In future versions I may
manage to switch to using an external-process LV2 UI which would
result in the plugin UI being completely host toolkit agnostic.
FWIW, I would not do this. The external UI extension is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...
The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
what has, and still is, outrageously wrong is
that utter cannot-say-what
stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
lock-in disease--mostly due on ardour being a top reference as a plugin
host, nevermind being a gtk based one (and damn good at several other
things too;)
What? The LV2 UI extension is toolkit agnotic. It is not gtk based
whatsoever. Permit me a bit of yelling for emphasis:
PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK
BASED, OR BASED ON ANY OTHER TOOLKIT. IT IS NOT, HAS NEVER BEEN, AND
NEVER WILL BE.
Sure, you (as a Qt person) don't like that most existing UIs happen to
have been implemented in Gtk. This is a problem with how we have
implemented UIs though, and not a problem with the UI extension itself.
That is, this is precisely the sort of problem that shows we need a
library to abstract this stuff (i.e. you are perfectly free to implement
Qt UIs, but then Gtk host authors have the same gripes).
9:32 p.m.
On Mon, Feb 21, 2011 at 3:27 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
alas, for some reason, calf and linuxdsp are using it
and with great
success. should i say more? maybe not.
well, yes and no. notice that its not possible to embed the plugin
UIs, which is something we even manage to do with Ardour on OSX, where
we're using GTK and the plugins are using Cocoa or Carbon. this seems
like a bit of a backwards step - here we are on a platform where we
control *all* the technology and we can't even get the plugin GUIs to
embed? shurely shome mishtake ...
11:53 p.m.
On 02/21/2011 08:32 PM, Paul Davis wrote:
On Mon, Feb 21, 2011 at 3:27 PM, Rui Nuno Capela
<rncbc(a)rncbc.org> wrote:
put it another way:
is there any lv2 plugin which is not using the lv2_external_ui extension
but is xembed-dable and please, do not force the host to link to libgtk
et al. and even show its gui?? i'd like to know :)
oh, and did i say that the gtkmm based ones are even crappier in that
regard? because it also forces you (host) to link to libgtkmm, which is
outrageously and utterly plain nuisance?
cya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
alas, for some reason, calf and linuxdsp are
using it and with great
success. should i say more? maybe not.
well, yes and no. notice that its not possible to embed the plugin
UIs, which is something we even manage to do with Ardour on OSX, where
we're using GTK and the plugins are using Cocoa or Carbon. this seems
like a bit of a backwards step - here we are on a platform where we
control *all* the technology and we can't even get the plugin GUIs to
embed? shurely shome mishtake ...
22 Feb
22 Feb
3:06 a.m.
On Mon, 2011-02-21 at 22:53 +0000, Rui Nuno Capela wrote:
On 02/21/2011 08:32 PM, Paul Davis wrote:
The UI simply provides a widget of some type (e.g. GtkWidget). Whatever
the host can/does with this is not a feature of the UI. Your question is
a bit misleading (it is obviously impossible to use a GtkWidget without
linking to Gtk). Technically the answer to your question is yes, since
it is possible to XEmbed a GtkWidget. If you mean to point out that the
current situation is inadequate, there's no disagreement there - there
is currently no good solution to that problem (i.e. hosts /can/ do it,
with a lot of work and code duplication, but this is not a good
solution). There is indeed a problem here, but it is a host-side one.
The question is /what/ should link to Gtk. You say not the host, and I
agree. We therefore need something in-between then host and the e.g. Gtk
UI implementation. There are two options:
* Throw out embedding and various other desirable features, and
re-implement this bridging in every single UI (the external UI
extension's strategy). Not everyone is happy: nice features become
impossible, and copy/paste code duplication is rampant.
* Keep all the desirable features when possible, gracefully degrade
when not, and implement this bridging once in a library. Everyone is
happy: anything possible is, uh, possible, proper code reuse means all
hosts work correctly for free, bugs/features need implementing once,
implementing a UI or UI support becomes much simpler (increasing
adoption), neither host nor UI authors need to care about cross-toolkit
compatibility, etc.
The latter is What Needs Doing. There is IMO no question about that,
it's all win. There are a few details to sort out, though:
The proposed library would inherently need to link to Gtk. This means
the host doesn't directly link to / depend on Gtk, but the library ends
up depending on all toolkits, so from a package perspective every host
ends up depending on every toolkit, which is no good. So, the library
will need to be implemented in several dynamically loaded modules
(ideally packaged separately). I think this is probably the way to go.
If even an indirect dynamic linkage like this is a problem (why?), then
a process based solution is also possible. This will probably be needed
for new stuff like UIs in other languages (e.g. python), remote/web UIs,
etc. I don't think doing it this way is wise/necessary for the current
crop of hosts/UIS, though (all C/C++), i.e. this is non-pressing future
work that shouldn't affect the library API.
On Mon, Feb 21, 2011 at 3:27 PM, Rui Nuno Capela
<rncbc(a)rncbc.org> wrote:
put it another way:
is there any lv2 plugin which is not using the lv2_external_ui extension
but is xembed-dable and please, do not force the host to link to libgtk
et al. and even show its gui?? i'd like to know :) alas, for some reason, calf and linuxdsp are
using it and with great
success. should i say more? maybe not.
well, yes and no. notice that its not possible to embed the plugin
UIs, which is something we even manage to do with Ardour on OSX, where
we're using GTK and the plugins are using Cocoa or Carbon. this seems
like a bit of a backwards step - here we are on a platform where we
control *all* the technology and we can't even get the plugin GUIs to
embed? shurely shome mishtake ... oh, and did i say that the gtkmm based ones are even
crappier in that
regard? because it also forces you (host) to link to libgtkmm, which is
outrageously and utterly plain nuisance?
The Gtkmm initialisation problem does suck(*), but linking to gtkmm is
no more outrageous than any other toolkit. Again, just another example
of why this all needs to be wrapped up in a library where we can solve
it once, correctly.
-dr
(* There is, however a simple solution I won't go into now that is also
useful for a few other similar situations)
21 Feb
21 Feb
11:41 p.m.
On Mon, 2011-02-21 at 20:27 +0000, Rui Nuno Capela wrote:
Dave,
please,
you certainly know that most lv2 gtk plugins out there do break this
whole "agnostic" paradigm--tell me one which doesn't? yep. the ones on
lv2_external_ui. shall i rest my case? no.
I said the LV2 UI extension is toolkit agnostic. It is - i.e. it
supports any toolkit.
I did not say all particular LV2 UIs are toolkit agnostic. They are
not. Many are implemented in Gtk, for example. This, however, is not
the problem (as we both agree, i.e. UI authors should be free to do so).
On 02/21/2011 07:20 PM, David Robillard wrote:
> On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:
[...]
what has, and still is, outrageously wrong is that
utter cannot-say-what
stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
lock-in disease--mostly due on ardour being a top reference as a plugin
host, nevermind being a gtk based one (and damn good at several other
things too;)
What? The LV2 UI extension is toolkit agnotic. It is not gtk based
whatsoever. Permit me a bit of yelling for emphasis:
PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK
BASED, OR BASED ON ANY OTHER TOOLKIT. IT IS NOT, HAS NEVER BEEN, AND
NEVER WILL BE.
Sure, you (as a Qt person) don't like that most existing UIs happen to
have been implemented in Gtk. This is a problem with how we have
implemented UIs though, and not a problem with the UI extension itself.
That is, this is precisely the sort of problem that shows we need a
library to abstract this stuff (i.e. you are perfectly free to implement
Qt UIs, but then Gtk host authors have the same gripes).
if you look closer most of those ill-behaved lv2 gtk
plugins, the ones i
brag about, are committing the mortal sin of realizing a gtk(mm) widget,
hardly Xembed-dable. look, it's not even a toplevel window for X sake
(nb. the X is for X, not for Christ)--this seems to be a gross mistake
from all early lv2 ui extension times when most people involved just
wanted to pull up a proof-of-concept gui or something. it turned out the
code base has spread like amoeba (i'm avoiding "viral" intentionally:)
Well, sure, but you can't say that not having LV2 UIs whatsoever would
be a good thing with a straight face. Nobody's claiming everything has
been done perfectly. I will, however, claim that the freedom for
developers to do their thing does result in real, actual, innovation,
and improvements in the 'LAD platform' that would not occur otherwise,
and history backs me up. That developers can do their proof of concept
implementations is certainly not a bad thing! It's a very, very good
thing, that has been shown to work.
Of course, this freedom comes at a cost, no argument there. We do
indeed need to revise how those proof of concepts were done (with the
benefit of the experience gained) from time to time. Sure beats not
being able to...
That's the cost - the reward is higher quality software (eventually),
more features, and all the well-known wins that come with
distributed/agile software development. Particularly in an open source
world, it's IMO a very wise trade-off.
Anyway, back to practical matters:
i'm not, and never was, against plugin developers
doing their guis with
whatever toolkit they like. it's just that the way they've been doing,
and i suspect spreading like a "copy-paste" anti-pattern somehow
I fully agree, which is why I just described my proposed solution to the
problem. Again, I don't tend to discuss such things on-list much (the
pointless direction of this discussion being evidence as to why), but
developers need to know a particular technology is not a
wise /long-term/ investment to make the best decisions, and the issue
came up, so...
, is a
lot more wrong than using Nedko's lv2_external_ui extension.
Well, no, because that extension threw out the baby with the bathwater,
and while it solved a pragmatic part of the problem in the short-term,
it made the serious long-term problem here (API) even worse in some
sense.
The problem is not how plugin authors have been doing their GUIs at all.
They have been, can, and still should, be implementing them in their
toolkit of choice, such as Gtk. The problem is that it was not
implemented correctly on the host side of things, and instead of solving
this problem once correctly and collectively (library), the external UI
extension kludge screwed up the UI API instead, put the solution in the
wrong place, forced that solution to be constantly re-implemented, and
further fragmented the community. Long term problem => alarm bells =>
fix needed.
Note that the problem here is not the LV2 UI extension, which will not
have to change(*). That it may be the pragmatic choice for plugin UI
authors right now does not change the fact that the external UI
extension was (objectively and without malice) the design screw-up here.
Fair enough, the ability to try and screw it up is a part of that
freedom. I've certainly screwed up my fair share as well. Live and
learn... and revise :)
-dr
(* Which, by the way, is a real-life example of the LV2 extension way of
things working)
22 Feb
22 Feb
12:18 a.m.
On 02/21/2011 10:39 PM, David Robillard wrote:
On Mon, 2011-02-21 at 20:27 +0000, Rui Nuno Capela
wrote:
Dave,
please,
you certainly know that most lv2 gtk plugins out there do break this
whole "agnostic" paradigm--tell me one which doesn't? yep. the ones on
lv2_external_ui. shall i rest my case? no.
I said the LV2 UI extension is toolkit agnostic. It is - i.e. it
supports any toolkit.
on my pov it doesn't. or iow. it just drops the baby no matter whether
there's any water in the bathtub :)
the lv2 ui extension just quietly assumes the host knows what to do with
an opaque "widget" handle, which i rather say is the whole problem point
of this discussion.
i'm not saying lv2_external_ui is the ultimate and correct solution but
quite frankly it is not that wrong as you try to convince me. again, it
might be simply as wrong as using the bare lv2 ui. the lv2_external_ui
was the only solution we had and still...
anyway, the lv2 ui extension _needs_ to be extended. to be "de facto"
toolkit agnostic. the only thing that stepped in in a while was, yep
again, lv2_external_ui. it is not perfect, but it helped :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 02/21/2011 07:20 PM, David Robillard wrote:
> On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:
[...]
what has, and still is, outrageously wrong is that
utter cannot-say-what
stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
lock-in disease--mostly due on ardour being a top reference as a plugin
host, nevermind being a gtk based one (and damn good at several other
things too;)
What? The LV2 UI extension is toolkit agnotic. It is not gtk based
whatsoever. Permit me a bit of yelling for emphasis:
PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK
BASED, OR BASED ON ANY OTHER TOOLKIT. IT IS NOT, HAS NEVER BEEN, AND
NEVER WILL BE.
Sure, you (as a Qt person) don't like that most existing UIs happen to
have been implemented in Gtk. This is a problem with how we have
implemented UIs though, and not a problem with the UI extension itself.
That is, this is precisely the sort of problem that shows we need a
library to abstract this stuff (i.e. you are perfectly free to implement
Qt UIs, but then Gtk host authors have the same gripes).
3:56 a.m.
On Mon, 2011-02-21 at 23:18 +0000, Rui Nuno Capela wrote:
[Snip a bunch of irrelevant hand-wavey noise about the past that
completely ignores all discussion about the solution]
anyway, the lv2 ui extension _needs_ to be extended.
to be "de facto"
toolkit agnostic.
No, again, it does not. Not a single argument that it does, or a single
suggestion as to what these modifications would be, have come up in this
thread. Please stop harping on the point that the current situation is
inadequate - nobody disagrees, least of all me. This includes your point
that the external UI extension is the only currently existing solution
to external UIs. Nobody disagrees, least of all me. Both of these things
are blatantly obvious and not under debate.
i'm not saying lv2_external_ui is the ultimate and
correct solution
but
quite frankly it is not that wrong as you try to convince me.
I have described the various cons in detail. This entire discussion
itself is evidence that there is a problem.
You are essentially arguing (in this latest reply) that all this
bridging stuff should be copy-paste duplicated in every UI instead of
every host (i.e. not considering the UI author's perspective). Globally,
this is an even worse solution since there are far more plugins than
UIs.
I have described in detail a solution that makes the LV2 UI situation
"de facto toolkit agnostic", which does not require modifying the UI
extension. As far as I can tell, this is a pretty good solution, and the
only one that doesn't have obvious problems. It meets the needs of
everyone who has voiced them, including you. It solves the
fragmentation/compatibility problems. Do you have any actual feedback on
this? Particularly, any reasons I have missed why it is not a good
solution? You seem to want to argue "against" me, but there's no mention
of my proposed solution at all here... unless new information comes up,
I'll take that as a sign that this is indeed the way to go, and get on
with doing it.
-dr
10:43 a.m.
On Mon, 21 Feb 2011 21:55:04 -0500, David Robillard <d(a)drobilla.net>
wrote:
On Mon, 2011-02-21 at 23:18 +0000, Rui Nuno Capela
wrote:
[Snip a bunch of irrelevant hand-wavey noise about the past that
completely ignores all discussion about the solution]
...
I have described the various cons in detail. This entire discussion
itself is evidence that there is a problem.
You are essentially arguing (in this latest reply) that all this
bridging stuff should be copy-paste duplicated in every UI instead of
every host (i.e. not considering the UI author's perspective).
Globally,
this is an even worse solution since there are far more plugins than
UIs.
I have described in detail a solution that makes the LV2 UI situation
"de facto toolkit agnostic", which does not require modifying the UI
extension. As far as I can tell, this is a pretty good solution, and
the
only one that doesn't have obvious problems. It meets the needs of
everyone who has voiced them, including you. It solves the
fragmentation/compatibility problems. Do you have any actual feedback
on
this? Particularly, any reasons I have missed why it is not a good
solution? You seem to want to argue "against" me, but there's no
mention
of my proposed solution at all here... unless new information comes
up,
I'll take that as a sign that this is indeed the way to go, and get
on
with doing it.
well, i never said your proposed solution isn't any good, did i?
in fact, i apologise for the noise and wish to sincerely nod and
commend it, by all means.
please do not take my stance on defending the lv2_external_ui as a
counter-argument to your proposal. quite the contrary ;)
carry on
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
6:39 p.m.
On Tue, 2011-02-22 at 09:43 +0000, Rui Nuno Capela wrote:
On Mon, 21 Feb 2011 21:55:04 -0500, David Robillard
<d(a)drobilla.net>
[...]
You seem to want to argue "against" me, but
there's no
Heh, fair enough. I get frustrated when things stray from the useful
thread of conversation, what can I say :)
I should say that, though the API design and long-term implications of
the external UI extension are a problem I have been harping on, you're
of course right in that it works. Those who implemented the external UI
stuff have already done the actual implementation of making external UIs
work, it's just in the wrong place(s). My task is basically to play the
architect and put that useful working code in the place where it belongs
to make the architectural problems go away. I'm certainly not saying the
work is entirely crap and wasted time, it just needs a bit of moulding.
Since I enjoy the architect thing quite a bit more than the nitty gritty
make-it-work thing, I'm quite grateful for what's been done, because I
don't want to do it :)
Speaking of existing work, I vaguely recall mention of a plugin with a
Qt GUI? Where is this, I need one for testing...
Cheers,
-dr
mention
of my proposed solution at all here... unless new information comes
up,
I'll take that as a sign that this is indeed the way to go, and get
on
with doing it.
well, i never said your proposed solution isn't any good, did i?
in fact, i apologise for the noise and wish to sincerely nod and
commend it, by all means.
please do not take my stance on defending the lv2_external_ui as a
counter-argument to your proposal. quite the contrary ;)
carry on
7:31 p.m.
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
rncbc(a)rncbc.org
9:02 p.m.
On Tue, 2011-02-22 at 18:32 +0000, Rui Nuno Capela wrote:
On 02/22/2011 05:38 PM, David Robillard wrote:
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
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 ;) 
11:22 p.m.
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
23 Feb
23 Feb
2:22 a.m.
On Tue, 2011-02-22 at 17:22 -0500, Paul Giblock wrote:
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.
OK, thanks. Does anyone care about 3 any more?
(On a related note, the Gtk one should also have had a version number in
there, but whatever, it's just a name)
-dr
2:33 a.m.
Yeah, I was thinking the something regarding gtk. Too late to change it
though. I suppose the next one will just be versioned.
And you are right. Nobody cares about 3 anymore, except for backwards
compatibility. There is no reason to pull that into the UI spec, though, as
there are no Qt3 lv2 plugins.
Paul
4:33 a.m.
Speaking of existing work, I vaguely recall mention of
a plugin with a
Qt GUI? Where is this, I need one for testing...
Take a look at latest svn of CLAM Network Editor. It is apparently able to
export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots
-m
9 a.m.
On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
Speaking of existing work, I vaguely recall mention of a
plugin with a
Qt GUI? Where is this, I need one for testing...
Take a look at latest svn of CLAM Network Editor. It is apparently
able to export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour, they must
be doing the wrapping in the UI code. It would be nice if the next CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
-dr
10:03 a.m.
On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard <d(a)drobilla.net>
wrote:
On Wed, 2011-02-23 at 12:33 +0900, michael noble
wrote:
red herring alert! :)
this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly assumes
the lv2_gtk_ui (pseudo)extension and for that matter it is a plain
gtk-gnostic ui :)--the host must still get to libgtk et al. to handle
the gtk widget/socket--i'm afraid this is not what Dave really asked for
:/
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Speaking of existing work, I vaguely recall mention of a
plugin with a Qt GUI? Where is this, I need one for
testing...
Take a look at latest svn of CLAM Network Editor. It is apparently
able to export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour, they
must
be doing the wrapping in the UI code. It would be nice if the next
CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
10:57 a.m.
On Wed, Feb 23, 2011 at 09:03:03AM +0000, Rui Nuno Capela wrote:
On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard
<d(a)drobilla.net>
wrote:
i think this IS what dave asked for :)
he can just move the gtk shell code, and move it into his library, and
it will be a qt plug :)
On Wed, 2011-02-23 at 12:33 +0900, michael noble
wrote:
red herring alert! :)
this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly
assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
handle the gtk widget/socket--i'm afraid this is not what Dave
really asked for :/
Speaking of existing work, I vaguely recall mention of a
plugin with a Qt GUI? Where is this, I need one for
testing...
Take a look at latest svn of CLAM Network Editor. It is apparently
able to export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour,
they must
be doing the wrapping in the UI code. It would be nice if the next
CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
12:03 p.m.
On Wed, 23 Feb 2011 10:57:25 +0100, torbenh <torbenh(a)gmx.de> wrote:
On Wed, Feb 23, 2011 at 09:03:03AM +0000, Rui Nuno
Capela wrote:
oh come on. do you mean Dave's library will have a so called
specialized "gtk shell" for each toolkit out there? wrapping everything
under gtk is not what i would call a "pretty good solution" at least the
one we've agreed about earlier.
Fons is right suggesting a common-denominator term: the lv2_ui
descriptor should have carried a system window-id instead, in
alternative to, a plain toolkit-dependent widget pointer that
lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based
systems it would cast to a Window type; on windows it would be a HWND;
i'm sure there's something native and equivalent on macosx/carbon/cocoa
w/e... depending on the system the plugins are built/targeted then the
host will/must "know" what to do with that window-id--embed, show, hide,
realize, destroy, trap and send events, etc... look, it is this
window-id in fact the corner stone for the gtk-socket to xembed a
qt-widget on the clam example.
imnsho, a GtkWidget* is not, cannot and never will be the way to
"toolkit agnosticism" :) why is that not obvious to you?
cya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Wed, 23 Feb 2011 02:58:56 -0500, David
Robillard <d(a)drobilla.net>
wrote:
i think this IS what dave asked for :)
he can just move the gtk shell code, and move it into his library,
and
it will be a qt plug :)
On Wed, 2011-02-23 at 12:33 +0900, michael noble
wrote:
red herring alert! :)
this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly
assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
handle the gtk widget/socket--i'm afraid this is not what Dave
really asked for :/
Speaking of existing work, I vaguely recall mention of a
plugin with a Qt GUI? Where is this, I need one for
testing...
Take a look at latest svn of CLAM Network Editor. It is apparently
able to export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour,
they must
be doing the wrapping in the UI code. It would be nice if the next
CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
12:44 p.m.
On Wed, Feb 23, 2011 at 11:03:52AM +0000, Rui Nuno Capela wrote:
On Wed, 23 Feb 2011 10:57:25 +0100, torbenh
<torbenh(a)gmx.de> wrote:
well it will have a specialised qt shell for the other toolkits too.
On Wed, Feb 23, 2011 at 09:03:03AM +0000, Rui Nuno
Capela wrote:
oh come on. do you mean Dave's library will have a so called
specialized "gtk shell" for each toolkit out there? wrapping
everything under gtk is not what i would call a "pretty good
solution" at least the one we've agreed about earlier. On Wed, 23 Feb 2011 02:58:56 -0500, David
Robillard <d(a)drobilla.net>
wrote:
i think this IS what dave asked for :)
he can just move the gtk shell code, and move it into his library,
and
it will be a qt plug :)
On Wed, 2011-02-23 at 12:33 +0900, michael noble
wrote:
>
> Speaking of existing work, I vaguely recall mention of a
> plugin with a Qt GUI? Where is this, I need one for
>testing...
>
>
>Take a look at latest svn of CLAM Network Editor. It is apparently
>able to export networks as LV2 with a Qt GUI. See
>http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour,
they must
be doing the wrapping in the UI code. It would be nice if the next
CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
red herring alert! :)
this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly
assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
handle the gtk widget/socket--i'm afraid this is not what Dave
really asked for :/
Fons is right suggesting a common-denominator term: the lv2_ui
descriptor should have carried a system window-id instead, in
alternative to, a plain toolkit-dependent widget pointer that
lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based
systems it would cast to a Window type; on windows it would be a
HWND; i'm sure there's something native and equivalent on
macosx/carbon/cocoa w/e... depending on the system the plugins are
built/targeted then the host will/must "know" what to do with that
window-id--embed, show, hide, realize, destroy, trap and send
events, etc... look, it is this window-id in fact the corner stone
for the gtk-socket to xembed a qt-widget on the clam example.
imnsho, a GtkWidget* is not, cannot and never will be the way to
"toolkit agnosticism" :) why is that not obvious to you?
nobody said that.
the library would hand you a Qt widget.
this would be a QtWidget wrapping an external ui, the Qt Widget from a
qt gui, or a gtk widget wrapped in a Qt shell.
you already have more experience with this wrapping stuff. so far i have
gathered that you have problems with wrapping gtkmm guis, or something ?
this needs solving on the gtk side.
lets please move this discussion to naming the problems, instead of
claiming that it doesnt work.
the goal of the library, is to make the host not need to deal with the
nastities of embedding stuff.
(there are a few broken windowmanagers out there which dont really
support xembed)
the host will just open the library, and if the library supports the
hosts toolkit, it will hand it out a native widget.
or if thats not possible for some reasons, it will just make the plug
open a toplevel window.
most of the code to do this, is already there. its just scattered.
we just need to put it into a central library with some dlopen stuff, so
that _you_ dont need to link against gtk :)
--
torben Hohn
6:23 p.m.
On Wed, 2011-02-23 at 11:03 +0000, Rui Nuno Capela wrote:
On Wed, 23 Feb 2011 10:57:25 +0100, torbenh
<torbenh(a)gmx.de> wrote:
You seem to have forgotten, or decided to ignore, every single solitary
point brought up in this conversation over the night ;)
You are wrong, but why that is so, and what the correct solution is, has
been described plenty enough already, so I won't waste time doing so
once again. If you're just interested in blissfully ignorant trolling
about Gtk gnosticism or whatever, I'll adjust my mental ignore list
accordingly. If you're actually interested in making the solution
happen, then let's do it:
This is Qt LV2 UIs embedded in Ingen:
http://drobilla.net/files/qt_in_ingen.png
Ingen has absolutely no idea about anything Qt or X11 related
whatsoever, and the float plugin has absolutely no idea about anything
Gtk or X11 related whatsoever. They both just do exactly what their
developers want, without any of the PITA of dealing with foreign
toolkits and window systems and embedding and whatever else. In other
words, this solution is superior.
This, of course, means I wrote that library:
http://svn.drobilla.net/lad/trunk/suil/
I have not tested the Gtk-in-Qt direction yet. You're a Qt host author.
Hint, hint. I got stuck in qtractor autohell and gave up last night.
The relevant code in Ingen is here:
http://svn.drobilla.net/lad/trunk/ingen/src/client/PluginUI.cpp
The "make a UI set" thing is a bit tedious, but is needed to avoid SLV2
<=> Suil dependency. I am thinking that maybe I should make SLV2 depend
on this library(*) and provide a simpler interface there (basically just
suil_instance_new, which is the real meat). The next SLV2 release will
break API slightly anyway. Feedback from you or any other SLV2 users
welcome, I am inclined to break the SLV2 UI related API if it makes it
obvious and trivial for hosts to do the right thing.
-dr
(* The library itself depends on no toolkits, it uses dynamically loaded
modules for all the wrapping, but this depends on packagers doing it
right)
On Wed, Feb 23, 2011 at 09:03:03AM +0000, Rui
Nuno Capela wrote:
oh come on. do you mean Dave's library will have a so called
specialized "gtk shell" for each toolkit out there? wrapping everything
under gtk is not what i would call a "pretty good solution" at least the
one we've agreed about earlier.
Fons is right suggesting a common-denominator term: the lv2_ui
descriptor should have carried a system window-id instead, in
alternative to, a plain toolkit-dependent widget pointer that
lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based
systems it would cast to a Window type; on windows it would be a HWND;
i'm sure there's something native and equivalent on macosx/carbon/cocoa
w/e... depending on the system the plugins are built/targeted then the
host will/must "know" what to do with that window-id--embed, show, hide,
realize, destroy, trap and send events, etc... look, it is this
window-id in fact the corner stone for the gtk-socket to xembed a
qt-widget on the clam example.
imnsho, a GtkWidget* is not, cannot and never will be the way to
"toolkit agnosticism" :) why is that not obvious to you? On Wed, 23 Feb 2011 02:58:56 -0500, David
Robillard <d(a)drobilla.net>
wrote:
i think this IS what dave asked for :)
he can just move the gtk shell code, and move it into his library,
and
it will be a qt plug :)
On Wed, 2011-02-23 at 12:33 +0900, michael noble
wrote:
>
> Speaking of existing work, I vaguely recall mention of a
> plugin with a Qt GUI? Where is this, I need one for
>testing...
>
>
>Take a look at latest svn of CLAM Network Editor. It is apparently
>able to export networks as LV2 with a Qt GUI. See
>http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour,
they must
be doing the wrapping in the UI code. It would be nice if the next
CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
red herring alert! :)
this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly
assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
handle the gtk widget/socket--i'm afraid this is not what Dave
really asked for :/
8:03 p.m.
New subject: libsuil (was: IR: LV2 Convolution Reverb)
On 02/23/2011 05:22 PM, David Robillard wrote:
<snip>
http://svn.drobilla.net/lad/trunk/suil/
I have not tested the Gtk-in-Qt direction yet. You're a Qt host
author. Hint, hint. I got stuck in qtractor autohell and gave up last
night.
<snip>
(* The library itself depends on no toolkits, it uses dynamically loaded
modules for all the wrapping, but this depends on packagers doing it
right)
i see. and these dlload'ed modules which do all the wrapping have these
revealing names like "libsuil_qt4_in_gtk2" and
"libsuil_gtk2_in_qt4"... :/
nice, but i figure it's a solution in a world where the host and the
plugin are either of those 2 toolkits and only under a x11 umbrella.
what if a plugin developer wishes to do it on fltk, juce, plain xlib,
win32/64, carbon, cocoa, whatever? (lv2_external_ui already allows that
*grin*)) aha, you'll probably say there will be a plethora of
combinations on those modules like
"libsuil_$(plugin-toolkit)_in_$(host-toolkit)"... is that it?
sorry to be such a troll:) maybe i'll shut up now.
anyway, i'm still looking forward to this libsuil project, by all means
an excellent effort. sincerely agree that it will do a lot better than
the current lv2_gtk_ui situation.
cya
ps. btw, i removed all gtk wrapping/xembed-ding from qtractor since it
was more the bloat than the trouble--if one has to link to libgtk just
to get a lousy x11 window-id from a GtkWidget then one's better off
doing it all the-gtk-way:)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
8:39 p.m.
New subject: libsuil (was: IR: LV2 Convolution Reverb)
On Wed, 2011-02-23 at 19:03 +0000, Rui Nuno Capela wrote:
On 02/23/2011 05:22 PM, David Robillard wrote:
<snip>
I have no idea why this is something to :/ at...
http://svn.drobilla.net/lad/trunk/suil/
I have not tested the Gtk-in-Qt direction yet. You're a Qt host
author. Hint, hint. I got stuck in qtractor autohell and gave up last
night.
<snip>
(* The library itself depends on no toolkits, it uses dynamically loaded
modules for all the wrapping, but this depends on packagers doing it
right)
i see. and these dlload'ed modules which do all the wrapping have these
revealing names like "libsuil_qt4_in_gtk2" and
"libsuil_gtk2_in_qt4"... :/ nice, but i figure it's a solution in a world
where the host and the
plugin are either of those 2 toolkits and only under a x11 umbrella.
what if a plugin developer wishes to do it on fltk, juce, plain xlib,
win32/64, carbon, cocoa, whatever? (lv2_external_ui already allows that
*grin*))
Yes, it allows that by shifting the burden on the plugin authors (which
is even worse than doing it to host authors), encouraging half-assed
solutions, rampant copy/paste code duplication, bugs, and a high barrier
of entry for writing a plugin UI. On top of all that, it throws out
embedding and other niceties entirely. This is why it is a poor
solution.
aha, you'll probably say there will be a plethora
of
combinations on those modules like
"libsuil_$(plugin-toolkit)_in_$(host-toolkit)"... is that it?
Yes, that is precisely the idea. It all gets implemented in one place,
and neither the host nor plugin authors have to worry about any of it.
This is the only solution where that is true. Making all the UI authors
deal with it (repeatedly, via half-assed solutions and copy paste code
duplication) is not a good solution.
People probably will start using these new toolkits, and it will Just
Work in all the host, for free, as soon as it's implemented here. This
is a Good Thing. (The same applies to a UI exposing a low level window
ID, by the way, but there is no longer any good reason to do that).
The point, that has been repeatedly missed (which is really starting to
get irritating), is that all this IMPLEMENTATION DETAIL has become just
that. The burden on you, as a host author, to worry about the "plethora
of combinations", has been removed. That burden has also been removed
from the UI authors (which is not true of the solutions you keep
championing. As for the "plethora", there simply aren't that many
toolkits, and the modules are neither large nor complicated, but
again... implementation detail. As far as you are concerned, the magic
library just works.
Suppose Fltk plugin UIs do come along. Wonderful. Implement that in
Suil, and it will just magically work in e.g. Qtractor and Ardour with
zero changes required.
In short: Problem Solved.
sorry to be such a troll:) maybe i'll shut up
now.
anyway, i'm still looking forward to this libsuil project, by all means
an excellent effort. sincerely agree that it will do a lot better than
the current lv2_gtk_ui situation.
No future tense required, there it is. Make it happen. If I had a Qt
host to test with right now, I'd make sure Gtk2-in-Qt4 actually works,
release, and that's that.
That said, I think I will just modify the SLV2 API accordingly so you
don't have to use Suil directly, so maybe wait a day (but switching
would be easy, and the sooner I have something to test with, the sooner
this problem is solved, so don't let that stop you).
-dr
9:11 p.m.
New subject: libsuil
On 02/23/2011 07:37 PM, David Robillard wrote:
On Wed, 2011-02-23 at 19:03 +0000, Rui Nuno Capela
wrote:
i won't :)
one question,
(btw, i know my english is weird, even on my mothers language i'm lousy:)
are you saying that this suil api will get it implicit and integrated
into slv2? in a matter of days? i've looked into the "suil.h" and it
makes perfect sense...
yep, i might arrange some time to test this gtk2_in_qt4 stuff (granted i
don't fall into wafhell over more than a week-end ;))
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
anyway, i'm still looking forward to this libsuil project, by all means
an excellent effort. sincerely agree that it will do a lot better than
the current lv2_gtk_ui situation.
No future tense required, there it is. Make it happen. If I had a Qt
host to test with right now, I'd make sure Gtk2-in-Qt4 actually works,
release, and that's that.
That said, I think I will just modify the SLV2 API accordingly so you
don't have to use Suil directly, so maybe wait a day (but switching
would be easy, and the sooner I have something to test with, the sooner
this problem is solved, so don't let that stop you).
10:29 p.m.
New subject: libsuil
On Wed, 2011-02-23 at 20:11 +0000, Rui Nuno Capela wrote:
On 02/23/2011 07:37 PM, David Robillard wrote:
Well, I'm just thinking it might be a bit less of a hassle, and make
doing the right thing extremely easy/obvious, if SLV2 just had a
function like suil_instance_new. It also allows me to deprecate (or just
outright remove) the old SLV2UIInstance stuff which encourages the wrong
thing (poking through the UIs and instantiating them yourself, i.e.
caring about toolkits).
The independent suil API is just slightly more annoying because you have
to take your SLV2UIs and stick its contents in a SuilUIs... it's just a
little loop, not a huge deal, but it's not pretty. Have one Do The Right
Thing UI instantiation function in SLV2 is nice and idiot-proof, but
perhaps the dependency isn't worth it.
I could, of course, just literally implement all of this in SLV2 itself,
but I figured a zero-dependency library would be a good thing, and in
general I like to keep UI things separate...
On Wed, 2011-02-23 at 19:03 +0000, Rui Nuno
Capela wrote:
i won't :)
one question,
(btw, i know my english is weird, even on my mothers language i'm lousy:)
are you saying that this suil api will get it implicit and integrated
into slv2? in a matter of days? i've looked into the "suil.h" and it
makes perfect sense...
anyway, i'm still looking forward to this libsuil project, by all means
an excellent effort. sincerely agree that it will do a lot better than
the current lv2_gtk_ui situation.
No future tense required, there it is. Make it happen. If I had a Qt
host to test with right now, I'd make sure Gtk2-in-Qt4 actually works,
release, and that's that.
That said, I think I will just modify the SLV2 API accordingly so you
don't have to use Suil directly, so maybe wait a day (but switching
would be easy, and the sooner I have something to test with, the sooner
this problem is solved, so don't let that stop you).
yep, i might arrange some time to test this
gtk2_in_qt4 stuff (granted i
don't fall into wafhell over more than a week-end ;))
From the user POV it's the usual pkg-config
routine.
(I can't even begin to describe what a relief it is to trade up to the
sensible prettiness of waf and escape the convoluted layer upon
convoluted layer of inconsistent fugly line noise that is autohell, but
that's another conversation entirely)
-dr
24 Feb
24 Feb
10:20 a.m.
New subject: libsuil
On Wed, 2011-02-23 at 20:11 +0000, Rui Nuno Capela wrote:
[snip]
are you saying that this suil api will get it implicit
and integrated
into slv2? in a matter of days? i've looked into the "suil.h" and it
makes perfect sense...
I've done this now[1]. The half-baked collection API in Suil as of my
last post was clumsy and out of place. I've removed all that, so Suil is
exclusively for instantiating (and possibly wrapping) plugin UIs
(deciding which UI to instantiate is the user's problem).
SLV2 now (optionally) depends on Suil. The API changes are minimal; host
authors just need to switch from the now-deprecated slv2_ui_instantiate
to its replacement, slv2_ui_instance_new. This new function takes the
same parameters plus an additional widget type parameter which specifies
the type of widget the host expects. Cross-toolkit embedding should then
magically work.
-dr
[1] http://dev.drobilla.net/changeset/3022
10:39 a.m.
New subject: libsuil
On Thu, 24 Feb 2011 04:19:05 -0500, David Robillard <d(a)drobilla.net>
wrote:
On Wed, 2011-02-23 at 20:11 +0000, Rui Nuno Capela
wrote:
[snip]
great!
i'll test this stuff asap.
oh, another question on wishing to keep compile-time (#ifdef's:)
retro-compatibility with previous libslv2 releases:
is it correct to assume that "slv2_ui_instance_new" symbol is
determinant to whether we're in presence of this newer libslv2 version?
if not, what would be the correct method, iyo?
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
are you saying that this suil api will get it
implicit and
integrated
into slv2? in a matter of days? i've looked into the "suil.h" and it
makes perfect sense...
I've done this now[1]. The half-baked collection API in Suil as of my
last post was clumsy and out of place. I've removed all that, so Suil
is
exclusively for instantiating (and possibly wrapping) plugin UIs
(deciding which UI to instantiate is the user's problem).
SLV2 now (optionally) depends on Suil. The API changes are minimal;
host
authors just need to switch from the now-deprecated
slv2_ui_instantiate
to its replacement, slv2_ui_instance_new. This new function takes the
same parameters plus an additional widget type parameter which
specifies
the type of widget the host expects. Cross-toolkit embedding should
then
magically work.
5:46 p.m.
New subject: libsuil
On Thu, 2011-02-24 at 09:39 +0000, Rui Nuno Capela wrote:
On Thu, 24 Feb 2011 04:19:05 -0500, David Robillard
<d(a)drobilla.net>
wrote:
Check for version >= 0.7.0. You could check that symbol too, I suppose.
Regarding compatibility, I just had a thought: if I made a
slv2_world_set_ui_widget_type or something, and stored that in the
world, then the old function interface could do wrapping without
breaking the instantiation function. Deprecating the old one (w/ GCC
warnings) makes it more obvious to host authors what they need to do,
though... I dunno...
Cheers,
-dr
On Wed, 2011-02-23 at 20:11 +0000, Rui Nuno
Capela wrote:
[snip]
great!
i'll test this stuff asap.
oh, another question on wishing to keep compile-time (#ifdef's:)
retro-compatibility with previous libslv2 releases:
is it correct to assume that "slv2_ui_instance_new" symbol is
determinant to whether we're in presence of this newer libslv2 version?
if not, what would be the correct method, iyo? are you saying that this suil api will get it
implicit and
integrated
into slv2? in a matter of days? i've looked into the "suil.h" and it
makes perfect sense...
I've done this now[1]. The half-baked collection API in Suil as of my
last post was clumsy and out of place. I've removed all that, so Suil
is
exclusively for instantiating (and possibly wrapping) plugin UIs
(deciding which UI to instantiate is the user's problem).
SLV2 now (optionally) depends on Suil. The API changes are minimal;
host
authors just need to switch from the now-deprecated
slv2_ui_instantiate
to its replacement, slv2_ui_instance_new. This new function takes the
same parameters plus an additional widget type parameter which
specifies
the type of widget the host expects. Cross-toolkit embedding should
then
magically work.
23 Feb
23 Feb
5:17 p.m.
On Wed, 2011-02-23 at 09:03 +0000, Rui Nuno Capela wrote:
On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard
<d(a)drobilla.net>
wrote:
Right. It isn't, but it should be.
-dr
P.S. The "gnostic" thing is getting old ;)
On Wed, 2011-02-23 at 12:33 +0900, michael noble
wrote:
red herring alert! :)
this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly assumes
the lv2_gtk_ui (pseudo)extension and for that matter it is a plain
gtk-gnostic ui :)--the host must still get to libgtk et al. to handle
the gtk widget/socket--i'm afraid this is not what Dave really asked for
:/
Speaking of existing work, I vaguely recall mention of a
plugin with a Qt GUI? Where is this, I need one for
testing...
Take a look at latest svn of CLAM Network Editor. It is apparently
able to export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots
Interesting. Judging by the fact that they're shown in Ardour, they
must
be doing the wrapping in the UI code. It would be nice if the next
CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.
22 Feb
22 Feb
5:52 a.m.
On Mon, Feb 21, 2011 at 7:20 PM, David Robillard <d(a)drobilla.net> wrote:
On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela
wrote:
Just because something right has not been implemented does not mean the
existing thing is right... (as your Gtk gripes illustrate)
Yes, clearly right now (excluding actually implementing the library),
using it is the pragmatic decision if you want a UI that works in a host
of any toolkit (and you don't need to embed UIs). This situation,
however, is crap, and needs fixing.
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/…
:)
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.
Jeremy
On 02/09/2011 04:49 PM, David Robillard wrote:
> On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi wrote:
>>
>> Regarding LV2 hosts other than Ardour: the second in the above list of
>> fixes should help, however please be aware that IR is at the moment
>> really not usable without its own GTK UI. In future versions I may
>> manage to switch to using an external-process LV2 UI which would
>> result in the plugin UI being completely host toolkit agnostic.
>
> FWIW, I would not do this. The external UI extension is the wrong way
> of going about this, and momentum towards it is very worrysome... We
> need an abstraction layer (i.e. a library) to provide the ability for
> any UI to be external. It shouldn't be the host's - and very
definitely
> not the plugin's - problem to do this.
It's a difficult problem to get
> just right(*). Even if it wasn't, we'd end up with the same code
> implemented all over the place, which is an obvious sign something is
> not right...
>
> The right way is for the plugin UI to provide whatever native UI (e.g.
> gtk) it pleases, and a library provides the means to launch it
> externally if the host toolkit does not match. This way, the host can
> embed the UI if possible (a feature which really is a shame to throw
> away), but anyone can use it externally if this is not possible. It is
> also possible these days for Gtk to embed Qt, and vice versa, which the
> lib could also do... in short, all the tricky business of using an X UI
> in a Y host, either embedded or externally, needs to be done in one
> place, and done in that one place correctly, so every host/plugin
author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
your words, Dave, are wise, but... until that (yours?) lib gets ever
real, the lv2-external-ui extension won't ever be wrong. sorry to tell what has, and still is, outrageously wrong is
that utter cannot-say-what
stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
lock-in disease--mostly due on ardour being a top reference as a plugin
host, nevermind being a gtk based one (and damn good at several other
things too;)
What? The LV2 UI extension is toolkit agnotic. It is not gtk based
whatsoever. Permit me a bit of yelling for emphasis:
PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK
BASED, OR BASED ON ANY OTHER TOOLKIT. IT IS NOT, HAS NEVER BEEN, AND
NEVER WILL BE.
Sure, you (as a Qt person) don't like that most existing UIs happen to
have been implemented in Gtk. This is a problem with how we have
implemented UIs though, and not a problem with the UI extension itself.
That is, this is precisely the sort of problem that shows we need a
library to abstract this stuff (i.e. you are perfectly free to implement
Qt UIs, but then Gtk host authors have the same gripes).
I fully agree host authors should not have to deal with this (I
certainly don't want a bunch of Qt crap in my Gtk hosts either), that's
the entire point. I take it further and don't believe plugin UI authors
should have to deal with it either.
We can get all the wins without:
* Throwing out UI embedding, which really sucks for a lot of potential
UI designs (window hell sucks).
* Forcing a particular toolkit, which will inevitably piss off everyone
who doesn't like that particular toolkit, again really suck for a lot of
potentially neat UI designs, and thus severely hurt adoption
* Making plugin or host authors
Why throw out nice things if we don't have to? Kludges in
implementations are fine, but kludges that affect what interfaces we
cooperate using are dangerous, particularly in the long term...
please, don't give me nice talks about xembed
and that stuff about gtk
and qt widgets being reciprocally embeddable. it just doesn't work for
the masses. well, in practice, unless you're in some kind ivory tower
and aim for a very special case or tight coupled application, that is...
I am told it can work these days, unlike in the past. Torben has some
experiments along those lines that work for him and at least some
others, but one direction (I can't remember which) didn't work for me.
Maybe it is indeed unrealistic, at least in some situations. It doesn't
really matter regardless, the design decision of where the
embed/external/whatever stuff belongs is orthogonal.
In other words, maybe embedding toolkit X in toolkit Y can work, maybe
it can not. I am not sure, nor do I really care so much. My point is
definitely not that we should all depend on cross-toolkit embedding
working; the important point is that this problem (e.g. using a Gtk UI
in a Qt host) needs solving once, not a million kludgey times in every
host and UI implementation.
I do intend to write said library myself soon (I don't often talk about
what I/we "will" do, but this is something of an LV2 UI state of the
union). It is a high, but not top, priority for me right now (somewhere
after releasing LV2r4, the new librdf-free slv2, and the LV2 persist
extension).
The important part, that I am suggesting very much needs doing ASAP, is
that getting a library interface implemented, so people can start using
it. This does not depend on making embedding working, since the
fallback will be making an external windows. We simply need something
like (obviously a simplification):
OpaqueWidget
lv2_ui_lib_load(ToolkitType requested_toolkit,
UI plugin_ui)
Which will return a widget of the requested toolkit type, regardless of
the toolkit the UI is implemented. There's a few possibilities:
1) Hooray, the toolkits match, and this will directly return the UI
widget, which you can embed or do whatever else you want with.
2) The toolkits do not match, and the library can implement
cross-toolkit embedding. This will return a widget in the requested
toolkit that from the caller's perspective is the same as case 1.
3) The toolkits do not match, and cross-toolkit embedding is not
possible. This will do the external UI thing (i.e. make a window, and
return a corresponding widget).
There are, in general, the 3 cases. The jist of the current problem is
that implementers must make a decision that mandates an interface on
other implementers. The library will make this problem go away, and
make these cases implementation details as they should be.
This is very much a pragmatic path, and not at all an ivory tower / pie
in the sky situation: whether or not a case (particularly 2) can work in
a given situation doesn't really matter - we have gained graceful
degradation and interface stability. The first version will simply
implement cases 1 and 3 - providing the interface is the important part
that will solve the pressing problems with this situation.
Hopefully someone will figure out and contribute case 2, but this is not
a pressing (i.e. API related / community fragmenting) problem - just a
nicety.
Peace,
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
7:08 p.m.
On Tue, 2011-02-22 at 04:52 +0000, 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/…
:) 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 :)
Cheers,
-dr
7:50 p.m.
2011/2/22 David Robillard <d(a)drobilla.net>et>:
On Tue, 2011-02-22 at 04:52 +0000, Jeremy Salwen
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.
Stefano
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/…
:) 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 :)
7:55 p.m.
On Tue, Feb 22, 2011 at 1:50 PM, Stefano D'Angelo <zanga.mail(a)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.
9:36 p.m.
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.mail(a)gmail.com> wrote:
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
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.
9:29 p.m.
On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote:
2011/2/22 David Robillard <d(a)drobilla.net>et>:
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
On Tue, 2011-02-22 at 04:52 +0000, Jeremy Salwen
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. 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/…
:) 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 :)
9:34 p.m.
New subject: [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.)
11:31 p.m.
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:
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.
2011/2/22 David Robillard
<d(a)drobilla.net>et>:
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. On Tue, 2011-02-22 at 04:52 +0000, Jeremy Salwen
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. 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/…
:) 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 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.)
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--
23 Feb
23 Feb
10:52 a.m.
On 2/23/11, Philipp Überbacher <hollunder(a)lavabit.com> wrote:
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.
So problem number one is that you have old-fashioned view on system
configuration.
Besides that the interface is slow and buggy, despite
running on the
same machine. I wouldn't call it a good interface in general.
So problem number two is that because CUPS's UI is bad, you
extrapolate that on other web UIs. Very interesting.
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.
So problem number three is conspiracy theories.
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.
So problem number four is that you have no idea whatsoever about
possibility to use hotkeys in a web app. Just FYI Gmail has lots of
shortcuts for both replying, forwarding and navigation between mails.
I use it all the time. Why you have no idea it is possible with AJAX
-- I really couldn't say. But you said something about
short-sightedness :-P
Accessibility? Forget it, text browser don't do
JS.
So the problem number five is being one of few hundred people around
the globe who still use text browsers in the world of Firefox, Chrome,
Opera, Safari and IE.
Ever heard of http://www.w3.org/WAI/ btw?
In other words, most of your points are made on the basis of you not
being up to day with modern technologies.
Sorry, I could rant on forever.
Pray continue. I love reading stuff like that.
Alexandre Prokoudine
http://libregraphicsworld.org
11:39 a.m.
On Wed, Feb 23, 2011 at 12:52:44PM +0300, Alexandre Prokoudine wrote:
Apart from some very trivial ones I've never seen one that
was any better. I've seen a lot of them that are a pain to use.
Or elementary security awareness. If exposing the old and deprecated
non-ssh based X11 interface is a bad idea (there's no discussion about
that probably), then storing your data unprotected on a third party
system certainly is. And then there are the legal issues. If you store
some data obtained under NDA in a Google App, do you violate the NDA ?
I'd say yes. What if a medical doctor stores his patient's files this
way ? Most professional activities involve keeping confidential data
of some sort. I would not hesitate to say that Google Apps is a no-go
for that reason alone.
Ciao,
--
FA
On 2/23/11, Philipp Überbacher
<hollunder(a)lavabit.com> wrote:
A realistic one I'd say. Using a web interface implies you have
already a working system, and by no means a minimal one.
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.
So problem number one is that you have old-fashioned view on system
configuration. Besides that
the interface is slow and buggy, despite running on the
same machine. I wouldn't call it a good interface in general.
So problem number two is that because CUPS's UI is bad, you
extrapolate that on other web UIs. Very interesting. 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.
So problem number three is conspiracy theories. 
2:42 p.m.
On Wed, 23 Feb 2011 10:39:49 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Or elementary security awareness. If exposing the old
and deprecated
non-ssh based X11 interface is a bad idea (there's no discussion about
that probably), then storing your data unprotected on a third party
system certainly is. And then there are the legal issues. If you store
some data obtained under NDA in a Google App, do you violate the NDA ?
I'd say yes. What if a medical doctor stores his patient's files this
way ? Most professional activities involve keeping confidential data
of some sort. I would not hesitate to say that Google Apps is a no-go
for that reason alone.
Ciao,
As far as I am concerned this point overrides any and all other considerations.
You have absolutely no control over where your data is going or who may be
looking at it.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
noon
Excerpts from Alexandre Prokoudine's message of 2011-02-23 10:52:44 +0100:
No, I talked about specific examples instead of talking out of my arse.
This has nothing to do with conspiracy theories at all, and google not
the topic here.
I know that shortcuts are possible, I tried it before writing my mail,
but they are limited, and the limits may change from browser to browser,
system to system, and you use many different systems all the time,
otherwise you wouldn't need a web UI.
I'm thinking mostly about blind users when I talk about accessibility,
and I'm not sure how usable graphical browsers are for the blind.
Might be that I'm not up-to-date, but I don't see a reason to be.
Especially JS, which seems to be at the heart of the 'modern' web, is
for me associated with security, privacy and compatibility problems as
well as lack of user control while tangible benefits are hard to find.
I'd rather like to see examples of good web UIs including an explanation
of their benefits over conventional UIs instead of 'you'r so uncool'.
Maybe you can show me at LAC?
On 2/23/11, Philipp Überbacher
<hollunder(a)lavabit.com> wrote:
That might be, I don't see why a new way would be necessary or
benefitial, especially if the new way is to configure a local
system using a web UI.
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.
So problem number one is that you have old-fashioned view on system
configuration. Besides that
the interface is slow and buggy, despite running on the
same machine. I wouldn't call it a good interface in general.
So problem number two is that because CUPS's UI is bad, you
extrapolate that on other web UIs. Very interesting. 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.
So problem number three is conspiracy theories. 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.
So problem number four is that you have no idea whatsoever about
possibility to use hotkeys in a web app. Just FYI Gmail has lots of
shortcuts for both replying, forwarding and navigation between mails.
I use it all the time. Why you have no idea it is possible with AJAX
-- I really couldn't say. But you said something about
short-sightedness :-P Accessibility?
Forget it, text browser don't do JS.
So the problem number five is being one of few hundred people around
the globe who still use text browsers in the world of Firefox, Chrome,
Opera, Safari and IE.
Ever heard of http://www.w3.org/WAI/ btw?
In other words, most of your points are made on the basis of you not
being up to day with modern technologies. Sorry, I could
rant on forever.
Pray continue. I love reading stuff like that.
Alexandre Prokoudine
http://libregraphicsworld.org
2:43 p.m.
On 2/23/11, Philipp Überbacher wrote:
That might be, I don't see why a new way would be necessary or
benefitial, especially if the new way is to configure a local
system using a web UI.
But it doesn't have to be a local system :)
No, I talked about specific examples instead of talking out of my arse.
*sigh*
I don't believe you did, the reason being -- you vote against the
whole web thing by providing examples of one bad web UI. How does this
one web UI affect other web UIs? Does it infect them fith influenza?
Do they cough and suck loads of throat sweets? :)
Can you remeber what Bill Gates said about Internet back in early 90s?
Can you remember what happened next? Do you close your eyes and
pretend not to hear anything when you keep seing new cloud computing
services popping up with a workiing business model behind them,
because they contradict your view of a perfect world to live in?
This has nothing to do with conspiracy theories at all, and google not
the topic here.
No wait, you did say "google docs/spreadsheet" and then google is
suddenly not the topic? :)
Personally, I find the whole anticloud-computing thing highly exaggerated.
Google doesn't start new services, because they feel so charitable.
This is business. They justify cost of production, maintenance and
further development by having some business model behind every new
service. The same is valid for other companies. Storing your data in a
cloud is how it works.
Quite a number of modern hospitals have centralized data storage as
well. Doctors only need a tablet to access information from it when
they do their rounds in a shift. Would you resist being transferred to
such a hospital, because information will be centralized? Would you
request all the information to be erased when you leave (and all the
cookies wiped :))?
Privacy is a valid concern. Exxagerating it, however, rarely helps.
It's up to you if you want trading anything off. These days anyone can
do a personal cloud computng service for just him-/herself with as
much privacy as desired. And you don't even need cloud computing: the
whole SparkleShare thing that is essentially a Git wrapper was born
out of a will to control data instead of further relying on Dropbox.
Then what is your point exactly? Because some web app developers don't
care about accessibility, let's dump the whole thing altogether?
Again, it's up to web developers how much efforts they put into making
their apps accessible.
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.
So problem number one is that you have old-fashioned view on system
configuration. Besides that the interface is slow and buggy, despite
running on the
same machine. I wouldn't call it a good interface in general.
So problem number two is that because CUPS's UI is bad, you
extrapolate that on other web UIs. Very interesting. 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.
So problem number three is conspiracy theories. So problem
number four is that you have no idea whatsoever about
possibility to use hotkeys in a web app. Just FYI Gmail has lots of
shortcuts for both replying, forwarding and navigation between mails.
I use it all the time. Why you have no idea it is possible with AJAX
-- I really couldn't say. But you said something about
short-sightedness :-P
I know that shortcuts are possible, I tried it before writing my mail,
but they are limited, and the limits may change from browser to browser,
system to system, and you use many different systems all the time,
otherwise you wouldn't need a web UI.
Wrong :) Web UI is about more things then just using different
systems. Collaboration is the first thing I can think of.
So the problem
number five is being one of few hundred people around
the globe who still use text browsers in the world of Firefox, Chrome,
Opera, Safari and IE.
Ever heard of http://www.w3.org/WAI/ btw?
In other words, most of your points are made on the basis of you not
being up to day with modern technologies.
I'm thinking mostly about blind users when I talk about accessibility,
and I'm not sure how usable graphical browsers are for the blind. I'd rather like to see examples of good web UIs
including an explanation
of their benefits over conventional UIs instead of 'you'r so uncool'.
Well, I quite like Gmail + Google Talk. People laughed at me when I
said "how about mating mail and Jabber?". They stopped doing so a year
later when Google Talk was announced and made available. After that
there's no way I choose to go back to arbitrary Jabber address and an
offline mail client, not until I'm dragged kicking and screaming. I
can see why IMAP can still be preferred by many people, but there is
such a thing as "not my cup of tea". I see no reason whatsoever to
argue about that. It's up to me to decide what is usable for me,
likewise it's up to you to decide what is usable for you.
Alexandre Prokoudine
http://libregraphicsworld.org
3:53 p.m.
On 2/23/11, Alexandre Prokoudine wrote:
Oh, and speaking of accessibility, both GTK+ and Qt are somewhat
broken: GTK+ on Windows doesn't support accelerators in non-Latin
locales, and Qt on (at least) Linux doesn't do it either. How about
fixing that first? :)
Alexandre Prokoudine
http://libregraphicsworld.org
I'm
thinking mostly about blind users when I talk about accessibility,
and I'm not sure how usable graphical browsers are for the blind.
Again, it's up to web developers how much efforts they put into making
their apps accessible.
4:05 p.m.
On Wed, Feb 23, 2011 at 04:43:50PM +0300, Alexandre Prokoudine wrote:
Do you close your eyes and
pretend not to hear anything when you keep seing new cloud computing
services popping up with a workiing business model behind them,
because they contradict your view of a perfect world to live in?
When I seen somehting that contradicts my view of a perfect world,
and that thing is likely to affect me or people or things I care
about, then I do not close my eyes, and I have every right to
critisize it. Even if you don't like that or if it interferes
with your dreams. Or do you say 'these are not dreams, what I
mean to say is that resistance is futile and you will be
assimilated' ? In that case we don't have a conspiracy _theory_,
but a real one.
Quite a number of modern hospitals have centralized
data storage
as well.
That usually was centralised even before the days of computers.
Would you resist being transferred to
such a hospital, because information will be centralized?
Not because it is centralised (I rather expect it to be). But
I would certainly object to it being given to a third party
which has nothing to do with running medical services, but
only with exploiting the data it is handling for commercial
gain.
If providers of 'cloud computing' would be serious about data
and privacy protection they would use systems that allow the
users to protect their data in a verifiable way. This is not
what I see happening: they do the inverse and force the user
to make his data exploitable. Because *that* is the business
model.
Like everything essentially driven by greed, it would be sort
of acceptable (on a voluntary basis) if either
* the relation between the parties is regulated by law,
ensuring a fair deal for both and protection of basic
rights of the weakest one,
* or the parties have approximately equal power, ensuring
'mutual damage' if any of them misbehaves towards the
other.
None of the two conditions is satisfied, e.g. in the case
of Google, Facebook, and the likes.
--
FA
5:55 p.m.
On 2/23/11, Fons Adriaensen wrote:
Fair enough :) My point however was about strangely easy dismissal of
modern web technologies. I'd hate to see Linux behind the game *again*
just because some old fashioned people who control essential parts of
the ecosystem decided that things they don't personally like won't
happen. Don't get me wrong -- there's nothing bad about being
old-fashioned, I am one in many ways :) But there's time and place.
For how many years did we have to use Rosegarden/MusE and Ardour *and*
Hydrogen simultaneously just to get *basic* DAW functionality only
because everyone went on saying things like "Oh, this is UNIX
philosophy -- do one thing and do it well" or "Divide and conqer"? So,
we divided, and what have we conquered? :) After so many years we are
ending up with A3 approaching that has integrated MIDI and audio
anyway, a decade (too?) late.
Even our open approach to multitude of toolkits is biting us in the
arse (LV2 again), whereas we are supposed to be having it by the
throat.
What I'd really like to see is some perspective. I'm not talking about
visionaries, gods, no :) I'm talking about acknowledgement of where
the industry is heading to and how we can part of the future without
trading off our essential values (and rights).
Honestly, in 12 years that I've been following libre audio and
graphics project I've had enough of "me-too-ism". It's about time we
had some "you-don't-but-we-do-ism" for difference's sake :) There are
perfectly valid and safe ways to do it, and this is already taking
place, but in a rather scattered, disorganized way.
Do you close
your eyes and
pretend not to hear anything when you keep seing new cloud computing
services popping up with a workiing business model behind them,
because they contradict your view of a perfect world to live in?
When I seen somehting that contradicts my view of a perfect world,
and that thing is likely to affect me or people or things I care
about, then I do not close my eyes, and I have every right to
critisize it. If providers of 'cloud computing' would be
serious about data
and privacy protection they would use systems that allow the
users to protect their data in a verifiable way.
Verifiable how exactly?
This is not what I see happening: they do the inverse
and force
the user to make his data exploitable.
Exactly how they do it? Please use SoundCloud as example.
Like everything essentially driven by greed, it would
be sort
of acceptable (on a voluntary basis) if either
* the relation between the parties is regulated by law,
ensuring a fair deal for both and protection of basic
rights of the weakest one,
And it isn't taking place? Exactly why?
Alexandre Prokoudine
http://libregraphicsworld.org
11:57 p.m.
On Wed, 2011-02-23 at 19:55 +0300, Alexandre Prokoudine wrote:
For how many years did we have to use Rosegarden/MusE
and Ardour *and*
Hydrogen simultaneously just to get *basic* DAW functionality only
because everyone went on saying things like "Oh, this is UNIX
philosophy -- do one thing and do it well" or "Divide and conqer"? So,
we divided, and what have we conquered? :) After so many years we are
ending up with A3 approaching that has integrated MIDI and audio
anyway, a decade (too?) late.
... and this is why I've stopped using computers for music, and why the
nekosynth plugins haven't progressed in two years.
There is no way in hell I'm going near the utterly fundamentally
retarded mess of shit and fail that is Ardour 3.
It's a DAW. It shouldn't have *any* MIDI beyond control automation and
some idea of sync. Leave that to a sequencer.
Of course, there are no *usable* PC-based sequencers, so after gathering
dust for some ten years my 1/4" tape machine and Alesis MMT-8 are having
all the fun, and the PC just sits with pidgin, evolution and an ssh
session to my IRC client.
Linux audio is nowhere. There isn't a usable sample editor, there are a
couple of brave attempts at sequencers that lack pretty fundamental
features, and we have one DAW that seems to be going down the "do
everything, even if badly" route.
It's 2011. I've been at this for a decade. It's just as bad as it was
when I started trying to use PCs for music. I give up.
Gordon MM0YEQ
24 Feb
24 Feb
1:11 a.m.
On Wed, Feb 23, 2011 at 5:58 PM, Gordon JC Pearce <gordonjcp(a)gjcp.net> wrote:
There is no way in hell I'm going near the utterly
fundamentally
retarded mess of shit and fail that is Ardour 3.
gordon, we love you too. honest.
It's a DAW. It shouldn't have *any* MIDI
beyond control automation and
some idea of sync. Leave that to a sequencer.
its wierd how the overwhelming majority of folks out there in the
world don't seem to feel that this distinction is relevant to their
working style, and even more, whenever anybody does bring out a cool
new sequencer (e.g. nodal, or some of the hex- or octagonal sequencers
that have appeared recently) everyone starts wondering about how it
can be integrated into <theirDAW>.
Linux audio is nowhere. There isn't a usable
sample editor, there are a
couple of brave attempts at sequencers that lack pretty fundamental
features, and we have one DAW that seems to be going down the "do
everything, even if badly" route.
we haven't done OSC sequencing yet, so we still have plenty of room to
screw things up even more. oh, i forgot, *video*. yep, once we're done
with that, the stink will be so bad you'll have to wear a class 5
volatile vapor breathing apparatus to even sit down in front of your
computer. yeah, we are going to fuck with your mind you'll wish you
could just get back to DOS. which we'll run in a virtualbox instance
reparented inside an ardour window, just so that dave phillips can run
sequencer gold without any hassles. the future's so bright i've got to
wear a straightjacket! frizz me down with that kielbasse, officer!
It's 2011. I've been at this for a decade.
It's just as bad as it was
when I started trying to use PCs for music. I give up.
/me slaps on the peter gabriel and .... <hugs> .....
really, gordon, its OK. its going to be OK.
1:32 a.m.
On Wed, 2011-02-23 at 19:11 -0500, Paul Davis wrote:
What happened to the idea of doing one thing, and doing it well? I'm
not even totally sold on the idea of having the recorder and mixer in
the same app...
To that end, why has no-one managed to produce a PC (by which I mean the
general case of modern personal computer, not x86/PCI cards/beige box
PC) sequencer that doesn't suck overweight elephants through extremely
fine mesh? Cubase 3 on the Atari was simple, intuitive (well, apart
from the Interactive Phrase Synthesizer, I never met anyone that could
figure that out except for one guy from Orkney who lived in a house full
of cats and ate only yoghurt and green tea) and reliable. Surely it
cannot be beyond the wit of man to come up with something as good as
20-year-old software on hardware a million times as fast?
Gordon MM0YEQ
On Wed, Feb 23, 2011 at 5:58 PM, Gordon JC Pearce
<gordonjcp(a)gjcp.net> wrote:
Oh, that reminds me, it's just about donation time again, isn't it?
There is no way in hell I'm going near the
utterly fundamentally
retarded mess of shit and fail that is Ardour 3.
gordon, we love you too. honest. It's a
DAW. It shouldn't have *any* MIDI beyond control automation and
some idea of sync. Leave that to a sequencer.
its wierd how the overwhelming majority of folks out there in the
world don't seem to feel that this distinction is relevant to their
working style, and even more, whenever anybody does bring out a cool
new sequencer (e.g. nodal, or some of the hex- or octagonal sequencers
that have appeared recently) everyone starts wondering about how it
can be integrated into <theirDAW>.
1:39 a.m.
On Wed, Feb 23, 2011 at 7:33 PM, Gordon JC Pearce <gordonjcp(a)gjcp.net> wrote:
What happened to the idea of doing one thing, and
doing it well? I'm
not even totally sold on the idea of having the recorder and mixer in
the same app...
you probably want ayyi then. except ... oh well.
To that end, why has no-one managed to produce a PC
(by which I mean the
general case of modern personal computer, not x86/PCI cards/beige box
PC) sequencer that doesn't suck overweight elephants through extremely
fine mesh? Cubase 3 on the Atari was simple, intuitive
... and couldn't do shit with audio sequencing. so shall we move on?
cannot be beyond the wit of man to come up with
something as good as
20-year-old software on hardware a million times as fast?
what is beyond the wit of man is to define the meaning of "as good" in
a context where every neighbour has different intents and purposes.
1:41 a.m.
On Wed, Feb 23, 2011 at 7:39 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Wed, Feb 23, 2011 at 7:33 PM, Gordon JC Pearce
<gordonjcp(a)gjcp.net> wrote:
> What happened to the idea of doing one thing, and doing it well?
oh, and to answer that question: what happened was huge great
boatloads of data that need to be shovelled around between all the
relevant components, complicated synchronization in both the backend
models and the user interfaces of all the relevant components, and a
general disdain for complex *systems* when one can settle for merely
complex programs.
i mean, good god, why do i need to deal with freaking color channels
in the GIMP when all i want to do is a posterization, rotation,
surface mask and illumination effect?
12:43 p.m.
On Wed, Feb 23, 2011 at 07:41:56PM -0500, Paul Davis wrote:
and to answer that question: what happened was huge
great
boatloads of data that need to be shovelled around between all the
relevant components, complicated synchronization in both the backend
models and the user interfaces of all the relevant components, and a
general disdain for complex *systems* when one can settle for merely
complex programs.
There's no doubt that many users or potential users want the
'all integrated' DAW combining audio, sequencing, invasive
effects, etc. required to produce a particular type of music
(and some other content, e.g. ads) that happens to have a
wide audience. And consequently a large number of people
wanting to be involved in making it.
OTOH, this does not mean that some other people (who may be
a minority) can't have other needs, nor does it provide good
reasons to imply that they are in some way retarded, out of
sync with their time, old-fashioned or whatever.
It's also foolish to suggest that the 'all inclusive universal
DAW' will cater for those needs - just ignore what you don't
use etc. It most definitely does *not* because it's by no means
as universal as you may think, but rather the reflection of
one particular musical culture. Which means that whatever is
not used in that particular scene will not be provided. Ardour,
despite all it qualities and being a magnificent piece of work,
is a good example of that.
Also, 'ignoring the bits you don't need' is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.
And the most perverse consequence of preferring complex apps
to complex systems is that it becomes near impossible to modify
them to individual or 'minority' needs. To all effects, Ardour
is to me as closed as Protools is, just because it has become
so complex rather than just big, and I can't spend a year on
learning all of it. I'm at the mercy of its developers, and
they have good reasons to ignore my needs as they have done
for years. So the only remaining advantage is that it is free
as in free beer. And for a professional user that is irrelevant.
Spending some money on Protools is not really different to doing
the same for a kilometer of microphone cable or some XLR plugs.
Ciao,
--
FA
1:08 p.m.
On 02/24/2011 12:43 PM, Fons Adriaensen wrote:
It's also foolish to suggest that the 'all
inclusive universal
DAW' will cater for those needs - just ignore what you don't
use etc. It most definitely does *not* because it's by no means
as universal as you may think, but rather the reflection of
one particular musical culture. Which means that whatever is
not used in that particular scene will not be provided. Ardour,
despite all it qualities and being a magnificent piece of work,
is a good example of that.
Now you talk about features not being provided, when the starting point
was features that are provided.
Also, 'ignoring the bits you don't need'
is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.
Sure, a tool that offers exactly what you need and nothing more has
something reassuring to it. But how much do you get to see of Ardour's
MIDI support if you simply do not add any MIDI track to your session?
And for a professional user that is irrelevant.
Spending some money on Protools is not really different to doing
the same for a kilometer of microphone cable or some XLR plugs.
You pay license fees for cables and plugs and you would never alter them
in any way?
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
1:29 p.m.
And for a
professional user that is irrelevant.
Spending some money on Protools is not really different to doing
the same for a kilometer of microphone cable or some XLR plugs.
You pay license fees for cables and plugs and you would never alter them
in any way?
6:11 p.m.
On Thu, 2011-02-24 at 13:08 +0100, Thorsten Wilms wrote:
On 02/24/2011 12:43 PM, Fons Adriaensen wrote:
Oh, you havn't seen the latest improvements? The Ardour team noticed
that, since the track type selector is a combo box, literally not a
single pixel related to MIDI is shown during a purely audio related work
flow. This is, of course, a big problem in terms of our greater mission
to provide software that caters to the needs of precisely nobody while
irritating everybody else.
To resolve this situation, we now have an exciting new Clippy inspired
assistant that hops around your screen begging you to add MIDI tracks
constantly.
If, after 20 minutes, you have still not created a MIDI track, Ardour
will overwrite every .waf file found in your home directory with a 4/4
electronic kick drum loop, then shut down.
-dr
It's also foolish to suggest that the
'all inclusive universal
DAW' will cater for those needs - just ignore what you don't
use etc. It most definitely does *not* because it's by no means
as universal as you may think, but rather the reflection of
one particular musical culture. Which means that whatever is
not used in that particular scene will not be provided. Ardour,
despite all it qualities and being a magnificent piece of work,
is a good example of that.
Now you talk about features not being provided, when the starting point
was features that are provided.
Also, 'ignoring the bits you don't
need' is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.
Sure, a tool that offers exactly what you need and nothing more has
something reassuring to it. But how much do you get to see of Ardour's
MIDI support if you simply do not add any MIDI track to your session?
7:35 p.m.
On Thursday 24 February 2011 18:09:19 David Robillard wrote:
To resolve this situation, we now have an exciting new
Clippy inspired
assistant that hops around your screen begging you to add MIDI tracks
constantly.
Will you call it ardourino?
If, after 20 minutes, you have still not created a
MIDI track, Ardour
will overwrite every .waf file found in your home directory with a 4/4
electronic kick drum loop, then shut down.
You couldn't get the rights to use the amen-break for this?
Have (much!) fun,
Arnold
7:41 p.m.
On Thu, Feb 24, 2011 at 1:35 PM, Arnold Krille <arnold(a)arnoldarts.de>
You couldn't get the rights to use the amen-break
for this?
dude we don't use no breaks unless its "when the levee breaks", is
that clear? problem is, jimmy and the boys in zep wouldn't clear the
sample for us, so ...
we're using a break from barry manilow's "copacabana". its all good.
7:49 p.m.
The amen break has no rights attached to it. It was a gift from the gods. Now
whether or not those gods love or hate us is another matter...
Michael
----- Original Message ----
From: Arnold Krille <arnold(a)arnoldarts.de>
To: linux-audio-dev(a)lists.linuxaudio.org
Sent: Thu, February 24, 2011 12:35:39 PM
Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb
On Thursday 24 February 2011 18:09:19 David Robillard wrote:
To resolve this situation, we now have an exciting new
Clippy inspired
assistant that hops around your screen begging you to add MIDI tracks
constantly.
Will you call it ardourino?
If, after 20 minutes, you have still not created a
MIDI track, Ardour
will overwrite every .waf file found in your home directory with a 4/4
electronic kick drum loop, then shut down.
You couldn't get the rights to use the amen-break for this?
Have (much!) fun,
Arnold
9:11 p.m.
On Thu, Feb 24, 2011 at 6:49 PM, Michael Bechard <gothmagog(a)yahoo.com>wrote;wrote:
The amen break has no rights attached to it. It was a
gift from the gods.
Now
whether or not those gods love or hate us is another matter...
As far as I know the Winstons own the copyright (well... used to anyway, it
might have expired) but they never chased anyone about lifting the drums...
For an informative youtube browse there's a nice video on the start of
sampling, dnb, etc:
http://www.youtube.com/watch?v=5SaFTm2bcac
Cheers, -Harry
9:13 p.m.
Heh, yeah, I know. I was more commenting on how every DJ on the planet has
treated that sample. :)
Michael
________________________________
From: Harry Van Haaren <harryhaaren(a)gmail.com>
To: Michael Bechard <gothmagog(a)yahoo.com>
Cc: Arnold Krille <arnold(a)arnoldarts.de>de>; linux-audio-dev(a)lists.linuxaudio.org
Sent: Thu, February 24, 2011 2:11:20 PM
Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb
On Thu, Feb 24, 2011 at 6:49 PM, Michael Bechard <gothmagog(a)yahoo.com> wrote:
The amen break has no rights attached to it. It was a gift from the gods. Now
whether or not those gods love or hate us is another
matter...
As far as I know the Winstons own the copyright (well... used to anyway, it
might have expired) but they never chased anyone about lifting the drums...
For an informative youtube browse there's a nice video on the start of sampling,
dnb, etc:
http://www.youtube.com/watch?v=5SaFTm2bcac
Cheers, -Harry
2:02 p.m.
On Thu, Feb 24, 2011 at 6:43 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Wed, Feb 23, 2011 at 07:41:56PM -0500, Paul Davis
wrote:
i don't agree with you that its about a type of music. it is about the
difference between some different ways of producing music, and not
just two of them. there are certainly approaches to making music that
are not well served by a DAW. but they are approaches to the
production of music, not kinds of music.
and to answer that question: what happened was
huge great
boatloads of data that need to be shovelled around between all the
relevant components, complicated synchronization in both the backend
models and the user interfaces of all the relevant components, and a
general disdain for complex *systems* when one can settle for merely
complex programs.
There's no doubt that many users or potential users want the
'all integrated' DAW combining audio, sequencing, invasive
effects, etc. required to produce a particular type of music OTOH, this does not mean that some other people (who
may be
a minority) can't have other needs, nor does it provide good
reasons to imply that they are in some way retarded, out of
sync with their time, old-fashioned or whatever.
of course not. but the question still remains whether that particular
group of people would rather deal with a complex app that is tuned to
their needs or a complex system that can, optionally, be tuned to
their needs. the question doesn't change. there are people who are far
happier to deal with PD or Max than with a collection of plugins
inside a modular host - its the same kind of distinction.
It's also foolish to suggest that the 'all
inclusive universal
DAW' will cater for those needs - just ignore what you don't
use etc. It most definitely does *not* because it's by no means
as universal as you may think, but rather the reflection of
one particular musical culture.
i think you're wrong. its not that a DAW represents one particular
musical culture, it just reflects some cultures of music production
and not others. the notion that there is ever "one tool" for a task as
incredibly varied as producing music is absurd. nobody with half a
brain suggests that any DAW can be that tool.
Also, 'ignoring the bits you don't need'
is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.
i think you over-estimate the impact of this, although i agree that
its not zero.
And the most perverse consequence of preferring
complex apps
to complex systems is that it becomes near impossible to modify
them to individual or 'minority' needs.
i return to my earlier points above. why would you imagine that
tinkering with "the all inclusive universal DAW" is ever going to
produce the right tool for each individual or minority need. the whole
concept is just misformed.
learning all of it. I'm at the mercy of its
developers, and
they have good reasons to ignore my needs as they have done
for years. So the only remaining advantage is that it is free
not to be mercenary about it, but the difference is that if your needs
were that important and not being met by anything available to an
intolerable degree, you could (or some organization could) choose to
pay to have your needs met and not face any licensing/access issues in
doing so.. the open source nature of ardour, like the open source
nature of emacs and firefox and linux, doesn't mean that its going to
cater to everyone's needs as-is. the difference with protools is that
you can't even consider this as an option. is that a big difference?
it depends on whether a tool like ardour stands any hope of being the
solution. for people who like to make music with renoise or with
ensembles of cassette players and violins played with pencil erasers,
it very well may not be.
4:23 p.m.
On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote:
i don't agree with you that its about a type of
music. it is about the
difference between some different ways of producing music, and not
just two of them. there are certainly approaches to making music that
are not well served by a DAW. but they are approaches to the
production of music, not kinds of music.
Well, 'type' or even 'a particular type' can refer to a leaf node
in the taxonomy or to a quite solid branch of it.
The are classes of music that depend on sequencing etc. in order to
be produced at all - that's why people involved in them want those
features in the first place. I don't think it's wrong to call this
'a particular type of music', the type is defined by its dependence
on those tools.
i think you're wrong. its not that a DAW
represents one particular
musical culture, it just reflects some cultures of music production
and not others.
Indeed, see above.
the notion that there is ever "one tool" for
a task as
incredibly varied as producing music is absurd. nobody with half a
brain suggests that any DAW can be that tool.
Then maybe the term 'DAW' is misnomer. I wouldn't call a tool
that can't do simple four point editing an 'audio workstation'.
The sad fact here is that Ardour probably has 99% of the code
required to do it. The final 1% is missing because the concept
doesn't exist in the mindset of the developers. And by that I
don't want to suggest they are too stupid for it (as some may
choose to interpret my words), but just that they are focussed
on a 'type', 'class', 'category' or whatever you may call it
of music that doesn't require it.
not to be mercenary about it, but the difference is
that if your needs
were that important and not being met by anything available to an
intolerable degree, you could (or some organization could) choose to
pay to have your needs met and not face any licensing/access issues in
doing so..
Well, I could pay or I could offer my time as a developer. During
the last five years I have several times offered to integrate decent
multichannel or AMB panning into Ardour, provided I could team up
with someone taking care of the GUI aspects (I'm a nitwit regarding
writing for GTK). Nothing has happened. I've arrived at the point
where it quite clear that if I want certain functionality I'll be
on my own to implement it.
Ciao,
--
FA
5:17 p.m.
On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
what you don't know (because you're not on IRC) is the question of
N-point editing comes up a lot. i (and others) have argued (in my
opinion quite successfully) that four point editing is a relic of an
older workflow. others who have used 2, 3 and 4 point editing a lot on
other systems have argued back. nobody has been persuaded to change
their minds, and clearly nobody with the strong feelings in favor of
it has been motivated thus far to implement it.
On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis
wrote:
music is sound arranged in time (and optionally in space). i don't
know precisely what you mean by sequencing, but that means that any
production of music is going to involve arranging one or more of the
following things in time:
* carrying out physical movements
* playback of existing recordings of audio
* instructions (for a human and/or a machine) to do one or both of the above
to the extent that computers don't carry out physical movement (much),
any use of computers in the production of music means that it is going
to involve the 2nd and 3rd options. both of them have been called
"sequencing". ardour2 only does the second action right now; ardour3
adds the third (instructions for a machine).
i don't agree with you that its about a type
of music. it is about the
difference between some different ways of producing music, and not
just two of them. there are certainly approaches to making music that
are not well served by a DAW. but they are approaches to the
production of music, not kinds of music.
Well, 'type' or even 'a particular type' can refer to a leaf node
in the taxonomy or to a quite solid branch of it.
The are classes of music that depend on sequencing etc. in order to
be produced at all - that's why people involved in them want those
features in the first place. I don't think it's wrong to call this
'a particular type of music', the type is defined by its dependence
on those tools. the notion
that there is ever "one tool" for a task as
incredibly varied as producing music is absurd. nobody with half a
brain suggests that any DAW can be that tool.
Then maybe the term 'DAW' is misnomer. I wouldn't call a tool
that can't do simple four point editing an 'audio workstation'. choose to interpret my words), but just that they are
focussed
on a 'type', 'class', 'category' or whatever you may call it
of music that doesn't require it.
actually, i think i can speak clearly for carl and myself (the two
most active current developers; possibly most of the others too) when
i say that we are focussed on the feedback that we get from people who
repeatedly engage with us using the communication channels that we
find most convenient for this work. is that perfect? no. but its the
way things work out, at least for the last several years. the price of
entry into the exclusive club that is #ardour is simply time, nothing
more (or less).
Well, I could pay or I could offer my time as a
developer. During
the last five years I have several times offered to integrate decent
multichannel or AMB panning into Ardour, provided I could team up
with someone taking care of the GUI aspects (I'm a nitwit regarding
writing for GTK). Nothing has happened. I've arrived at the point
where it quite clear that if I want certain functionality I'll be
on my own to implement it.
if you can live with VBAP, this may interest you:
http://ardour.org/files/vbappanners.png
5:28 p.m.
On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote:
On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
i doubt, that he can live with vbap.
however, the ui should be pretty similar.
so maybe he only needs to port amb dsp code.
--
torben Hohn
On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul
Davis wrote:
Well, I could pay or I could offer my time as a developer. During
the last five years I have several times offered to integrate decent
multichannel or AMB panning into Ardour, provided I could team up
with someone taking care of the GUI aspects (I'm a nitwit regarding
writing for GTK). Nothing has happened. I've arrived at the point
where it quite clear that if I want certain functionality I'll be
on my own to implement it.
if you can live with VBAP, this may interest you:
5:31 p.m.
On Thu, Feb 24, 2011 at 11:28 AM, torbenh <torbenh(a)gmx.de> wrote:
On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis
wrote:
i was planning to do that myself at some point soon, actually. i just
have to get clear in my head whether i think any warning needs to
exist somewhere that using it generates b-format.
i also just discovered that VBAP doesn't do constant power panning
between outputs, which means it probably needs to be thrown away.
On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
i doubt, that he can live with vbap.
however, the ui should be pretty similar.
so maybe he only needs to port amb dsp code. On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul
Davis wrote:
Well, I could pay or I could offer my time as a developer. During
the last five years I have several times offered to integrate decent
multichannel or AMB panning into Ardour, provided I could team up
with someone taking care of the GUI aspects (I'm a nitwit regarding
writing for GTK). Nothing has happened. I've arrived at the point
where it quite clear that if I want certain functionality I'll be
on my own to implement it.
if you can live with VBAP, this may interest you:
5:46 p.m.
On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote:
what you don't know (because you're not on
IRC) is the question of
N-point editing comes up a lot. i (and others) have argued (in my
opinion quite successfully) that four point editing is a relic of an
older workflow. others who have used 2, 3 and 4 point editing a lot on
other systems have argued back. nobody has been persuaded to change
their minds, and clearly nobody with the strong feelings in favor of
it has been motivated thus far to implement it.
Then tell me how to do the following:
replace a range A-B by another one C-D, with user controllable
short xfades at the transitions, and so that everything to the
right of B (which may mean disjoint regions) moves as required
to make space for C-D. On all tracks, or some selected ones.
With the option to listen to each side of a transition separately,
and ajust it, without having to move away the other side.
actually, i think i can speak clearly for carl and
myself (the two
most active current developers; possibly most of the others too) when
i say that we are focussed on the feedback that we get from people who
repeatedly engage with us using the communication channels that we
find most convenient for this work. is that perfect? no. but its the
way things work out, at least for the last several years. the price of
entry into the exclusive club that is #ardour is simply time, nothing
more (or less).
I don't have the time to hang out in chat room all day. Fortunately
I also have other things to do. You can of course choose to ignore
this list and others, and emails, but using these are a far better
use of my (or anybody's) time.
if you can live with VBAP, this may interest you:
I'm generally not interested in VBAP. I provides the worst surround
possible, even worse than most 5.1 panners. And in those rare cases where
it would be a good solution, I can derive the required signals from a more
universal encoding.
Ciao,
--
FA
6:39 p.m.
On Thu, Feb 24, 2011 at 11:46 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis
wrote:
the position that i take with N-point editing is not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
anyway, i've been through this debate at least 4 times in the last 2
years. i didn't persuade people who feel that its critical, and they
didn't persuade me. status quo.
what you don't know (because you're not
on IRC) is the question of
N-point editing comes up a lot. i (and others) have argued (in my
opinion quite successfully) that four point editing is a relic of an
older workflow. others who have used 2, 3 and 4 point editing a lot on
other systems have argued back. nobody has been persuaded to change
their minds, and clearly nobody with the strong feelings in favor of
it has been motivated thus far to implement it.
Then tell me how to do the following: I don't have the time to hang out in chat room all
day. Fortunately
i didn't say that. but i will say this. i could have had this
conversation with you on IRC in about 50% of the time it takes via
email.
IRC is one of the channels i meant. but what i meant much more was a
reference to those people who, either via IRC, email or the bug
tracker, get involved in an issue or feature and move it forward by
(a) creating the "loop" (b) staying in the "loop". there are many
bugs
in ardour that i haven't fixed because i don't personally see them as
big issues and because nobody has convinced me otherwise. it doesn't
mean i'm right, but it does mean that if i (or someone else) is going
to switch focus to feature X or bug Y, even though i (or someone else)
isn't that motivated to do so, someone has to play advocate for the
role. and its not an advocate in a sea of silence. there are long
lists of bugs and long lists of cool features that we *want* to work
on, at all times. for something to rise up above that particular ocean
of noise does, unfortunately, sometimes require a bit of advocacy that
goes beyond an email to a mailing list describing a problem.
I'm generally not interested in VBAP. I provides
the worst surround
possible, even worse than most 5.1 panners. And in those rare cases where
it would be a good solution, I can derive the required signals from a more
universal encoding.
well, panners in a3 are now plugins, of a fashion (they are a bit
different from normal plugin APIs for a variety of reasons, primarily
the fact that they never do in-place processing). its quite likely
that at least the simplest of your ambi LADSPA plugins will show up in
that fashion in the not too distant future, with a GUI very similar to
the one in that screen shot.
when i was in berlin attending "serious" concerts of electro-acoustic
music, there seemed to be quite a range of opinion about ambisonics
versus VBAP. although i tend to take your word for it on such matters,
there were quite several smart people with years of experience in
multi-speaker setups who had real issues with ambisonics and felt that
VBAP was generally preferable. i don't want to make people choose.
6:59 p.m.
On 02/24/2011 06:39 PM, Paul Davis wrote:
well, panners in a3 are now plugins, of a fashion
(they are a bit
different from normal plugin APIs for a variety of reasons, primarily
the fact that they never do in-place processing). its quite likely
that at least the simplest of your ambi LADSPA plugins will show up in
that fashion in the not too distant future, with a GUI very similar to
the one in that screen shot.
nice :)
when i was in berlin attending "serious"
concerts of electro-acoustic
music, there seemed to be quite a range of opinion about ambisonics
versus VBAP. although i tend to take your word for it on such matters,
there were quite several smart people with years of experience in
multi-speaker setups who had real issues with ambisonics and felt that
VBAP was generally preferable. i don't want to make people choose.
actually, i didn't like what i heard of vbap so far, but it does work as
advertised, even under very adverse conditions. unless we have franz
zotter's partial sphere magic firmly in place for all workflows, *and*
there are kick-ass, fool-proof automatic ambisonic decoder generators
for even the most pathological speaker layouts, vbap sure has its place.
9:45 p.m.
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
the position that i take with N-point editing is not
that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
The only conclusion I can arrive at from this, and despite lots
of effort to avoid it, is that you don't have a clue as to what
is involved in editing e.g. classic music recordings.
Ciao,
--
FA
10:13 p.m.
On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis
wrote:
unfortunately, your conclusion would be wrong.
the position that i take with N-point editing is
not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
The only conclusion I can arrive at from this, and despite lots
of effort to avoid it, is that you don't have a clue as to what
is involved in editing e.g. classic music recordings.
10:58 p.m.
On Thu, Feb 24, 2011 at 04:12:58PM -0500, Paul Davis wrote:
On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Unfortunately, I don't think so. Or you have other reasons
for not providing the sort of functionality that is needed.
Without a single exception, everyone involved in this sort of
work (classic or more generally, 'acoustic' music recording
and editing) that I've shown Ardour to has said more or less
the same thing: 1. it can't do it, or at best in a very clumsy
way, and 2. it's a marvellous program otherwise, and it would
probably take very little to solve its obvious problems.
Not my words, but I do agree with them.
--
FA
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul
Davis wrote:
unfortunately, your conclusion would be wrong. the position that i take with N-point editing is
not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
The only conclusion I can arrive at from this, and despite lots
of effort to avoid it, is that you don't have a clue as to what
is involved in editing e.g. classic music recordings.
11:02 p.m.
You are full of even more shit than I am - can you just f-off and write your own
DAW? Or at least go and write apps for an OS that has other developer lists.
"we have to make sure that old fag [Fons] does disappear”.
Jim Wong, president of IT products, Acer
Date: Thu, 24 Feb 2011 21:58:12 +0000
From: fons(a)linuxaudio.org
To: paul(a)linuxaudiosystems.com
CC: linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb
On Thu, Feb 24, 2011 at 04:12:58PM -0500, Paul Davis wrote:
On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Unfortunately, I don't think so. Or you have other reasons
for not providing the sort of functionality that is needed.
Without a single exception, everyone involved in this sort of
work (classic or more generally, 'acoustic' music recording
and editing) that I've shown Ardour to has said more or less
the same thing: 1. it can't do it, or at best in a very clumsy
way, and 2. it's a marvellous program otherwise, and it would
probably take very little to solve its obvious problems.
Not my words, but I do agree with them.
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul
Davis wrote:
unfortunately, your conclusion would be wrong. the position that i take with N-point editing is
not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
The only conclusion I can arrive at from this, and despite lots
of effort to avoid it, is that you don't have a clue as to what
is involved in editing e.g. classic music recordings.
10:20 p.m.
On 2/24/11, Fons Adriaensen wrote:
You know, I find this kind of attitude quite dangerous. JAMin
developers not having clue, Ardour developers not having and clue, and
then there's Fons in the shining armour never telling what is the
right thing exactly, because "This is an error that any DSP student is
allowed to make once". As much as I treasure your contribution (and I
do), this is really disturbing. Especially since we are *sort of*
community that is supposed to *sort of* share knowledge.
Alexandre Prokoudine
http://libregraphicsworld.org
the position
that i take with N-point editing is not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
The only conclusion I can arrive at from this, and despite lots
of effort to avoid it, is that you don't have a clue as to what
is involved in editing e.g. classic music recordings.
10:39 p.m.
On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote:
You know, I find this kind of attitude quite
dangerous.
What attitude ?
JAMin developers not having clue,
Didn't write that.
Ardour developers not having and clue
About one very specfic issue.
"This is an error that any DSP student is allowed
to make once".
This is absolutely true for the one I referred to.
Especially since we are *sort of* community that is
supposed
to *sort of* share knowledge.
Indeed. And what knowledge have you been sharing lately ?
--
FA
11:05 p.m.
On 2/25/11, Fons Adriaensen wrote:
See below.
*sigh*
Really?
"'True. After all those years none of the 'DSP experts' developing Jamin
has noticed anything wrong when listening to it (it's quite obvious
actually), let alone done a simple measurement that could have revealed
this problem even before the first release."
These were your words.
So what I'm seeiing is that while JAMin guys write in their list that
you, Fons, have interesting ideas about improvements in the backend,
you, in return, write that utter bullshit. And then you pretend you
never did that.
And now I see this repeating with Ardour team.
Lately I've been spreading tolerance and respect to fellow community
members with a shovel. I'm pretty sure I can find some for you.
Alexandre Prokoudine
http://libregraphicsworld.org
You know, I
find this kind of attitude quite dangerous.
What attitude ? JAMin
developers not having clue,
Didn't write that. Especially
since we are *sort of* community that is supposed
to *sort of* share knowledge.
Indeed. And what knowledge have you been sharing lately ?
11:13 p.m.
On Fri, Feb 25, 2011 at 01:05:03AM +0300, Alexandre Prokoudine wrote:
"'True. After all those years none of the
'DSP experts' developing Jamin
has noticed anything wrong when listening to it (it's quite obvious
actually), let alone done a simple measurement that could have revealed
this problem even before the first release."
Which is simply true. A simple measurement would have revealed that
particular problem. Some critical listening would have revealed it
as well.
The term 'DSP experts' was first used not by me, but in an attempt
to discredit what I wrote. So don't blame me for quoting it.
These were your words.
And I'll repeat them any time you want.
--
FA
25 Feb
25 Feb
12:48 a.m.
On Thu, 2011-02-24 at 21:39 +0000, Fons Adriaensen wrote:
As absolutely true as when I say the obviously terrible software
architecture / design decisions that come out of certain DSP heads
are... well, obvious terrible to anyone who actually knows what they are
doing in that field?
The trick is to know what you're good at, and shut up about the rest.
-dr (Who couldn't - and thus won't try to - tell you the first thing
about DSP, or classical music editing, or ...)
On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre
Prokoudine wrote:
[...]
"This is
an error that any DSP student is allowed to make once".
This is absolutely true for the one I referred to.
1:34 a.m.
On Thu, Feb 24, 2011 at 06:47:10PM -0500, David Robillard wrote:
On Thu, 2011-02-24 at 21:39 +0000, Fons Adriaensen
wrote:
As absolutely true as when I say the obviously terrible software
architecture / design decisions that come out of certain DSP heads
are... well, obvious terrible to anyone who actually knows what they are
doing in that field?
That could very well be the case.
With N >= 1000:
There are some things I know about, N times more things I'm
interested in, know a little about and want to learn more,
and again N times more I don't know anything about. That's
life.
Now I'm here, I do have a question. And please just take it
for what it is and don't look for anything behind it as there
isn't anything.
How did you arrive at the name 'ingen' ?
This evening I happened to stumble on an episode of 'Midsommer
Murders', a famous English detective TV series, on Youtube.
Strangely enough it had Swedish (I think) subtitles. From which
I learned that 'ingen' is Swedish for 'no, nobody, nothing' or
similar...
Again, that's not meant to be a comment on your program, just
curious.
Ciao,
--
FA
On Fri, Feb 25, 2011 at 12:20:44AM +0300,
Alexandre Prokoudine wrote:
[...]
"This is an error that any DSP student is allowed to make once".
This is absolutely true for the one I referred to. 
1:43 a.m.
On Fri, 2011-02-25 at 00:34 +0000, Fons Adriaensen wrote:
I learned that 'ingen' is Swedish for 'no,
nobody, nothing' or
similar...
Nobody it is.
--
Brand new stockings
http://mx44.linux.dk/notturno/brand_new_stockings.mp3
12:28 p.m.
On Fri, Feb 25, 2011 at 01:42:46AM +0100, Jens M Andreasen wrote:
On Fri, 2011-02-25 at 00:34 +0000, Fons Adriaensen wrote:
Tack :-)
Also noticed 'ingen fara' -> no problem and 'ingen aning' -> no
idea.
--
FA
I learned that 'ingen' is Swedish for
'no, nobody, nothing' or
similar...
Nobody it is.
2:03 p.m.
On Fri, 2011-02-25 at 11:28 +0000, Fons Adriaensen wrote:
Also noticed 'ingen fara' -> no problem
and 'ingen aning' -> no idea.
In a compound statement, yes
And then You have the Scottish Gaelic "inghean" from Old Irish
"ingen"
meaning "daughter" which might be related to the Swedish/Norwegian
female name "Inga" which in turn also happens to be the pluralis form of
"none"?
Or it could be a reference to InGen systems, from Jurassic Parc ..
http://ingenaning.com/noidea.html
/j
--
Brand new stockings
http://mx44.linux.dk/notturno/brand_new_stockings.mp3
26 Feb
26 Feb
5:59 a.m.
On Fri, Feb 25, 2011 at 02:02:09PM +0100, Jens M Andreasen wrote:
On Fri, 2011-02-25 at 11:28 +0000, Fons Adriaensen wrote:
Or a reference to the Japanese term meaning 'string beans'.
--
Joel Roth
Also noticed 'ingen fara' -> no
problem and 'ingen aning' -> no idea.
In a compound statement, yes
And then You have the Scottish Gaelic "inghean" from Old Irish
"ingen"
meaning "daughter" which might be related to the Swedish/Norwegian
female name "Inga" which in turn also happens to be the pluralis form of
"none"?
Or it could be a reference to InGen systems, from Jurassic Parc ..
25 Feb
25 Feb
6:52 p.m.
On Fri, 2011-02-25 at 00:34 +0000, Fons Adriaensen wrote:
On Thu, Feb 24, 2011 at 06:47:10PM -0500, David
Robillard wrote:
Indeed.
On Thu, 2011-02-24 at 21:39 +0000, Fons
Adriaensen wrote:
As absolutely true as when I say the obviously terrible software
architecture / design decisions that come out of certain DSP heads
are... well, obvious terrible to anyone who actually knows what they are
doing in that field?
That could very well be the case.
With N >= 1000:
There are some things I know about, N times more things I'm
interested in, know a little about and want to learn more,
and again N times more I don't know anything about. That's
life. On Fri, Feb 25, 2011 at 12:20:44AM +0300,
Alexandre Prokoudine wrote:
[...]
"This is an error that any DSP student is allowed to make once".
This is absolutely true for the one I referred to. Now I'm here, I do have a question. And please
just take it
for what it is and don't look for anything behind it as there
isn't anything.
How did you arrive at the name 'ingen' ?
Mainly, INstrument GENerator, and the fact that it's like "engine".
This evening I happened to stumble on an episode of
'Midsommer
Murders', a famous English detective TV series, on Youtube.
Strangely enough it had Swedish (I think) subtitles. From which
I learned that 'ingen' is Swedish for 'no, nobody, nothing' or
similar...
Again, that's not meant to be a comment on your program, just
curious.
Yeah, if I had a nickel for every time that's been mentioned to me I
wouldn't have to beg for donations anymore :)
I actually like the connection in a way, since the whole point of Ingen
is to be a minimal framework in which to wire up generic plugins to do
what you want. The plugins are the rock stars, Ingen is just the stage.
I also have a penchant for Zen, and there's certainly no thing wrong
with no thing ;)
It's also the company in Jurassic Park. One day I'll make it to #1
Google hit. One day!
-dr
7:01 p.m.
On Fri, Feb 25, 2011 at 8:50 PM, David Robillard wrote:
It's also the company in Jurassic Park. One day
I'll make it to #1
Google hit. One day!
You already have :) Just try it.
Alexandre Prokoudine
http://libregraphicsworld.org
9:43 p.m.
Clear your cookies and try again. Google must know you are involved
in Linux Audio ;)
On Fri, Feb 25, 2011 at 1:01 PM, Alexandre Prokoudine
<alexandre.prokoudine(a)gmail.com> wrote:
On Fri, Feb 25, 2011 at 8:50 PM, David Robillard
wrote:
It's also the company in Jurassic Park. One
day I'll make it to #1
Google hit. One day!
You already have :) Just try it.
Alexandre Prokoudine
http://libregraphicsworld.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
26 Feb
26 Feb
4:40 p.m.
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
the position that i take with N-point editing is not
that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
Tell that to your customer when he (or she in this case) wants you
to replace part of an edited track with the same fragment from
another take.
A simple case:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/d_amor_sull_ali_rosee2.mp3>
After this was edited (9 fragments from 4 takes), the singer wanted
to replace the part "del prigioniere misero conforta l'egra mente"
[2:03 to 2:27] by another take.
Now I could have told her that what she wanted was 'rooted in an
older way of thinking', or that she was stupid and should have had
that bright idea before we had done the five edits following this
fragment, but I didn't and actually performed the edit to her
satisfaction.
Now this was a simple demo with just the piano instead of a full
orchestra. The latter could easily be more than 20 tracks if the
recording is done live and no mics must be visible. And mixing it
before editing is usually *not* and option.
Quiz2: there are 10 edits in this recording, free beer at LAC2011
if you can find 5 of them.
Ciao,
--
FA
4:52 p.m.
On Sat, Feb 26, 2011 at 10:40 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis
wrote:
i'm confused about who the customer is. the older way of thinking
about the overall workflow is an attribute of the engineer/editor, not
the singer.
if the engineer/editor is the customer, i'd tell them to use another
program right now because ardour doesn't support their workflow. i try
not to spend much time convincing people to work in a different way
than they are used to, it seems pretty pointless to me since i don't
really believe that one way is superior to the others (though some are
definitely more connected to ideas rooted in some kind physical
operation like tape splicing).
hint: there's no reason to replace the section from [2:03 to 2:27]
with another take at all.
the position that i take with N-point editing is
not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
Tell that to your customer when he (or she in this case) wants you
to replace part of an edited track with the same fragment from
another take. Now I could have told her that what she wanted was
'rooted in an
older way of thinking', or that she was stupid and should have had
that bright idea before we had done the five edits following this
fragment,
that would just have confirmed that you have the skills to be abrasive
and difficult to get along with when you choose to.
but I didn't and actually performed the edit to
her
satisfaction.
much better idea.
10:44 p.m.
On Sat, 26 Feb 2011 10:52:05 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sat, Feb 26, 2011 at 10:40 AM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
hi,
I'm noob with ardour but I'd like to understand, how would one solve a
problem such as the one posed by Fons?
If I understand correctly you're saying that if you use a different
workflow while setting up the project / recording you wan't fall in
this problem, so could you explain what is this different workflow?
cheers
renato
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul
Davis wrote:
i'm confused about who the customer is. the older way of thinking
about the overall workflow is an attribute of the engineer/editor, not
the singer.
if the engineer/editor is the customer, i'd tell them to use another
program right now because ardour doesn't support their workflow. i try
not to spend much time convincing people to work in a different way
than they are used to, it seems pretty pointless to me since i don't
really believe that one way is superior to the others (though some are
definitely more connected to ideas rooted in some kind physical
operation like tape splicing).
hint: there's no reason to replace the section from [2:03 to 2:27]
with another take at all.
the position that i take with N-point editing is
not that there is
some other way to do "the following". There isn't. its that the
way of approaching the task that leads to needing to do "the
following" is rooted in an older way of thinking about the overall
workflow.
Tell that to your customer when he (or she in this case) wants you
to replace part of an edited track with the same fragment from
another take. 
27 Feb
27 Feb
1:05 a.m.
Fons
Being someone that tracks recordings live constantly, I am curious, if the
singer only wanted to overdub one section of their vocals with another, and
you are not touching the remainder of the recorded tracks, exactly what
stops you from doing a standard punch in/out in your example?
Even if you are referring to replacing a mixdown take, I am not certain 4
point editing is to much of a benefit there persay to be honest, as I have
done this without it quite well in the past as I often have to edit down
recordings for dance choreographers for modified music in a way you can't
tell it is edited obviously.
I have never used 4 point editing, and have done mixing of all varieties,
musical and non, from many different genres including some classical. There
are points where I can easily see 4 point editing being useful as has been
explained to me in the past by people that do use it, but this is not one of
them if I am understanding your question correctly. (Of course I can't think
of a good example at the moment where I was thinking it would be useful, but
I remember being told some in the past and thinking it would be).
Seablade
On Sat, Feb 26, 2011 at 10:40 AM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis
wrote:
After this was edited (9 fragments from 4 takes), the singer wanted
to replace the part "del prigioniere misero conforta l'egra mente"
[2:03 to 2:27] by another take.
Now I could have told her that what she wanted was 'rooted in an
older way of thinking', or that she was stupid and should have had
that bright idea before we had done the five edits following this
fragment, but I didn't and actually performed the edit to her
satisfaction.
Now this was a simple demo with just the piano instead of a full
orchestra. The latter could easily be more than 20 tracks if the
recording is done live and no mics must be visible. And mixing it
before editing is usually *not* and option.
Quiz2: there are 10 edits in this recording, free beer at LAC2011
if you can find 5 of them.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
the position that i take with N-point editing is
not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.
Tell that to your customer when he (or she in this case) wants you
to replace part of an edited track with the same fragment from
another take.
A simple case:
<
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/d_amor_sull_ali_rose…
10:38 a.m.
On 02/27/2011 01:05 AM, Thomas Vecchione wrote:
Fons
Being someone that tracks recordings live constantly, I am curious, if
the singer only wanted to overdub one section of their vocals with
another, and you are not touching the remainder of the recorded tracks,
exactly what stops you from doing a standard punch in/out in your example?
in classical recording sessions, overdubs happen rarely if ever.
i guess the situation here is that multiple full or partial takes were
recorded with the full ensemble, and the editing happens afterwards,
when all musicians are gone.
iiuc, the soloist requested one section to be replaced with another
take. since there is no "click", this usually means that the part after
the new spliced-in section will move in time, slightly.
which is a bit of a problem in ardour while you haven't consolidated
region fragments (which often you don't want to do until the very end),
because you have to be very careful to move all subsequent regions.
easy in the vertical thanks to edit groups, but quite hard in the
horizontal. or maybe i'm overlooking yet another feature?
best,
jörn
11:41 a.m.
Hi,
This feature is actually also very useful in post production for film
or TV, where often you get a video edit after you've started doing
your mixing, and you have to move big blocks of tracks in time. I'd
also like to know if there's a simple way to do this in ardour, or to
add my vote for it =)
Cheers,
Andres
2011/2/27 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 02/27/2011 01:05 AM, Thomas Vecchione wrote:
Fons
Being someone that tracks recordings live constantly, I am curious, if
the singer only wanted to overdub one section of their vocals with
another, and you are not touching the remainder of the recorded tracks,
exactly what stops you from doing a standard punch in/out in your example?
in classical recording sessions, overdubs happen rarely if ever.
i guess the situation here is that multiple full or partial takes were
recorded with the full ensemble, and the editing happens afterwards, when
all musicians are gone.
iiuc, the soloist requested one section to be replaced with another take.
since there is no "click", this usually means that the part after the new
spliced-in section will move in time, slightly.
which is a bit of a problem in ardour while you haven't consolidated region
fragments (which often you don't want to do until the very end), because you
have to be very careful to move all subsequent regions.
easy in the vertical thanks to edit groups, but quite hard in the
horizontal. or maybe i'm overlooking yet another feature?
best,
jörn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:21 p.m.
Yes film and TV post is where I have heard of it being more useful, but
since I just got up I will leave that for the moment until my brain is more
awake;)
Fons replied off list and we discussed his example some, The situations was
similar to what i had thought, where a 4 point edit was one possible way to
do it, but far from the only.solution, and probably wouldn't be what I
personally used. The real issue was A2's lack of an ability to move
automation with regions, which Carl has addressed in A3 IIRC. I didn't
spell this out as much as I should have in my reply to Fons on list however
due to typing on my cell phone at the time:)
Seablade
PS For the record yes I understand an overdub wouldn't be likely in
classical recording, an even less so in tracking live performances which is
more of what I am used to doing obviously, but in that particular situation
is something I could see doing since the singer had requested it I assume
they were present. However this wasn't the situation presented above, thus
my post above.
2011/2/27 Andres Cabrera <mantaraya36(a)gmail.com>
Hi,
This feature is actually also very useful in post production for film
or TV, where often you get a video edit after you've started doing
your mixing, and you have to move big blocks of tracks in time. I'd
also like to know if there's a simple way to do this in ardour, or to
add my vote for it =)
Cheers,
Andres
2011/2/27 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 02/27/2011 01:05 AM, Thomas Vecchione wrote:
>
> Fons
>
> Being someone that tracks recordings live constantly, I am curious, if
> the singer only wanted to overdub one section of their vocals with
> another, and you are not touching the remainder of the recorded tracks,
> exactly what stops you from doing a standard punch in/out in your
example?
in classical recording sessions, overdubs happen rarely if ever.
i guess the situation here is that multiple full or partial takes were
recorded with the full ensemble, and the editing happens afterwards, when
all musicians are gone.
iiuc, the soloist requested one section to be replaced with another take.
since there is no "click", this usually means that the part after the new
spliced-in section will move in time, slightly.
which is a bit of a problem in ardour while you haven't consolidated
region
fragments (which often you don't want to do
until the very end), because
you
have to be very careful to move all subsequent
regions.
easy in the vertical thanks to edit groups, but quite hard in the
horizontal. or maybe i'm overlooking yet another feature?
best,
jörn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
2:19 p.m.
On Sun, Feb 27, 2011 at 06:21:29AM -0500, Thomas Vecchione wrote:
Fons replied off list and we discussed his example
some, The situations was
similar to what i had thought, where a 4 point edit was one possible way to
do it, but far from the only.solution, and probably wouldn't be what I
personally used.
Exactly, a 4-pt is not the only way to do it, and I'd probably split
it up into two edits anyway unless the part to be replaced was very
short (which happens, I've been replacing single notes in some cases).
What I don't accept is the suggestion that this sort of thing is never
necessary, and that if it is, that is just the result of using the
wrong 'workflow'. So far I haven't seen any alternative 'workflow'
that would actually get the job done.
The real issue was A2's lack of an ability to
move
automation with regions, which Carl has addressed in A3 IIRC.
Not in this case, as there was no automation. The real issue is
that it is very difficult to move everything to the right of the
edit, in particular if this alternates with trimming the start
point, trimming the end point of the left side, and listening
to the result. It requires constant changing of selections,
and zoom factors. One 'erreur de manip' and something gets
damaged, and if you don't notice that immediately (and very
probably you don't if you are zoomed in) it becomes a nightmare
to repair.
The underlying problem are
1. That everything is 'visual', done by actually moving regions
and their endpoints on screen (and quite ofter being sure you
get the right one of these actions is an exercise by itself).
2. That Ardour has no idea at all of what you want to do, it just
sees a series of individual operations and consequently can't
provide any support. For example if you want to listen to the
end of the left part followed by silence, or the start of the
right part (to trim them), the only way is to move the right
part away, destroying any tentative edit you may already have.
Ciao,
--
FA
1:18 a.m.
On Sat, Feb 26, 2011 at 7:40 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
<SNIP>
A simple case:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/d_amor_sull_ali_rosee2.mp3>
After this was edited (9 fragments from 4 takes), the singer wanted
to replace the part "del prigioniere misero conforta l'egra mente"
[2:03 to 2:27] by another take.
<SNIP>
I don't give a flip about convolution reverbs, LVL2 gtk vs qt, or
where I host a VST.
I do however love a good piece of music.
Thanks for sharing.
- Mark
2:17 a.m.
On Sat, Feb 26, 2011 at 04:18:30PM -0800, Mark Knecht wrote:
I don't give a flip about convolution reverbs,
LVL2 gtk vs qt, or
where I host a VST.
-:) Strangely enough, this is not about any of these subjects :-)
I do however love a good piece of music.
Thanks for sharing.
Verdi, Rigoletto.
Ciao,
--
FA
24 Feb
24 Feb
2:07 p.m.
On Thu, Feb 24, 2011 at 2:43 PM, Fons Adriaensen wrote:
There's no doubt that many users or potential
users want the
'all integrated' DAW combining audio, sequencing, invasive
effects, etc. required to produce a particular type of music
(and some other content, e.g. ads) that happens to have a
wide audience. And consequently a large number of people
wanting to be involved in making it.
That sounds like an intentionally badly hidden sarcasm.
OTOH, this does not mean that some other people (who
may be
a minority) can't have other needs, nor does it provide good
reasons to imply that they are in some way retarded, out of
sync with their time, old-fashioned or whatever.
MIDI tracks in A3 are not forced to users at knife-point.
Also, 'ignoring the bits you don't need'
is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.
The question I'm inclined to ask is whether you ever saw A3 live.
Because, really, until you choose to add a MIDI track, the related
functionality barely exposes itself.
And the most perverse consequence of preferring
complex apps
to complex systems is that it becomes near impossible to modify
them to individual or 'minority' needs.
http://createdigitalmusic.com/2011/02/the-79-virtual-analog-console-now-on-…
"Coming from the rarified world of high-end audio systems, we
recognized a lot of the same qualities in Ardour. Some examples:
<snip> “customization on a truly deep level is important for
enterprise-class facilities” …. stuff like that."
You had it coming, Fons.
Alexandre Prokoudine
http://libregraphicsworld.org
2:45 p.m.
On Thu, Feb 24, 2011 at 8:07 AM, Alexandre Prokoudine
<alexandre.prokoudine(a)gmail.com> wrote:
http://createdigitalmusic.com/2011/02/the-79-virtual-analog-console-now-on-…
"Coming from the rarified world of high-end audio systems, we
recognized a lot of the same qualities in Ardour. Some examples:
<snip> “customization on a truly deep level is important for
enterprise-class facilities” …. stuff like that."
Well, *they* would say that. They like Ardour. And they live in
Nashville. Say no more, eh? :)
3:46 p.m.
On Thu, Feb 24, 2011 at 04:07:41PM +0300, Alexandre Prokoudine wrote:
I never said they were.
Ciao,
--
FA
On Thu, Feb 24, 2011 at 2:43 PM, Fons Adriaensen
wrote:
Absolutely none intended. It's just a fact.
There's no doubt that many users or potential
users want the
'all integrated' DAW combining audio, sequencing, invasive
effects, etc. required to produce a particular type of music
(and some other content, e.g. ads) that happens to have a
wide audience. And consequently a large number of people
wanting to be involved in making it.
That sounds like an intentionally badly hidden sarcasm. OTOH, this
does not mean that some other people (who may be
a minority) can't have other needs, nor does it provide good
reasons to imply that they are in some way retarded, out of
sync with their time, old-fashioned or whatever.
MIDI tracks in A3 are not forced to users at knife-point.
1:23 a.m.
On Wed, 2011-02-23 at 22:58 +0000, Gordon JC Pearce wrote:
On Wed, 2011-02-23 at 19:55 +0300, Alexandre
Prokoudine wrote:
LOL. Let me see if I have this straight: "I don't personally want a
'sequencer', therefore this program is a 'DAW', and therefore it
obviously should not be doing MIDI anything because I have conveniently
defined it as something that shouldn't". Solid argument.
Did you happen to notice how virtually every single popular PC DAW in
existence doesn't agree with your take on what they should do? How you
completely disregard overwhelming user demand (with no actual argument
behind it, no less)?
I'm not sure how you would attempt to justify this hilariously
curmudgeony opinion to a user who wants to work with audio and MIDI on a
timeline, but I'd sure like to hear it for entertainment's sake. Or is
working with audio and MIDI on a timeline somehow an inherently invalid
goal? Why, exactly? If I want to arrange some MIDI and audio on a
timeline (i.e. make music) I'm supposed to deal with the massively
clunky PITA of using separate programs to do so? What, exactly, is the
win there? What, exactly, is the user gaining?
If you're into "do one thing and do it well", there is actually a
logical argument in saying Ardour shouldn't have a mixer: particularly
with Jack, a process barrier between timeline and mixer/effects/etc
actually makes some sense. A process barrier between two timelines based
on the irrelevant detail of what kind of data you can stick in them does
not. The obscene amount of code duplication involved in that scenario is
pretty telling evidence that something is crap. What you are saying
simply does not make any sense whatsoever, and, coincidentally,
virtually everybody who has made music on a computer in the past several
decades disagrees with it. Hm. Everyone is wrong and you are right, eh?
Must be rough. Kids these days!
-dr
For how many years did we have to use
Rosegarden/MusE and Ardour *and*
Hydrogen simultaneously just to get *basic* DAW functionality only
because everyone went on saying things like "Oh, this is UNIX
philosophy -- do one thing and do it well" or "Divide and conqer"? So,
we divided, and what have we conquered? :) After so many years we are
ending up with A3 approaching that has integrated MIDI and audio
anyway, a decade (too?) late.
... and this is why I've stopped using computers for music, and why the
nekosynth plugins haven't progressed in two years.
There is no way in hell I'm going near the utterly fundamentally
retarded mess of shit and fail that is Ardour 3.
It's a DAW. It shouldn't have *any* MIDI beyond control automation and
some idea of sync. Leave that to a sequencer.
1:55 a.m.
On 2/24/11, Gordon JC Pearce wrote:
It's a DAW. It shouldn't have *any* MIDI
beyond control automation and
some idea of sync. Leave that to a sequencer.
I think I know your next argument: we don't need virtual instruments
as plug-ins, eh? And while at that, let's dump lash/ladish crap
altogether. Session management is for n00bs, real musicians have sound
engineers to do it for them, so they can focus on actual music :)
(On reflection, it provides a new dimension to my recent little visual
joke about Dream Theater's approach to music:
http://prokoudine.info/files/dream-theater.png (says "What's the
rush?") Paul, how about visualization of little pixies doing JACK
transport or pitch-shifting in A3? I know Gordon would love it :))
Of course, there are no *usable* PC-based sequencers,
so after gathering
dust for some ten years my 1/4" tape machine and Alesis MMT-8 are having
all the fun, and the PC just sits with pidgin, evolution and an ssh
session to my IRC client.
Gordon, there's no shame admitting you make a good use of hardware for
making music. We all did it, honestly. Some of us still do. Hardware
is joy to use.
Linux audio is nowhere. There isn't a usable
sample editor, there are a
"Sample editor" as in "Swami" or "gigedit"? I wouldn't
mind see them
merged, actually.
It's 2011. I've been at this for a decade.
It's just as bad as it was
when I started trying to use PCs for music. I give up.
Giving up is easy. Patching A3 to remove offensive MIDI tracks so that
the sight of the word "MIDI" in few parts of UI doesn't give the
willies is a real task for a real man. Be a man, Gordon, control your
software :)
Alexandre Prokoudine
http://libregraphicsworld.org
23 Feb
23 Feb
11:20 a.m.
On 2/22/11, David Robillard wrote:
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).
Any of them available to have a look at?
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).
Where do you stand with priorities now? That sounds like something
very much worth investing time in.
You see, one thing I'm puzzled about is that you have beginnings of
what could be significant part of a potentially successful cloud
computing audio app, and then you talk about how donations don't even
pay your rent :)
Alexandre Prokoudine
http://libregraphicsworld.org
5:32 p.m.
On Wed, 2011-02-23 at 13:20 +0300, Alexandre Prokoudine wrote:
This is the sort of thing I would like to be working on, right now. It
somewhat works, but Ingen is not yet a powerful enough programming
environment to actually do anything with the message sent to/from Dirg
(other than print them).
First I need to sort out this UI stuff, and get LV2r4 out. Then finalize
the atom extension (i.e. get it used by a few people, replacing the use
of instance-access in the new IR plugin with it would be a good start).
This will solve the long-standing "LV2 RPC" problem needed to take
things to the next level.
Then, the required tech will be more or less sorted out, and I'll get on
with making plugins to do what I need (i.e. make Ingen as powerful as
Max by implementing LV2 plugins as necessary).
My ultimate end-user visible goal for this is to make a multi-track
looper/sequencer in Ingen, with Dirg functioning as the UI.
On 2/22/11, David Robillard wrote:
It's all in my lad svn repository at http://svn.drobilla.net/lad/trunk/
The Atom extension is http://lv2plug.in/ns/ext/atom/
The idea is to use the 'standard' types in the Atom extension (and other
ones as necessary for e.g. waveforms) to build higher level things,
rather than make a different struct for every little thing. Then host
just need to implement serialisation/persistence/network
transparency/etc (all the same thing, essentially) once, and it just
works for everything. "Messages" are essentially dictionaries
(http://lv2plug.in/ns/ext/atom#Blank)
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).
Any of them available to have a look at? 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).
Where do you stand with priorities now? That sounds like something
very much worth investing time in. You see, one thing I'm puzzled about is that you
have beginnings of
what could be significant part of a potentially successful cloud
computing audio app, and then you talk about how donations don't even
pay your rent :)
Tell me about it, but to be fair, it's all still in experimental svn
land. I understand people aren't all that inclined to support things
that aren't releases they can depend on. Hence, making releases is my
primary mission.
Unfortunately, there's always digressions down into technology that I
just want to have, but aren't there yet (i.e. all this LV2 stuff;
somebody has to do it...). C'est la vie. It's coming along...
-dr
10 Feb
10 Feb
6:53 p.m.
On Wed, Feb 9, 2011 at 11:49 AM, David Robillard <d(a)drobilla.net> wrote:
FWIW, I would not do this. The external UI extension
is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...
The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
-dr
(* and it has recently come up that it seems impossible to get certain
window related things right with the current scheme...)
How would I write an LV2 GUI in python?
21 Feb
21 Feb
8:40 p.m.
On Thu, 2011-02-10 at 12:53 -0500, Paul Coccoli wrote:
On Wed, Feb 9, 2011 at 11:49 AM, David Robillard
<d(a)drobilla.net> wrote:
Good question. The UI library itself is a C library. I am not sure how
simple it is to get a C widget pointer for a UI implemented in Python
(this depends on the toolkit you choose to use, of course). The best
way of achieving this depends on that... if it's simple, you'd probably
just implement a teeny wrapper lib in your UI to do so (so the host
wouldn't know the difference). If not, we probably need a new UI type
for this (perhaps one that runs a separate executable, or something like
the current external UI extension).
I will keep this in mind when I get to the aforementioned LV2 UI design
work, thanks for raising the question...
-dr
FWIW, I would not do this. The external UI
extension is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...
The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.
After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.
-dr
(* and it has recently come up that it seems impossible to get certain
window related things right with the current scheme...)
How would I write an LV2 GUI in python? 
11:13 p.m.
On Wed, 2011-02-23 at 20:21 +0000, Chris Cannam wrote:
On 9 February 2011 16:49, David Robillard
<d(a)drobilla.net> wrote:
Entirely Redland free. I hand-wrote a Turtle parser and serialiser.
new librdf-free slv2
Entirely Redland-free, or still using Raptor? And: why?
In short, it's been a PITA for everyone in numerous ways since day one.
Some abandoned SLV2 entirely because of it. Others were in the process
of doing so, until I decided enough was enough. Clearly SLV2 was
deficient somehow if people were abandoning it, and they were abandoning
it explicitly because of Redland...
Redland is great if you really need a fully featured RDF implementation,
and I still use it in such cases. To simply implement LV2, however, you
don't, and such a heavyweight dependency certainly doesn't induce the
best knee-jerk reaction. Often the librdf packages would pull in
ridiculously massive mysql libraries and such - to implement a simple
LADSPA based plugin API?! That this left a bad taste in people's mouths
is completely understandable. It has definitely hurt LV2 adoption.
(Because of historical reasons, "RDF" can seem bloatey, but it's really
just an elegant abstract data model, and we are using a terse and simple
syntax for it. The new lean-and-mean SLV2 implementation shows that
there is no bloat inherent in LV2, and it's all a much easier pill to
swallow in practice).
Some less hand-wavey practical reasons: there were mysterious and very
un-fun problems with librdf-in-librdf that crop up when you have plugins
that load plugins (e.g. Ingen, NASPRO(*)). Portability was also an
issue. Stefano D'Angelo (of NASPRO) and myself are now cooperating on
LV2 implementation rather than duplicating effort because of Redland
related problems (e.g. he'll be helping with win32 portability, and
Ingen now depends on NASPRO for LADSPA support). I am all about
resolving any fragmentation that has happened in the LV2 world, and
dropping Redland has been a big positive step in that regard.
The new implementation is thousands of times smaller, lighter, and
faster. The entire thing is much smaller than libxml2 alone, for
example. I should have just written one like this from the get-go, and
the initial reception of LV2 would have been a lot better. Oh well, live
and learn.
SLV2 is now based on two new libraries: Serd (RDF syntax) and Sord (RDF
store). Both are roughly 2 thousand lines of C, solid and thoroughly
tested (about 95% code coverage, like SLV2 itself). Serd has zero
dependencies, Sord depends only on Glib (for the time being, possibly
not in the future). There is still some optimization to be done, but
it's already so much leaner it's not a huge priority for me.
The new SLV2 should be appropriate for, say, implementing LV2 on
embedded hardware with limited resources. The old one, frankly, smelled
of bloat even on a desktop system.
Unfortunately, this ground-up reimplementation thing consumed the
majority of my January, but I am very happy with the outcome.
-dr
(* For the unfamiliar, NASPRO is a bridge which transparently exposes
LADSPA, VST, etc. plugins as LV2 plugins, among other things)
24 Feb
24 Feb
12:47 p.m.
On Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote:
Entirely Redland free. I hand-wrote a Turtle parser
and serialiser.
In short, it's been a PITA for everyone in numerous ways since day one.
Congratulations. I mean it. This is probably the best move in the entire
history of LV2.
Ciao,
--
FA
2 p.m.
On 02/24/2011 12:47 PM, Fons Adriaensen wrote:
On Wed, Feb 23, 2011 at 05:11:33PM -0500, David
Robillard wrote:
seconded. it used to be quite tricky to chase the correct versions of
redland and its various dependencies, and i recall that at least one
library down dependency hell road would require hefty manual massaging
to even compile, at least on the distros i tried it on.
Entirely Redland free. I hand-wrote a Turtle
parser and serialiser.
In short, it's been a PITA for everyone in numerous ways since day one.
Congratulations. I mean it. This is probably the best move in the entire history
of LV2.
now that's a bit nasty :)
5:57 p.m.
On Thu, 2011-02-24 at 11:47 +0000, Fons Adriaensen wrote:
On Wed, Feb 23, 2011 at 05:11:33PM -0500, David
Robillard wrote:
Cheers :)
I am not a fan of wheel-reinventing; at the time using the existing
implementation seemed like the way to go, but... well, yeah. A burden
has been lifted for sure.
-dr
Entirely Redland free. I hand-wrote a Turtle
parser and serialiser.
In short, it's been a PITA for everyone in numerous ways since day one.
Congratulations. I mean it. This is probably the best move in the entire
history of LV2.
4800
days inactive
4845
days old
linux-audio-dev@lists.linuxaudio.org
160 comments
36 participants
participants (36)
-
Alexandre Prokoudine -
Andres Cabrera -
Arnold Krille -
Chris Cannam -
David Cornette -
David Robillard -
Devin Anderson -
Folderol -
Fons Adriaensen -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Gordon JC Pearce -
Harry Van Haaren -
Jens M Andreasen -
Jeremy Salwen -
Joel Roth -
Jörn Nettingsmeier -
Lorenzo Sutton -
Mark Knecht -
Michael Bechard -
Michael Beer -
michael noble -
Nick Copeland -
Paul Coccoli -
Paul Davis -
Paul Giblock -
Philipp Überbacher -
Ralf Mardorf -
Renato -
Rui Nuno Capela -
Sean Bolton -
Stefano D'Angelo -
Thomas Vecchione -
Thorsten Wilms -
Tom Szilagyi -
torbenh