(split from: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb)
On 02/26/2011 11:35 PM, David Robillard wrote:
> At this very instant, on a particular device, browser might not be up to
> snuff.
>
> Personally I'm more interested in better long-term investments, and the
> browser is only g
2011/2/28 Olivier Guilyardi :
I just dropped explicit LADSPA support from Ingen in favour of NASPRO.
IMO, if the bridge is inadequate, then the bridge should be fixed, so
I'm investing in NASPRO, so to speak, so hopefully it remains a vibrant
project :)
>>> I am really glad to r
On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
> (split from: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb)
>
> On 02/26/2011 11:35 PM, David Robillard wrote:
>
> > At this very instant, on a particular device, browser might not be up to
> > snuff.
> >
> > Personally I'm
On Mon, 2011-02-28 at 22:37 +0100, Stefano D'Angelo wrote:
[...]
> Unfortunately the LRDF part won't be there due to a complete rewrite,
> and support for that thing will be delayed to some later release (but
> not too much) since I want to avoid librdf. In this regard, I wanted
> to use libxml2 di
2011/3/1 David Robillard :
> On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
>> (split from: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb)
>>
>> On 02/26/2011 11:35 PM, David Robillard wrote:
>>
>> > At this very instant, on a particular device, browser might not be up to
>>
On Tue, 2011-03-01 at 14:13 +0100, Stefano D'Angelo wrote:
> 2011/3/1 David Robillard :
> > On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
[...]
> >> Also, I don't see what's so easy with browsers. I've done web development
> >> for
> >> years, and compatibility problems are the rule.
On 02/28/2011 10:37 PM, Stefano D'Angelo wrote:
> The current NASPRO bridge from LADSPA to LV2 does not depend on LRDF
> files, yet it uses them if found to provide extra metadata. After all,
> that's what they are for.
Sounds good. AFAIK, the LRDF files are especially useful for enumerations. I'
2011/3/1 Olivier Guilyardi :
> On 02/28/2011 10:37 PM, Stefano D'Angelo wrote:
>> However, that part currently depends on librdf, and I've been so lazy
>> not to provide ways to build the bridge without it. However it should
>> be easy to modify. But since the new bridges are in the making and top
2011/3/1 Stefano D'Angelo :
> 2011/3/1 Olivier Guilyardi :
>> On 02/28/2011 10:37 PM, Stefano D'Angelo wrote:
>>> However, that part currently depends on librdf, and I've been so lazy
>>> not to provide ways to build the bridge without it. However it should
>>> be easy to modify. But since the new
On 03/01/2011 12:58 AM, David Robillard wrote:
> On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
>> Actually, on current mobile platforms, when one wants a portable UI, there
>> is an
>> alternative to Web UIs: OpenGL. This runs everywhere, and as smoothly as can
>> be.
>> All you ne
On Tue, 2011-03-01 at 19:01 +0100, Stefano D'Angelo wrote:
> 2011/3/1 Stefano D'Angelo :
> > 2011/3/1 Olivier Guilyardi :
> >> On 02/28/2011 10:37 PM, Stefano D'Angelo wrote:
> >>> However, that part currently depends on librdf, and I've been so lazy
> >>> not to provide ways to build the bridge wi
On Tue, 2011-03-01 at 19:36 +0100, Olivier Guilyardi wrote:
> On 03/01/2011 12:58 AM, David Robillard wrote:
> > On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
>
> >> Actually, on current mobile platforms, when one wants a portable UI, there
> >> is an
> >> alternative to Web UIs: Op
On 03/02/2011 12:22 AM, David Robillard wrote:
> On Tue, 2011-03-01 at 19:36 +0100, Olivier Guilyardi wrote:
>> Hmm, what platform specific native code? In my idea, the host would handle
>> setting up the GL viewport and such.
>
> ... "the host would " ;)
No, not really.
Apart from mobile web
On Wed, Mar 2, 2011 at 8:20 AM, Olivier Guilyardi wrote:
> On 03/02/2011 12:22 AM, David Robillard wrote:
>
>> On Tue, 2011-03-01 at 19:36 +0100, Olivier Guilyardi wrote:
>
>>> Hmm, what platform specific native code? In my idea, the host would handle
>>> setting up the GL viewport and such.
>>
>>
On 03/02/2011 02:27 PM, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 8:20 AM, Olivier Guilyardi wrote:
>> With this method, notably used by game devs, there's one code base, with thin
>> platform drivers.
>
> i should comment here: although this is the *theory* behind game
> development, its very
2011/3/2 Olivier Guilyardi :
> On 03/02/2011 02:27 PM, Paul Davis wrote:
>
>> On Wed, Mar 2, 2011 at 8:20 AM, Olivier Guilyardi wrote:
>
>>> With this method, notably used by game devs, there's one code base, with
>>> thin
>>> platform drivers.
>>
>> i should comment here: although this is the *t
On 03/02/2011 03:30 PM, Stefano D'Angelo wrote:
> Let's try to make everybody (un)happy:
> http://blogs.sonyericsson.com/developerworld/2011/02/24/webgl-support-in-the-android-web-browser/
Pretty amazing.
> However, as I see it now, this is a possible list of GUI techonologies
> that may be wort
On Wed, 2011-03-02 at 16:58 +0100, Olivier Guilyardi wrote:
> On 03/02/2011 03:30 PM, Stefano D'Angelo wrote:
>
> > Let's try to make everybody (un)happy:
> > http://blogs.sonyericsson.com/developerworld/2011/02/24/webgl-support-in-the-android-web-browser/
>
> Pretty amazing.
>
> > However, as I
On Wed, 2011-03-02 at 15:30 +0100, Stefano D'Angelo wrote:
[...]
> Let's try to make everybody (un)happy:
> http://blogs.sonyericsson.com/developerworld/2011/02/24/webgl-support-in-the-android-web-browser/
>
> However, as I see it now, this is a possible list of GUI techonologies
> that may be wor
On 03/02/2011 05:56 PM, David Robillard wrote:
> On Wed, 2011-03-02 at 15:30 +0100, Stefano D'Angelo wrote:
> [...]
>> Let's try to make everybody (un)happy:
>> http://blogs.sonyericsson.com/developerworld/2011/02/24/webgl-support-in-the-android-web-browser/
>>
>> However, as I see it now, this is
On Wed, Mar 2, 2011 at 12:25 PM, Olivier Guilyardi wrote:
>
>
>
>
>
> ...
>
from the depths of time:
http://lalists.stanford.edu/lad/2000/Nov/0344.html
it basically turned out to be useless. the host can put together a
pretty good GUI by itself. it could do an almost perfect job w
On Wed, 2011-03-02 at 14:20 +0100, Olivier Guilyardi wrote:
> On 03/02/2011 12:22 AM, David Robillard wrote:
>
> > On Tue, 2011-03-01 at 19:36 +0100, Olivier Guilyardi wrote:
>
> >> Hmm, what platform specific native code? In my idea, the host would handle
> >> setting up the GL viewport and such
On Wed, 2011-03-02 at 12:29 -0500, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 12:25 PM, Olivier Guilyardi wrote:
>
> >
> >
> >
> >
> >
> > ...
> >
>
> from the depths of time:
>
> http://lalists.stanford.edu/lad/2000/Nov/0344.html
>
> it basically turned out to be useless. the hos
On 03/02/2011 06:32 PM, David Robillard wrote:
> Why you are trying to pick apart web UIs in the same email as you're
> arguing where one size does not fit all I don't know... I want a remote
> control that works on any device out of the box. It's about as blatantly
> obvious as anything can be th
(resending this since my previous mail with attachments didn't go through)
On 03/02/2011 06:29 PM, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 12:25 PM, Olivier Guilyardi wrote:
>
>>
>>
>>
>>
>>
>> ...
>>
>
> from the depths of time:
>
> http://lalists.stanford.edu/lad/2000/Nov/034
On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote:
> On 03/02/2011 06:32 PM, David Robillard wrote:
>
> > Why you are trying to pick apart web UIs in the same email as you're
> > arguing where one size does not fit all I don't know... I want a remote
> > control that works on any device o
2011/3/2 David Robillard :
> On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote:
>> On 03/02/2011 06:32 PM, David Robillard wrote:
>>
>> > Why you are trying to pick apart web UIs in the same email as you're
>> > arguing where one size does not fit all I don't know... I want a remote
>> > c
On Wed, Mar 2, 2011 at 2:55 PM, Stefano D'Angelo wrote:
> Plugins expose "control ports" (which, to me, are a design mistake how
> they're done, but whatever) for the purpose of managing how they work.
no different than any other plugin API, except that the concept is a
bit more unified than "da
On 2 Mar 2011 20:08, "Paul Davis" wrote:
> AU, which is the only other plugin API to explicitly support
> plugin<->GUI separation
*cough*
Still, with DSSI we apparently failed to persuade anyone (including Paul?)
that it was a good thing. I hope there's a better plan for LV2.
Chris
On Wed, Mar 2, 2011 at 3:44 PM, Chris Cannam
wrote:
>
> On 2 Mar 2011 20:08, "Paul Davis" wrote:
>> AU, which is the only other plugin API to explicitly support
>> plugin<->GUI separation
>
> *cough*
sorry. "AU, which the only other plugin API to ..." :)
> Still, with DSSI we apparently failed
On 03/02/2011 08:55 PM, Stefano D'Angelo wrote:
> What I don't really get is why you would ever want visualization,
> since that is more related to sound analysis, that LV2, as of now,
> doesn't really support (yes, you can do whatever you want, but don't
> tell me about spectrograms... that stuff
On Wed, 2011-03-02 at 20:55 +0100, Stefano D'Angelo wrote:
> 2011/3/2 David Robillard :
> > On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote:
> >> On 03/02/2011 06:32 PM, David Robillard wrote:
> >>
> >> > Why you are trying to pick apart web UIs in the same email as you're
> >> > arguing
On Wed, 2011-03-02 at 15:08 -0500, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 2:55 PM, Stefano D'Angelo wrote:
>
> > Plugins expose "control ports" (which, to me, are a design mistake how
> > they're done, but whatever) for the purpose of managing how they work.
>
> no different than any other p
On Wed, 2011-03-02 at 22:15 +0100, Olivier Guilyardi wrote:
> On 03/02/2011 08:55 PM, Stefano D'Angelo wrote:
> > What I don't really get is why you would ever want visualization,
> > since that is more related to sound analysis, that LV2, as of now,
> > doesn't really support (yes, you can do what
Personally, I like the idea of plugin interfaces having some form of
visualization. The compressor example is obvious. So is the graphical
equalizer. I can imagine other cases as well: waveform of a sampler.
Perhaps a synth that let's the user scribble their own waveform. There are
all sorts of t
2011/3/2 Paul Davis :
> On Wed, Mar 2, 2011 at 2:55 PM, Stefano D'Angelo wrote:
>
>> Plugins expose "control ports" (which, to me, are a design mistake how
>> they're done, but whatever) for the purpose of managing how they work.
>
> no different than any other plugin API, except that the concept
2011/3/2 Olivier Guilyardi :
> On 03/02/2011 08:55 PM, Stefano D'Angelo wrote:
>> What I don't really get is why you would ever want visualization,
>> since that is more related to sound analysis, that LV2, as of now,
>> doesn't really support (yes, you can do whatever you want, but don't
>> tell m
2011/3/2 David Robillard :
> On Wed, 2011-03-02 at 20:55 +0100, Stefano D'Angelo wrote:
>> 2011/3/2 David Robillard :
>> > On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote:
>> >> On 03/02/2011 06:32 PM, David Robillard wrote:
>> >>
>> >> > Why you are trying to pick apart web UIs in the s
2011/3/2 David Robillard :
> On Wed, 2011-03-02 at 22:15 +0100, Olivier Guilyardi wrote:
>> On 03/02/2011 08:55 PM, Stefano D'Angelo wrote:
>> > What I don't really get is why you would ever want visualization,
>> > since that is more related to sound analysis, that LV2, as of now,
>> > doesn't rea
2011/3/2 Paul Giblock :
> Personally, I like the idea of plugin interfaces having some form of
> visualization. The compressor example is obvious. So is the graphical
> equalizer. I can imagine other cases as well: waveform of a sampler.
> Perhaps a synth that let's the user scribble their own wav
On Wed, Mar 02, 2011 at 04:58:39PM -0500, David Robillard wrote:
> > Another example is a visual EQ as the one found in Jamin, where you both
> > see the
> > live spectrum and can adjust frequency bands level.
>
> Yawn. Personally I've always considered my ears better judges of audio
> than pixe
On Wed, Mar 2, 2011 at 5:36 PM, Stefano D'Angelo wrote:
> Since I'm not just complaining or posing hypotetical questions, but
> want the understand the issue at its deepest, I want to ask you to
> please better point out what is exactly this host-mediate parameter
> accessor API (a link to docs is
I suppose I don't mean to attack lv2. It is a good extensible format, and is
the product of much dedication, especially on Dave's part. I could write my
own extension and be done with it. But then we end up with a situation like
the external UI is today.
My concern is if we would ever have a stand
On Wed, 2 Mar 2011, Paul Giblock wrote:
My concern is if we would ever have a standard extension for this kind of
thing when the primary maintainer considers the idea stupid, dumb, or
broken.
Yes.
That's the whole point of the "extensions" thing. You do
not need the blessing of Drobilla o
On 03/02/2011 10:58 PM, David Robillard wrote:
> Yawn. Personally I've always considered my ears better judges of audio
> than pixellated waveforms on a screen.
>
> Knobs and speakers were good enough for some of the most brilliant sonic
> artists ever, and they're plenty good enough for me too.
2011/3/2 Paul Davis :
> On Wed, Mar 2, 2011 at 5:36 PM, Stefano D'Angelo wrote:
>> Since I'm not just complaining or posing hypotetical questions, but
>> want the understand the issue at its deepest, I want to ask you to
>> please better point out what is exactly this host-mediate parameter
>> acc
On Wed, Mar 2, 2011 at 6:14 PM, Olivier Guilyardi wrote:
> Ears are not separated from the body. Not only am I interested into the
> convergence of audio and graphics but also touch. This basically is what my
> Android app is about. Aside of that I've worked with a painter on an artistic
> project
2011/3/2 Fons Adriaensen :
> On Wed, Mar 02, 2011 at 04:58:39PM -0500, David Robillard wrote:
>
>> > Another example is a visual EQ as the one found in Jamin, where you both
>> > see the
>> > live spectrum and can adjust frequency bands level.
>>
>> Yawn. Personally I've always considered my ears
2011/3/3 Paul Giblock :
> My concern is if we would ever have a standard extension for this kind of
> thing when the primary maintainer considers the idea stupid, dumb, or
> broken.
Yet I can guarantee the maintainer in question is not stupid, dumb or
broken, and after possibly a long discussion i
On Thu, Mar 03, 2011 at 12:17:40AM +0100, Stefano D'Angelo wrote:
> Does point #1 mean we basically may want visualization that expresses
> only a few properties of a certain waveform?
Yes. Waveforms displays are completely useless for normal
audio engineering. You may need them for technical pur
On Wed, 2011-03-02 at 23:36 +0100, Stefano D'Angelo wrote:
> 2011/3/2 Paul Davis :
[...]
> > AU, which is the only other plugin API to explicitly support
> > plugin<->GUI separation (even across processes) works in exactly the
> > same way as LV2. there are many AU plugins which do precisely what y
On Wed, 2011-03-02 at 18:02 -0500, Paul Giblock wrote:
> I suppose I don't mean to attack lv2. It is a good extensible format,
> and is the product of much dedication, especially on Dave's part. I
> could write my own extension and be done with it. But then we end up
> with a situation like the ex
On Wed, 2011-03-02 at 22:49 +, Fons Adriaensen wrote:
> On Wed, Mar 02, 2011 at 04:58:39PM -0500, David Robillard wrote:
>
> > > Another example is a visual EQ as the one found in Jamin, where you both
> > > see the
> > > live spectrum and can adjust frequency bands level.
> >
> > Yawn. Pers
On Wed, Mar 02, 2011 at 07:37:37PM -0500, David Robillard wrote:
> Bang on. /This/ is the kind of UI stuff that actually matters.
>
> If you gave someone actually interested in making music or doing pro
> audio (or...) a choice between:
I guess the situation could be somewhat different for an a
On Wed, Mar 2, 2011 at 8:32 PM, Jeff McClintock wrote:
>> AU, which is the only other plugin API to explicitly support
>> plugin<->GUI separation.
>
> AND VST 3.0, AND GMPI/SynthEdit...
VST3 allows the GUI to run in a different process?
> The host needs to see every parameter tweak. It needs to
> AU, which is the only other plugin API to explicitly support
> plugin<->GUI separation.
AND VST 3.0, AND GMPI/SynthEdit...
The host needs to see every parameter tweak. It needs to be between the GUI
and the DSP to arbitrate clashes between conflicting control surfaces. It's
the only way to do a
On Wed, 2011-03-02 at 20:36 -0500, Paul Davis wrote:
[...]
> well, almost. as i mentioned, AU doesn't really route parameter
> changes via the host, it just makes sure that the host can find out
> about them. the nicest part of the AU system is the highly
> configurable listener system, which can b
On Wed, Mar 2, 2011 at 8:54 PM, David Robillard wrote:
> On Wed, 2011-03-02 at 20:36 -0500, Paul Davis wrote:
> [...]
>> well, almost. as i mentioned, AU doesn't really route parameter
>> changes via the host, it just makes sure that the host can find out
>> about them. the nicest part of the AU s
On Wednesday, March 02, 2011 09:15:32 pm Fons Adriaensen did opine:
> On Thu, Mar 03, 2011 at 12:17:40AM +0100, Stefano D'Angelo wrote:
> > Does point #1 mean we basically may want visualization that expresses
> > only a few properties of a certain waveform?
>
> Yes. Waveforms displays are comple
On Wed, 2011-03-02 at 21:10 -0500, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 8:54 PM, David Robillard wrote:
> > On Wed, 2011-03-02 at 20:36 -0500, Paul Davis wrote:
> > [...]
> >> well, almost. as i mentioned, AU doesn't really route parameter
> >> changes via the host, it just makes sure that t
On 03/03/2011 01:25 AM, David Robillard wrote:
> Anyway, I'd actively like to see GL UIs, since I have a host that's a
> modular canvas and you could do some pretty awesome things there - but
> that doesn't mean I think high performance waveforms and visualizations
> and whatever is important, or
On 03/02/2011 11:49 PM, Fons Adriaensen wrote:
>
> Here (for once) we do agree :-) There's probably no worse way
> to show what a compressor is doing than showing the input and
> output waveforms. A simple bargraph showing the current gain
> - or better, the gain range over a short period - will d
On Wed, Mar 02, 2011 at 09:33:43PM -0500, gene heskett wrote:
> On Wednesday, March 02, 2011 09:15:32 pm Fons Adriaensen did opine:
>
> > On Thu, Mar 03, 2011 at 12:17:40AM +0100, Stefano D'Angelo wrote:
> > > Does point #1 mean we basically may want visualization that expresses
> > > only a few
> From: Paul Davis
> Subject: Re: [LAD] Portable user interfaces for LV2 plugins.
> VST3 allows the GUI to run in a different process?
" The design of VST 3 suggests a complete separation of processor and edit
controller by implementing two components. Splitting up an effect
On Thu, 2011-03-03 at 11:04 +0100, Olivier Guilyardi wrote:
> On 03/03/2011 01:25 AM, David Robillard wrote:
>
> > Anyway, I'd actively like to see GL UIs, since I have a host that's a
> > modular canvas and you could do some pretty awesome things there - but
> > that doesn't mean I think high per
On Fri, 2011-03-04 at 08:56 +1300, Jeff McClintock wrote:
> > From: Paul Davis
> > Subject: Re: [LAD] Portable user interfaces for LV2 plugins.
>
> > VST3 allows the GUI to run in a different process?
>
> " The design of VST 3 suggests a complete separation of pr
On Thursday, March 03, 2011 10:01:22 pm Fons Adriaensen did opine:
> On Wed, Mar 02, 2011 at 09:33:43PM -0500, gene heskett wrote:
> > On Wednesday, March 02, 2011 09:15:32 pm Fons Adriaensen did opine:
> > > On Thu, Mar 03, 2011 at 12:17:40AM +0100, Stefano D'Angelo wrote:
> > > > Does point #1 m
On Mar 3, 2011, at 4:15 PM, David Robillard wrote:
On Fri, 2011-03-04 at 08:56 +1300, Jeff McClintock wrote:
From: Paul Davis
Subject: Re: [LAD] Portable user interfaces for LV2 plugins.
VST3 allows the GUI to run in a different process?
" The design of VST 3 suggests a com
On Thu, 2011-03-03 at 19:50 -0800, Sean Bolton wrote:
> On Mar 3, 2011, at 4:15 PM, David Robillard wrote:
>
> > On Fri, 2011-03-04 at 08:56 +1300, Jeff McClintock wrote:
> >>> From: Paul Davis
> >>> Subject: Re: [LAD] Portable user interfaces for LV2 plugin
On Friday 04 March 2011 04:40:06, David Robillard wrote:
> Right now it's all in-process because embedding is awesome and
> there's no reason to do otherwise and lose it)
Hmm? How isn't embedding orthogonal to separate-process?
What is it you lose again?
--
Pedro Alves
On Fri, Mar 4, 2011 at 6:02 AM, Pedro Alves wrote:
> On Friday 04 March 2011 04:40:06, David Robillard wrote:
>> Right now it's all in-process because embedding is awesome and
>> there's no reason to do otherwise and lose it)
>
> Hmm? How isn't embedding orthogonal to separate-process?
> What is
2011/3/4 Paul Davis :
> On Fri, Mar 4, 2011 at 6:02 AM, Pedro Alves wrote:
>> On Friday 04 March 2011 04:40:06, David Robillard wrote:
>>> Right now it's all in-process because embedding is awesome and
>>> there's no reason to do otherwise and lose it)
>>
>> Hmm? How isn't embedding orthogonal to
On 03/04/2011 01:04 AM, David Robillard wrote:
> On Thu, 2011-03-03 at 11:04 +0100, Olivier Guilyardi wrote:
>> On 03/03/2011 01:25 AM, David Robillard wrote:
>>
>>> Anyway, I'd actively like to see GL UIs, since I have a host that's a
>>> modular canvas and you could do some pretty awesome things
2011/3/3 Fons Adriaensen :
> On Wed, Mar 02, 2011 at 07:37:37PM -0500, David Robillard wrote:
>
>> Bang on. /This/ is the kind of UI stuff that actually matters.
>>
>> If you gave someone actually interested in making music or doing pro
>> audio (or...) a choice between:
>
> I guess the situation c
On Fri, Mar 04, 2011 at 01:53:55PM +0100, Stefano D'Angelo wrote:
> E.g., a compressor, following Olivier's reasoning, could show a
> compression curve (à la Calf) and maybe a dot on that curve that
> indicates "where you are" on average in the last, say, 0.1 seconds.
A simple bargraph showing t
2011/3/4 Fons Adriaensen :
> On Fri, Mar 04, 2011 at 01:53:55PM +0100, Stefano D'Angelo wrote:
>
>> E.g., a compressor, following Olivier's reasoning, could show a
>> compression curve (à la Calf) and maybe a dot on that curve that
>> indicates "where you are" on average in the last, say, 0.1 secon
On 03/04/2011 01:53 PM, Stefano D'Angelo wrote:
> Hence, in this case, I think we should exploit the
> extensibility/decentralization of LV2: those who, like me, care about
> "control rate" visualization hints may want to help on web UIs, for
> example, the others might do the same with native GL.
2011/3/4 Olivier Guilyardi :
> On 03/04/2011 01:53 PM, Stefano D'Angelo wrote:
>> Hence, in this case, I think we should exploit the
>> extensibility/decentralization of LV2: those who, like me, care about
>> "control rate" visualization hints may want to help on web UIs, for
>> example, the others
On 03/04/2011 03:40 PM, Stefano D'Angelo wrote:
> 2011/3/4 Olivier Guilyardi :
>> But LV2 is extensible. So what I think is that in addition to the extensions
>> which imply UI/engine separation (and I understand that it's important in
>> many
>> cases), there should be a DoWhatTheFuckYouWantInYo
On Fri, 2011-03-04 at 11:02 +, Pedro Alves wrote:
> On Friday 04 March 2011 04:40:06, David Robillard wrote:
> > Right now it's all in-process because embedding is awesome and
> > there's no reason to do otherwise and lose it)
>
> Hmm? How isn't embedding orthogonal to separate-process?
> Wh
On Fri, 2011-03-04 at 13:43 +0100, Olivier Guilyardi wrote:
> On 03/04/2011 01:04 AM, David Robillard wrote:
> > On Thu, 2011-03-03 at 11:04 +0100, Olivier Guilyardi wrote:
> >> On 03/03/2011 01:25 AM, David Robillard wrote:
> >>
> >>> Anyway, I'd actively like to see GL UIs, since I have a host th
On Fri, 2011-03-04 at 13:53 +0100, Stefano D'Angelo wrote:
[...]
> The only thing that we all need to ensure is that things work well
> together, whatever the host/plugin author choice is, also trying to
> make the whole thing as painless as it can be for everybody.
>
> Side note: this is yet anot
On Fri, 2011-03-04 at 15:24 +0100, Olivier Guilyardi wrote:
> On 03/04/2011 01:53 PM, Stefano D'Angelo wrote:
> > Hence, in this case, I think we should exploit the
> > extensibility/decentralization of LV2: those who, like me, care about
> > "control rate" visualization hints may want to help on w
On Friday 04 March 2011 19:38:28, David Robillard wrote:
> The plugin UI provides whatever widget it is natively implemented in.
> The host requests whatever widget type it is natively implemented in.
Why widget type/toolkit at all? If you want to abstract,
why not abstract at a lower level? Ma
On Fri, Mar 4, 2011 at 4:45 PM, Pedro Alves wrote:
> On Friday 04 March 2011 19:38:28, David Robillard wrote:
>> The plugin UI provides whatever widget it is natively implemented in.
>> The host requests whatever widget type it is natively implemented in.
>
> Why widget type/toolkit at all? If yo
On Friday 04 March 2011 22:00:47, Paul Davis wrote:
> but why? real hosts are not written with Xlib, they are written with
> Qt, or GTK or ...
Of course.
> embedding another Gtk widget into a Gtk window is a LOT easier
> than embedding an X window ID, and in fact is the whole reason why
> libsu
On Fri, 2011-03-04 at 21:45 +, Pedro Alves wrote:
> On Friday 04 March 2011 19:38:28, David Robillard wrote:
> > The plugin UI provides whatever widget it is natively implemented in.
> > The host requests whatever widget type it is natively implemented in.
>
> Why widget type/toolkit at all?
On Fri, 2011-03-04 at 22:56 +, Pedro Alves wrote:
> On Friday 04 March 2011 22:00:47, Paul Davis wrote:
>
> > but why? real hosts are not written with Xlib, they are written with
> > Qt, or GTK or ...
>
> Of course.
>
> > embedding another Gtk widget into a Gtk window is a LOT easier
> > th
On 03/04/2011 08:51 PM, David Robillard wrote:
> However, there is an extension a UI can use to get a pointer to a plugin
> instance, which is mostly what you are talking about:
>
> http://lv2plug.in/ns/ext/instance-access/
>
> I do not recommend its use for any situation except where it is
> ab
On 03/02/2011 03:30 PM, Stefano D'Angelo wrote:
> However, as I see it now, this is a possible list of GUI techonologies
> that may be worth considering:
> 1. HTML/JS/CSS (web UIs)
> 2. OpenGL (advanced UIs)
> 3. GTK+ and Qt (almost all current LV2 desktop hosts use either)
> 4. EFL (might be soun
90 matches
Mail list logo
