On Wed, 2006-05-10 at 15:15 +0200, Lars Luthman wrote:
> On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote:
> > On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote:
> > > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
> > > > Is there some equivalent mechanism that let
On Wed, 2006-05-10 at 13:42 +0200, stefan kersten wrote:
> On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
> > Is there some equivalent mechanism that lets dlloaded
> > plugins dig function pointers out of the the host? Thier
> > public symbol linking system is backward too from what
On Wed, May 10, 2006 at 03:15:25PM +0200, Lars Luthman wrote:
> On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote:
> > On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote:
> > > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
> > > > Is there some equivalent mechanism t
On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote:
> On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote:
> > On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
> > > Is there some equivalent mechanism that lets dlloaded
> > > plugins dig function pointers out of the the h
On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote:
> On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
> > Is there some equivalent mechanism that lets dlloaded
> > plugins dig function pointers out of the the host? Thier
> > public symbol linking system is backward too fro
On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
> Is there some equivalent mechanism that lets dlloaded
> plugins dig function pointers out of the the host? Thier
> public symbol linking system is backward too from what I
> remember.
one portable way is to pass a struct of function p
On Mon, May 08, 2006 at 07:32:06 +0200, [EMAIL PROTECTED] wrote:
> > I mean the linker should do it. If you dynamically build the plugin
> > against a stub library and the host exports something with the same ABI, I
> > /think/ the plugin should have the host's version of the function in its
> > na
On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote:
> On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote:
> > On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote:
> > > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote:
> > > > I guess the port things aren't a good
On Tue, May 02, 2006 at 02:34:20 -0400, Phil Frost wrote:
> On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote:
> > On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote:
> > > Do you mean that the plugin should dlopen the host? Wouldn't that
> > > require some way to pass the path
On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote:
> On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote:
> > Do you mean that the plugin should dlopen the host? Wouldn't that
> > require some way to pass the path to the host program to the plugin (in
> > which case you might as
On Mon, May 01, 2006 at 11:33:40PM +0200, Lars Luthman wrote:
> > I mean the linker should do it. If you dynamically build the plugin
> > against a stub library and the host exports something with the same ABI, I
> > /think/ the plugin should have the host's version of the function in its
> > names
On Mon, 2006-05-01 at 22:27 +0100, Steve Harris wrote:
> On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote:
> > On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote:
> > > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote:
> > > > I guess the port things aren't a good justifi
On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote:
> On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote:
> > On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote:
> > > I guess the port things aren't a good justification for the creation
> > > parameters, you're right. The qu
On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote:
> On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote:
> > I guess the port things aren't a good justification for the creation
> > parameters, you're right. The question, then, is what is the
> > recommended way for the host to provi
On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote:
> > IMHO, thats not the way to do any of those things:
> >
> > mono/stereo is best done with dosconnected ports IMHO. That way you can
> > change the connected state and have the plugin react.
>
> mono/stereo isn't the best example. I
On Mon, 2006-05-01 at 21:24 +0100, Steve Harris wrote:
> On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard wrote:
> > struct LADSPA_Parameter {
> > char* name;
> > char* data;
> > }
> >
> > LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor,
> >
On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard wrote:
> struct LADSPA_Parameter {
> char* name;
> char* data;
> }
>
> LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor,
> unsigned longsample_rate,
>
On Mon, 2006-05-01 at 02:13 +0200, Lars Luthman wrote:
> On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote:
> > On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote:
> > > > With the port types specified in the RDF file, MIDI input should be
> > > > doable with explicit LADSPA2 ports
On Mon, May 01, 2006 at 02:13:00AM +0200, Lars Luthman wrote:
> > > > 2) the dynamic program lists and midi mappings (static definitions
> > > > could be written in the RDF file, but that's no fun)
> > >
> > > That's a tougher one.
> >
> > Control port :|
>
> Not really - plugins only ge
On Sun, Apr 30, 2006 at 06:39:05 -0400, Dave Robillard wrote:
> > > > Dave, you complain about people talking down about modular
> > > > synths, then yourself discount things that are only useful in
> > > > non-modular designs? How about a little reciprocity here?
> > > [snip]
> > >
> > > ... a s
On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote:
> On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote:
> > > With the port types specified in the RDF file, MIDI input should be
> > > doable with explicit LADSPA2 ports of some defined MIDI type, which
> > > means that we wouldn't n
On Sun, 2006-04-30 at 20:49 +0100, Steve Harris wrote:
> On Sun, Apr 30, 2006 at 11:59:25 -0400, Dave Robillard wrote:
> > On Sun, 2006-04-30 at 08:49 -0700, Sean Bolton wrote:
> > > On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote:
> > > > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
>
On Sun, Apr 30, 2006 at 11:59:25 -0400, Dave Robillard wrote:
> On Sun, 2006-04-30 at 08:49 -0700, Sean Bolton wrote:
> > On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote:
> > > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
> > >> 4) the run_multiple*() callbacks (how many plugins use th
Chris Cannam schrieb:
On Sunday 30 Apr 2006 00:01, Dave Robillard wrote:
We need a better API with which to build good, useful things.
Use LACPA instead of LADSPA ;-)
It has
* audio i/o support
* sample accurate midi i/o support
* controls with midi mapping
* timeinfo support: tempo/b
On Sun, 2006-04-30 at 08:49 -0700, Sean Bolton wrote:
> On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote:
> > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
> >> 4) the run_multiple*() callbacks (how many plugins use these?)
> >
> > Silly useless function. Toss it on the trash heap with
On Sun, 2006-04-30 at 12:38 +0100, Steve Harris wrote:
> On Sun, Apr 30, 2006 at 11:37:28 +0100, Chris Cannam wrote:
> > On Sunday 30 Apr 2006 00:01, Dave Robillard wrote:
> > > We need a better API with which to build good, useful things.
> >
> > So what are those things, and how will LADSPA2 get
On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote:
On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
4) the run_multiple*() callbacks (how many plugins use these?)
Silly useless function. Toss it on the trash heap with run_adding.
Dave, you complain about people talking down about mod
On Sun, Apr 30, 2006 at 11:37:28 +0100, Chris Cannam wrote:
> On Sunday 30 Apr 2006 00:01, Dave Robillard wrote:
> > We need a better API with which to build good, useful things.
>
> So what are those things, and how will LADSPA2 get us to them? I'm not
> looking for perfect foresight here, just
On Sunday 30 Apr 2006 00:01, Dave Robillard wrote:
> We need a better API with which to build good, useful things.
So what are those things, and how will LADSPA2 get us to them? I'm not
looking for perfect foresight here, just some inspiring examples.
Just because one API is easier to extend th
On Sat, 2006-04-29 at 18:42 +0100, Steve Harris wrote:
> On Sat, Apr 29, 2006 at 12:40:11PM -0400, Dave Robillard wrote:
> > On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote:
> > > I haven't posted to this thread yet, for a couple of reasons besides the
> > > usual lack of time.
> > >
> > >
On Sat, Apr 29, 2006 at 06:43:14PM +0100, Chris Cannam wrote:
> On Saturday 29 Apr 2006 17:42, Dave Robillard wrote:
> > On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
> > > The things that aren't obvious how to do are
> > >
> > > 1) the configure() callback
> >
> > OSC message.
>
> And t
On Saturday 29 Apr 2006 17:42, Dave Robillard wrote:
> On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
> > The things that aren't obvious how to do are
> >
> > 1) the configure() callback
>
> OSC message.
And there you've introduced something I haven't seen in this thread yet:
sending mes
On Sat, Apr 29, 2006 at 12:40:11PM -0400, Dave Robillard wrote:
> On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote:
> > I haven't posted to this thread yet, for a couple of reasons besides the
> > usual lack of time.
> >
> > One reason is that on a technical level I don't have any argument w
On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote:
> > With the port types specified in the RDF file, MIDI input should be
> > doable with explicit LADSPA2 ports of some defined MIDI type, which
> > means that we wouldn't need the run_synth() callback. The GUI
> > specification and the
On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
> On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote:
> > This format is really going to have to aim to grow into something that
> > can replace DSSI as well. And while that could be great, it's a much
> > more snaggly business -- DSSI ha
On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote:
> I haven't posted to this thread yet, for a couple of reasons besides the
> usual lack of time.
>
> One reason is that on a technical level I don't have any argument with
> most of what Steve says. Removing descriptive data from the plugin
On Sat, 2006-04-29 at 15:09 +0100, Chris Cannam wrote:
> This format is really going to have to aim to grow into something that
> can replace DSSI as well. And while that could be great, it's a much
> more snaggly business -- DSSI has turned out pretty complicated, for
> some very sound reasons
I haven't posted to this thread yet, for a couple of reasons besides the
usual lack of time.
One reason is that on a technical level I don't have any argument with
most of what Steve says. Removing descriptive data from the plugin I
think is a good principle. I'm not fond of this Turtle form
On Fri, 2006-04-28 at 14:33 -0400, Dave Robillard wrote:
> Google around the 'net for some examples of the same data in RDF/XML
> versus Turtle. You'll change your mind real quick. ;)
great, another damn data format. we need to pull in _more_ dependencies.
it is important to have _more_ crude dat
On Fri, 2006-04-28 at 11:12 +0100, Damon Chaplin wrote:
> On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote:
> > On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote:
> > > The RDF stuff is looking more and more arcane and hairy with each
> > > iteration, with all those colons, periods
On Fri, Apr 28, 2006 at 11:12:13AM +0100, Damon Chaplin wrote:
> On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote:
> > On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote:
> > > The RDF stuff is looking more and more arcane and hairy with each
> > > iteration, with all those colons, p
On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote:
> On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote:
> > The RDF stuff is looking more and more arcane and hairy with each
> > iteration, with all those colons, periods and quotes, plus some
> > SQL'ish for good measure. Human readab
On Thu, Apr 27, 2006 at 09:09:57PM +0200, Leonard paniq Ritter wrote:
> On Thu, 2006-04-27 at 05:13 -0400, Dave Robillard wrote:
> > On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote:
> > > http://plugin.org.uk/ladspa2/
> > >
> > > Removed the :logarithmic hint, I agree with Paul, its not
> >
On Thu, Apr 27, 2006 at 01:14:09PM +0200, Luis Garrido wrote:
> The RDF stuff is looking more and more arcane and hairy with each
> iteration, with all those colons, periods and quotes, plus some
> SQL'ish for good measure. Human readable? I begin to miss the
> syntactic simplicity of only using an
On Thu, 2006-04-27 at 05:13 -0400, Dave Robillard wrote:
> On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote:
> > http://plugin.org.uk/ladspa2/
> >
> > Removed the :logarithmic hint, I agree with Paul, its not
> > fit-for-purpose as specified.
>
> er, I need logarithmic. if it's not fit-for-
On Thu, 2006-04-27 at 13:14 +0200, Luis Garrido wrote:
> The RDF stuff is looking more and more arcane and hairy with each
> iteration, with all those colons, periods and quotes, plus some
> SQL'ish for good measure. Human readable? I begin to miss the
> syntactic simplicity of only using angled br
The RDF stuff is looking more and more arcane and hairy with each
iteration, with all those colons, periods and quotes, plus some
SQL'ish for good measure. Human readable? I begin to miss the
syntactic simplicity of only using angled brackets in XML. Sigh, not
another syntax to learn, please.
Luis
On Thu, Apr 27, 2006 at 05:13:24 -0400, Dave Robillard wrote:
> On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote:
> > http://plugin.org.uk/ladspa2/
> >
> > Removed the :logarithmic hint, I agree with Paul, its not
> > fit-for-purpose as specified.
>
> er, I need logarithmic. if it's not fit
On Thu, 2006-04-27 at 09:45 +0100, Steve Harris wrote:
> http://plugin.org.uk/ladspa2/
>
> Removed the :logarithmic hint, I agree with Paul, its not
> fit-for-purpose as specified.
er, I need logarithmic. if it's not fit-for-purpose as specified then
we can specify it differently. it's in ladsp
http://plugin.org.uk/ladspa2/
Removed the :logarithmic hint, I agree with Paul, its not
fit-for-purpose as specified.
I'm now using the DOAP schema (http://usefulinc.com/doap) instead of Dublin
Core for software information, much more appropriate.
Fixed a load of typos in the schema and examples
50 matches
Mail list logo
