On Mon, Nov 17, 2003 at 07:48:53PM -0500, Paul Davis wrote:
> >Well, we COULD discuss this with the QT/GTK folk. However, I personally
>
> i already am :)
Excellent. Please keep us appraised :) QT and GTK would take care of the
majority of Linux issues.
>> >All this would be a lot simpler if the common GUI toolkits would provide
>> >a call that would allow one to create a raw X window that wil be
>> >connected to their internals and that gets its raw X events delivered
>> >to a user specified callback. From there on, the toolkit or library used
>>
On Mon, Nov 17, 2003 at 05:39:22PM -0500, Paul Davis wrote:
> >All this would be a lot simpler if the common GUI toolkits would provide
> >a call that would allow one to create a raw X window that wil be
> >connected to their internals and that gets its raw X events delivered
> >to a user specified
>All this would be a lot simpler if the common GUI toolkits would provide
>a call that would allow one to create a raw X window that wil be
>connected to their internals and that gets its raw X events delivered
>to a user specified callback. From there on, the toolkit or library used
>by the plugin
Hi Paul,
> have you considered the possibility that Xlib is not statically
> thread-safe? if there are any globals in the implementation of Xlib,
> this scheme will fail as soon as the host is using Xlib as well.
Yes, and if X does its bookkeeping in terms of 'processes' and not 'clients'
the sam
>It doesn't depend on the host's support in any way. The host doesn't even have
>to be an X client - the same library can be called by for example an internal
>JACK client.
>
>The shared library creates a thread for the X code, connects to the X-server
>as a new client, and provides a set of widget
On Mon, Nov 17, 2003 at 05:46:20PM +0100, Alfons Adriaensen wrote:
> It doesn't depend on the host's support in any way. The host doesn't even have
> to be an X client - the same library can be called by for example an internal
> JACK client.
That sounds like incredibly useful software.
> Plugin
On Mon, Nov 17, 2003 at 04:04:46PM +, Steve Harris wrote:
> I see, but I still dislike the idea FWIW :)
Well if you want the functionality (and I do) I see no other way,
except by doing something that would break the existing API.
> > I have some plugins that are able to create their own G
On Mon, Nov 17, 2003 at 04:57:07PM +0100, Alfons Adriaensen wrote:
> The purpose of my proposition is to enable a plugin writer (if he/she wishes
> to do so) to detect when the plugin is used in this way, and maybe optimise
> his code. For example, control rate computations (which can be elaborate
On Mon, Nov 17, 2003 at 03:36:06PM +, Steve Harris wrote:
> On Mon, Nov 17, 2003 at 04:26:23 +0100, Alfons Adriaensen wrote:
> > This is exactly what AMS is doing in polyphonic mode. Most internal modules
> > (PCM out is the obvious exception) are created as many times as there are
> > voices,
On Mon, Nov 17, 2003 at 04:26:23 +0100, Alfons Adriaensen wrote:
> This is exactly what AMS is doing in polyphonic mode. Most internal modules
> (PCM out is the obvious exception) are created as many times as there are
> voices, but still look like a single module to the user. Plugins can be
> crea
On Mon, Nov 17, 2003 at 03:01:40PM +, Steve Harris wrote:
> > I'd like to propose an extension of the LADSPA specs, or more correctly, a
> > particular interpretation of the current specs, in order to support the use of
> > plugins in a 'polyphonic' context.
> FWIW, I dont think this is the
On Mon, Nov 17, 2003 at 02:14:41 +0100, Alfons Adriaensen wrote:
> I'd like to propose an extension of the LADSPA specs, or more correctly, a
> particular interpretation of the current specs, in order to support the use of
> plugins in a 'polyphonic' context.
FWIW, I dont think this is the correct
Hello LAD,
I'd like to propose an extension of the LADSPA specs, or more correctly, a
particular interpretation of the current specs, in order to support the use of
plugins in a 'polyphonic' context.
The problem to be solved is this:
In a host such as AMS, a plugin can be loaded as part of a po
14 matches
Mail list logo
