On Wed, 2009-11-11 at 22:39 -0800, David Aguilar wrote:
On Nov 11, 2009, at 7:42 AM, David Robillard d...@drobilla.net wrote:
On Wed, 2009-11-11 at 00:18 -0500, Simon Burton wrote:
On Thu, 05 Nov 2009 20:32:47 -0500
David Robillard d...@drobilla.net wrote:
We need a good message/RPC
On Wed, 2009-11-11 at 00:18 -0500, Simon Burton wrote:
On Thu, 05 Nov 2009 20:32:47 -0500
David Robillard d...@drobilla.net wrote:
We need a good message/RPC system, basically, for quite a few things.
Something like OSC but a bit more flexible (or just OSC itself is an
option as
On Nov 11, 2009, at 7:42 AM, David Robillard d...@drobilla.net wrote:
On Wed, 2009-11-11 at 00:18 -0500, Simon Burton wrote:
On Thu, 05 Nov 2009 20:32:47 -0500
David Robillard d...@drobilla.net wrote:
We need a good message/RPC system, basically, for quite a few
things.
Something like
On Thu, 05 Nov 2009 20:32:47 -0500
David Robillard d...@drobilla.net wrote:
We need a good message/RPC system, basically, for quite a few things.
Something like OSC but a bit more flexible (or just OSC itself is an
option as well).
dbus ?
___
On Sun, Nov 8, 2009 at 6:41 AM, Jeff McClintock j...@synthedit.com wrote:
GMPI is quietly and successfully in use as the new native plugin format of
SynthEdit.
Interesting. Can you link to an API reference or the like?
Chris
___
Linux-audio-dev
Here is what should be (IMO) with current extension list (as i know it):
Gabriel M. Beddingfield gabr...@teuton.org writes:
FOR SYNTH HOSTS:
If you follow these guidelines, you may call yourself an LV2 Synth Host
and you will be able to work cleanly with every synth that
On Sun, 8 Nov 2009, Nedko Arnaudov wrote:
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.
I don't get why such restriction is needed.
So that the host application can lay out the plugin
On Sun, Nov 8, 2009 at 7:35 AM, Gabriel M. Beddingfield
gabr...@teuton.org wrote:
I (personally) really don't like having plugin windows flying all over the
place. I think they should be layed out in the host application. (And I
also think they should be widget-toolkit agnostic --
On Sun, 8 Nov 2009, Paul Davis wrote:
I (personally) really don't like having plugin windows flying all over the
place. I think they should be layed out in the host application. (And I
also think they should be widget-toolkit agnostic --
Qt/GTK/FLTK/whatever.)
when you come up with a way
2009/11/8 Jeff McClintock j...@synthedit.com:
insert obligatory GMPI joke here
-dr
GMPI is quietly and successfully in use as the new native plugin format of
SynthEdit. I've so far written 70 plugins with it, and others are writing
more. SynthEdit's previous plugin format has about 1000
On Sun, Nov 8, 2009 at 7:50 AM, Emanuel Rumpf xb...@web.de wrote:
2009/11/8 Jeff McClintock j...@synthedit.com:
FLOSS poeple - let's rather ignore GMPI as long as we can.
I don't recall you being involved in the GMPI process. I was, and so
was Jeff (and others include Steve Harris).
The final
2009/11/8 Paul Davis p...@linuxaudiosystems.com:
On Sun, Nov 8, 2009 at 7:50 AM, Emanuel Rumpf xb...@web.de wrote:
2009/11/8 Jeff McClintock j...@synthedit.com:
FLOSS poeple - let's rather ignore GMPI as long as we can.
I don't recall you being involved in the GMPI process. I was, and so
On Sun, 8 Nov 2009, Paul Davis wrote:
when you come up with a way to do that, please do let us know. this
has been on the table for at least 8 years and no acceptable solutions
have ever emerged. they either offer too little control to the plugin
developer, or simply cannot integrate with
On Sun, Nov 8, 2009 at 9:30 AM, Gabriel M. Beddingfield
gabr...@teuton.org wrote:
On Sun, 8 Nov 2009, Paul Davis wrote:
when you come up with a way to do that, please do let us know. this
has been on the table for at least 8 years and no acceptable solutions
have ever emerged. they either
On Sat, 2009-11-07 at 15:37 -0600, Gabriel M. Beddingfield wrote:
Looking at this, people say, This is good, but it's kind of a mess at the
moment. Can we get some sort of 'canonical list of extensions' or
/something/ stable for devs to work from? To which Dave replies, FUD!
FUD! FUD!
On Sat, 2009-11-07 at 23:09 +0100, f...@kokkinizita.net wrote:
On Sat, Nov 07, 2009 at 12:52:52PM -0500, David Robillard wrote:
This wouldn't be an LV2 plugin at all.
In spirit, no. But technically it would be a
perfectly conforming plugin.
Huh? An LV2 plugin in the code sense is a
On Sun, 2009-11-08 at 13:55 +1100, Patrick Shirkey wrote:
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?
Small examples would be great.
We need a more transparent way of referencing an extension/plugin by to
it's
On Sat, 2009-11-07 at 22:31 -0600, Gabriel M. Beddingfield wrote:
On Sun, 8 Nov 2009, Patrick Shirkey wrote:
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?
I don't think so. ATM, there's plenty of high-quality
On Sun, 2009-11-08 at 14:00 +0200, Nedko Arnaudov wrote:
Here is what should be (IMO) with current extension list (as i know it):
Gabriel M. Beddingfield gabr...@teuton.org writes:
+ Support (at least) extensions A, B, and C.
* the MIDI event extension
* the Event port extension
*
On Sun, 2009-11-08 at 06:35 -0600, Gabriel M. Beddingfield wrote:
On Sun, 8 Nov 2009, Nedko Arnaudov wrote:
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.
I don't get why such
On Sun, 2009-11-08 at 07:40 -0500, Paul Davis wrote:
On Sun, Nov 8, 2009 at 7:35 AM, Gabriel M. Beddingfield
gabr...@teuton.org wrote:
I (personally) really don't like having plugin windows flying all over the
place. I think they should be layed out in the host application. (And I
also
On Sun, 2009-11-08 at 08:30 -0600, Gabriel M. Beddingfield wrote:
On Sun, 8 Nov 2009, Paul Davis wrote:
when you come up with a way to do that, please do let us know. this
has been on the table for at least 8 years and no acceptable solutions
have ever emerged. they either offer too
On Sun, Nov 8, 2009 at 4:09 PM, David Robillard d...@drobilla.net wrote:
Qt can now use the glib main loop.
Not just can, it does by default since Qt 4.4. I think the
intention was exactly to allow cross-toolkit plugins. So it's quite
likely there is a way to make this work, though obviously
On Sun, 8 Nov 2009, David Robillard wrote:
+ The synths will have several MIDI input ports (for note data)
and several audio output ports.
Several? Why?
Several as in a non-negative integer. I.e. the host should be prepared
for a synth that has 1, 2, 3, 4, or even 0 ports.
On Sun, 8 Nov 2009, David Robillard wrote:
This is a good motivation, but pixel widths are the devil and should be
avoided whenever possible.
I agree. Can you suggest another metric?
-gabriel
___
Linux-audio-dev mailing list
On Sun, Nov 08, 2009 at 10:45:50AM -0500, David Robillard wrote:
On Sat, 2009-11-07 at 23:09 +0100, f...@kokkinizita.net wrote:
On Sat, Nov 07, 2009 at 12:52:52PM -0500, David Robillard wrote:
This wouldn't be an LV2 plugin at all.
In spirit, no. But technically it would be a
Thanks Nedko
On Sun, 8 Nov 2009, Nedko Arnaudov wrote:
+ Support (at least) extensions A, B, and C.
* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension
What about the dynparam extension? That seems appropriate to require from
On Sun, 2009-11-08 at 11:30 -0600, Gabriel M. Beddingfield wrote:
Hi Patrick,
On Sun, 8 Nov 2009, Patrick Shirkey wrote:
On Sun, 8 Nov 2009, Patrick Shirkey wrote:
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?
On Sun, 2009-11-08 at 17:46 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 4:09 PM, David Robillard d...@drobilla.net wrote:
Qt can now use the glib main loop.
Not just can, it does by default since Qt 4.4. I think the
intention was exactly to allow cross-toolkit plugins. So it's quite
On Sun, 2009-11-08 at 11:58 -0600, Gabriel M. Beddingfield wrote:
On Sun, 8 Nov 2009, David Robillard wrote:
This is a good motivation, but pixel widths are the devil and should be
avoided whenever possible.
I agree. Can you suggest another metric?
Decent UIs are sized based on text
On Sun, 2009-11-08 at 19:13 +0100, f...@kokkinizita.net wrote:
On Sun, Nov 08, 2009 at 10:45:50AM -0500, David Robillard wrote:
On Sat, 2009-11-07 at 23:09 +0100, f...@kokkinizita.net wrote:
On Sat, Nov 07, 2009 at 12:52:52PM -0500, David Robillard wrote:
This wouldn't be an LV2
On Sun, 2009-11-08 at 12:44 -0600, Gabriel M. Beddingfield wrote:
Thanks Nedko
On Sun, 8 Nov 2009, Nedko Arnaudov wrote:
+ Support (at least) extensions A, B, and C.
* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension
On Sun, Nov 8, 2009 at 6:59 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 17:46 +, Chris Cannam wrote:
likely there is a way to make this work
Yay
, though obviously not with the
existing GTK UI extension.
Why not?
Because it passes a GTK window, doesn't it?
Gabriel M. Beddingfield gabr...@teuton.org writes:
Thanks Nedko
On Sun, 8 Nov 2009, Nedko Arnaudov wrote:
+ Support (at least) extensions A, B, and C.
* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension
What about the
Chris Cannam can...@all-day-breakfast.com writes:
On Sun, Nov 8, 2009 at 6:59 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 17:46 +, Chris Cannam wrote:
likely there is a way to make this work
Yay
, though obviously not with the
existing GTK UI extension.
Why
On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
Chris Cannam can...@all-day-breakfast.com writes:
Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.
It passes GTK *widget*.
Right, OK, same thing though from this
On Sun, 2009-11-08 at 21:17 +0200, Nedko Arnaudov wrote:
Gabriel M. Beddingfield gabr...@teuton.org writes:
Thanks Nedko
On Sun, 8 Nov 2009, Nedko Arnaudov wrote:
+ Support (at least) extensions A, B, and C.
* the MIDI event extension
* the Event port extension
* the URI
David Robillard d...@drobilla.net writes:
Easy documentation about which hosts support what is indeed useful, but
you can't come up with a consensus about what hosts should support.
They should support everything ;)
It's what they DO support that matters. There's been far, far, far too
On Sun, 2009-11-08 at 19:19 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
Chris Cannam can...@all-day-breakfast.com writes:
Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.
It
On Sun, Nov 8, 2009 at 7:25 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 19:19 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
Chris Cannam can...@all-day-breakfast.com writes:
Because it passes a GTK window, doesn't
On 7 Nov 2009, at 20:15, Chris Cannam wrote:
2009/11/7 Jörn Nettingsmeier netti...@folkwang-hochschule.de:
This was a hangover from LADSPA, which had confusing and
contradictory
claims about what should/shouldn't be used to identify ports.
I still don't think there's consensus there.
On Sun, Nov 8, 2009 at 7:43 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
Uh, with an X window or whatever. [...]
Again, to be sure this is clear, there is no Gtk UI extension. The UI
extension can return a UI of any type (as a void pointer), Gtk just
happens to be one of them.
But
On Sun, 2009-11-08 at 14:39 -0500, David Robillard wrote:
New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be automatically generated as well (and in a much more
useful form than a
On Sun, 2009-11-08 at 19:43 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 7:25 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 19:19 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
Chris Cannam
On Sun, Nov 8, 2009 at 7:24 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
IMHO, the two basic questions that user will have are:
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?
Hm, I think you
On Sun, 2009-11-08 at 21:46 +0200, Nedko Arnaudov wrote:
David Robillard d...@drobilla.net writes:
New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be automatically generated
On Sun, 2009-11-08 at 21:13 +0100, Thorsten Wilms wrote:
On Sun, 2009-11-08 at 14:39 -0500, David Robillard wrote:
New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be
On Sun, 2009-11-08 at 20:23 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 7:24 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
IMHO, the two basic questions that user will have are:
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a
On Sun, Nov 8, 2009 at 8:28 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 20:23 +, Chris Cannam wrote:
Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why doesn't this plugin work?
This is a problem that hosts (can,
On Sun, Nov 8, 2009 at 3:36 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
On Sun, Nov 8, 2009 at 8:28 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 20:23 +, Chris Cannam wrote:
Hm, I think you may have the wrong tense. I think the one basic
question that users
On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis p...@linuxaudiosystems.com wrote:
[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.
That kind of PITA? :)
That kind of PITA, for every new plugin
On Sun, Nov 8, 2009 at 8:53 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis p...@linuxaudiosystems.com wrote:
[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
On Sun, 8 Nov 2009 20:53:40 +
Chris Cannam can...@all-day-breakfast.com wrote:
On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis
p...@linuxaudiosystems.com wrote:
[X] This plugin was discovered but can't be used without hacking
this host and recompiling because its uses an extension that
On Sun, 2009-11-08 at 20:36 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 8:28 PM, David Robillard d...@drobilla.net wrote:
On Sun, 2009-11-08 at 20:23 +, Chris Cannam wrote:
Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why
On Sun, 2009-11-08 at 20:53 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis p...@linuxaudiosystems.com wrote:
[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.
On Sun, 2009-11-08 at 20:59 +, Chris Cannam wrote:
On Sun, Nov 8, 2009 at 8:53 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis p...@linuxaudiosystems.com
wrote:
[X] This plugin was discovered but can't be used without hacking this
On Sun, 8 Nov 2009, David Robillard wrote:
pretty good idea. All that is needed as far as maintenance goes is for
hosts to supply a simple turtle document that says I implement foo and
bar and baz extensions. The rest can be compiled into whatever fancy
human readable form you want, for
On 11/09/2009 06:39 AM, David Robillard wrote:
New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be automatically generated as well (and in a much more
useful form than a human
On Sun, 8 Nov 2009, Gabriel M. Beddingfield wrote:
I would vote for XML for this, to better utilize all the parsers,
Erm... nevermind. You've already finished it. :-)
-gabriel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
On Sun, 8 Nov 2009, David Robillard wrote:
If you want to start such a thing, it's a wiki for a reason ;) It's
much easier to revise there than on the list.
So how does one get an account for the wiki?[1] I clicked the log in /
create account link[2] -- but there was no option to create an
Steve Harris wrote:
On 5 Nov 2009, at 23:33, David Robillard wrote:
On Thu, 2009-11-05 at 22:21 +0100, f...@kokkinizita.net wrote:
On the LV2 website, Lars Luthman's UI extension is described as:
This extension is written for revision 2 of the LV2 specification
and is NOT compatible with
On Fri, 2009-11-06 at 18:27 +0100, f...@kokkinizita.net wrote:
On Fri, Nov 06, 2009 at 10:55:17AM -0500, David Robillard wrote:
How could changing the rules about how anything references ports be done
as an extension?
By doing it the new way if the extension is requested,
and the old
On Sat, 2009-11-07 at 13:41 +0100, Jörn Nettingsmeier wrote:
Steve Harris wrote:
On 5 Nov 2009, at 23:33, David Robillard wrote:
On Thu, 2009-11-05 at 22:21 +0100, f...@kokkinizita.net wrote:
On the LV2 website, Lars Luthman's UI extension is described as:
This extension is written
2009/11/7 Jörn Nettingsmeier netti...@folkwang-hochschule.de:
This was a hangover from LADSPA, which had confusing and contradictory
claims about what should/shouldn't be used to identify ports.
I still don't think there's consensus there.
can you elaborate on this?
archive links would be
On Sat, 7 Nov 2009, David Robillard wrote:
A better analogy would be well-formed XML or RDF, where things can
easily be added but it doesn't break anything because the technology has
been designed specifically to handle this; or my shared library analogy
from earlier.
rant
Except when you
On Sat, Nov 07, 2009 at 12:52:52PM -0500, David Robillard wrote:
This wouldn't be an LV2 plugin at all.
In spirit, no. But technically it would be a
perfectly conforming plugin.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
On 11/08/2009 08:37 AM, Gabriel M. Beddingfield wrote:
On Sat, 7 Nov 2009, David Robillard wrote:
A better analogy would be well-formed XML or RDF, where things can
easily be added but it doesn't break anything because the technology has
been designed specifically to handle this; or my
On Sun, 8 Nov 2009, Patrick Shirkey wrote:
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?
I don't think so. ATM, there's plenty of high-quality reference code...
especially with Lars's tutorial. This is a different
On 11/08/2009 03:31 PM, Gabriel M. Beddingfield wrote:
On Sun, 8 Nov 2009, Patrick Shirkey wrote:
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?
I don't think so. ATM, there's plenty of high-quality reference
insert obligatory GMPI joke here
-dr
GMPI is quietly and successfully in use as the new native plugin format of
SynthEdit. I've so far written 70 plugins with it, and others are writing
more. SynthEdit's previous plugin format has about 1000 plugins available,
hopefully also will be ported to
On Thu, Nov 05, 2009 at 01:18:53PM +1100, Patrick Shirkey wrote:
On 11/05/2009 08:48 AM, Gordon JC Pearce wrote:
Implement it as a DSSI. It's much easier and cleaner than LV2, and you
don't need to link to complicated, fragile and bloated RDF libraries.
LV2 is a good intellectual
On Thu, 2009-11-05 at 22:21 +0100, f...@kokkinizita.net wrote:
On Thu, Nov 05, 2009 at 01:18:53PM +1100, Patrick Shirkey wrote:
On 11/05/2009 08:48 AM, Gordon JC Pearce wrote:
Implement it as a DSSI. It's much easier and cleaner than LV2, and you
don't need to link to complicated,
On Thu, 2009-11-05 at 22:21 +0100, f...@kokkinizita.net wrote:
On the LV2 website, Lars Luthman's UI extension is described as:
This extension is written for revision 2 of the LV2 specification
and is NOT compatible with revisions 3 and later. Do not implement
this extension in new plugins
I suppose it could. Though why is far beyond me... what's your point?
Such an extension would effectively embed a completely new
plugin standard into LV2, leaving only the plugin discovery
and packaging mechanism.
... and?
Supporting it would be no more complex than supporting e.g.
On Fri, 2009-11-06 at 12:26 +1100, Loki Davison wrote:
As a gedankenexperiment what are the problems in LV2 that make it
ineffective or even inelegant for implementing something like Jconv
i.e a wrapper on your very lovely zita-convolver? How should these be
solved?
The main thing lacking for
On Thu, 2009-10-15 at 23:59 +0200, Ulrich Lorenz Schlüter wrote:
Hi list,
as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.
Thanks
Uli
Implement it as a DSSI. It's much easier and cleaner than LV2, and you
don't need to link to complicated, fragile and bloated
Hi,
take a look at the invada studio LV2 plugin source code.
http://www.invadarecords.com/Downloads.php?ID=0264
J.
--- On Thu, 10/15/09, Ulrich Lorenz Schlüter audio-mobs...@gmx.de wrote:
From: Ulrich Lorenz Schlüter audio-mobs...@gmx.de
Subject: [LAD] How to develop guis for LV2
Hi list,
as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.
Thanks
Uli
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
78 matches
Mail list logo
