Re: [linux-audio-dev] Plugin APIs (again)

> > controls, two filter controls etc and making them slightly > > different and behave differently in each plug. Are we better to > > define the behavior, or at least offer a suggestion? > > 2D "address space": > Dimension 1:Channel > Dimension 2:Control Do we really want to

Re: [linux-audio-dev] Plugin APIs (again)

> I think we're actually talking about *three* kinds of controls, while > everyone is still talking about their own set of two kinds of > controls. What I'm thinking is: > Master Controls: > Channel/Part Controls: > Voice/Note Controls So if we support multi-timbral (multi-par

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 03.27, John Lazzaro wrote: > > David Olofson <[EMAIL PROTECTED]> writes: > > > > Yes - but we're not talking about MIDI here. We *may* require > > that events are never lost, and even that it's not legal to send > > two identical events in line to an event port, unless yo

Re: [linux-audio-dev] Plugin APIs (again)

> David Olofson <[EMAIL PROTECTED]> writes: > > Yes - but we're not talking about MIDI here. We *may* require that > events are never lost, and even that it's not legal to send two > identical events in line to an event port, unless you really mean > something else than to set a controller to th

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 02.25, John Lazzaro wrote: > > David Olofson writes: > > > > The point I think you're missing is that a "control change" event > > is *exactly* the same thing as a "voice start" event on the bits > > and bytes level. > > Lossy MIDI filters will prune away two MIDI Control

Re: [linux-audio-dev] Plugin APIs (again)

> David Olofson writes: > > The point I think you're missing is that a "control change" event is > *exactly* the same thing as a "voice start" event on the bits and > bytes level. Lossy MIDI filters will prune away two MIDI Control Change commands in a row for the same controller value with the

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 01.26, Nathaniel Virgo wrote: > On Saturday 07 December 2002 11:29 pm, David Olofson wrote: [...velocity or not...] > > Well, keep arguing, and I'll try to figure out more reasons why > > velocity is not special, nor universal. ;-) > > I think velocity is special because

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 01.03, Steve Harris wrote: > On Sat, Dec 07, 2002 at 09:26:12 +0100, David Olofson wrote: > > > Yes, more or less. I was using instrument as in VSTi > > > instrument, ie an instance of a thing instantiated from a .so > > > file. The word plugin is far too overloaded. > >

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 01.02, Tim Hockin wrote: > > > Why? What is it that LADSPA does that would be so complicated > > > that an instrument API must not support it? > > > > Nothing, OAPI or whatever will be a superset I imagine, but that > > implies that LADSPA will still be simpler. > > yeah,

Re: [linux-audio-dev] Plugin APIs (again)

On Saturday 07 December 2002 11:29 pm, David Olofson wrote: > [..] > > > MIDI has 2 velocities - note_on and note_off. I see velocity as > > specific to those two events. Isn't a new velocity event really a > > new strike or attack of the instrument, or, in other words a new > > voice (even if it

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 01.01, Steve Harris wrote: > On Sun, Dec 08, 2002 at 12:29:24 +0100, David Olofson wrote: > > > SILENT (plugin to host - sent when reverb tails or whatnot have > > > died..) > > > > Great idea. Sample accurate end-of-tail notification. :-) (In > > Audiality, I do that by

Re: [linux-audio-dev] Plugin APIs (again)

On Sunday 08 December 2002 00.52, Steve Harris wrote: > On Sun, Dec 08, 2002 at 12:03:14 +0100, David Olofson wrote: > > Are we going to have LADSPA, and soon OAPI (or whatever it'll be) > > - and in a year or two, another API, effectively merging LADSPA > > and OAPI? > > > > Why? What is it that L

Re: [linux-audio-dev] Plugin APIs (again)

On Sat, Dec 07, 2002 at 09:26:12 +0100, David Olofson wrote: > > Yes, more or less. I was using instrument as in VSTi instrument, ie > > an instance of a thing instantiated from a .so file. The word > > plugin is far too overloaded. > > Ok. (But VSTis can be multichanne/multipart, AFAIK.) OK, but

Re: [linux-audio-dev] Plugin APIs (again)

> > Why? What is it that LADSPA does that would be so complicated that an > > instrument API must not support it? > > Nothing, OAPI or whatever will be a superset I imagine, but that implies > that LADSPA will still be simpler. yeah, and I want to make it easy for an OAPI (I HATE that name - ope

Re: [linux-audio-dev] Plugin APIs (again)

On Sun, Dec 08, 2002 at 12:29:24 +0100, David Olofson wrote: > > SILENT (plugin to host - sent when reverb tails or whatnot have > > died..) > > Great idea. Sample accurate end-of-tail notification. :-) (In > Audiality, I do that by fiddling with the plugin state, which is > rather ugly and not

Re: [linux-audio-dev] Plugin APIs (again)

On Sun, Dec 08, 2002 at 12:03:14 +0100, David Olofson wrote: > Are we going to have LADSPA, and soon OAPI (or whatever it'll be) - > and in a year or two, another API, effectively merging LADSPA and > OAPI? > > Why? What is it that LADSPA does that would be so complicated that an > instrument A

Re: [linux-audio-dev] Plugin APIs (again)

On Saturday 07 December 2002 22.13, Tim Hockin wrote: [...] > > > So no one has offered me any suggestions on how we handle the > > > clash between Master and per-voice controls. To re-ask: > > > > Ban it :) > > I'm not sure we can reasonably do that. We can say that no one > control applies to b

Re: [linux-audio-dev] Plugin APIs (again)

On Saturday 07 December 2002 21.17, Steve Harris wrote: > > > The intention is that these things would (on the whole) be > > > sound generators, right? To me plugin implies inline > > > processing. > > > > This API is not purely instrumental. It can certainly be for > > effects and sinks, too. Th

Re: [linux-audio-dev] Plugin APIs (again)

On Saturday 07 December 2002 20.12, Tim Hockin wrote: > Combining three replies: > > Steve Harris <[EMAIL PROTECTED]> wrote: > > On Sat, Dec 07, 2002 at 12:25:09 -0800, Tim Hockin wrote: > > > This is what I am thinking: One of the flags on each control > > > is whether it is a CTRL_MASTER, or a C

Re: [linux-audio-dev] Plugin APIs (again)

> Not defining them seperatly, but making a distinction, I dont think one > control should be applied per voice and per instrument. So one should not be able to manipulate a per-voice volume and a master volume? > > So no one has offered me any suggestions on how we handle the clash between > > M

Re: [linux-audio-dev] The global API namespace

On Saturday 07 December 2002 18.21, Paul Davis wrote: [...Audiality naming conventions...] > see? c++ is good for something, eh? Well, there must be a reason why it was created, I guess... ;-) [...] > i can imagine that > there are cases where namespaces could be considered so valuable as > to m

Re: [linux-audio-dev] Plugin APIs (again)

On Saturday 07 December 2002 17.33, Steve Harris wrote: > On Sat, Dec 07, 2002 at 04:44:39 +0100, David Olofson wrote: > > I'm still not sure I understand the terminology here... > > Considering some recent posts, I assume that the following > > applies: > > Yes, more or less. I was using instrumen

Re: [linux-audio-dev] Plugin APIs (again)

On Sat, Dec 07, 2002 at 11:12:54 -0800, Tim Hockin wrote: > What advantage do you see to defining them seperately? Certainly the > structures are analogous, if not identical. Not defining them seperatly, but making a distinction, I dont think one control should be applied per voice and per instru

Re: [linux-audio-dev] Plugin APIs (again)

Combining three replies: Steve Harris <[EMAIL PROTECTED]> wrote: > > On Sat, Dec 07, 2002 at 12:25:09 -0800, Tim Hockin wrote: > > This is what I am thinking: One of the flags on each control is whether it > > is a CTRL_MASTER, or a CTRL_VOICE (or both). This allows the plugin to > > define a

Re: [linux-audio-dev] The global API namespace

>> How about this for Audiality: >> >> Functions: a_whatever() >> Types: at_whatever > >I think a_ is too breif. aud_foo(), maybe. And types of AUD_foo_type; >Its the easiest. Because nothing sucks worse than accidentally namig a >variable or function the same as a type

Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 + lowlat +preempt + alsa + jack = dead computer

>Are you certain your freeze is actually happening in kernel space? >Tried using watchdog with "ping-pong" between highest and lowest >priority SCHED_FIFO threads? (BTW, we should have a watchdog anyway, >probably integrated with givertcap or something.) JACK has its own watchdog thread. if eng

Re: [linux-audio-dev] Plugin APIs (again)

On Sat, Dec 07, 2002 at 04:44:39 +0100, David Olofson wrote: > I'm still not sure I understand the terminology here... Considering > some recent posts, I assume that the following applies: Yes, more or less. I was using instrument as in VSTi instrument, ie an instance of a thing instantiated from

Re: [linux-audio-dev] The global API namespace

On Saturday 07 December 2002 16.59, David Olofson wrote: > On Saturday 07 December 2002 07.36, Tim Hockin wrote: [...] > > aud_foo(), maybe. And types of > > AUD_foo_type; Its the easiest. ady_*() and ADY_*...? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return

Re: [linux-audio-dev] The global API namespace

On Saturday 07 December 2002 07.36, Tim Hockin wrote: > > How about this for Audiality: > > > > Functions: a_whatever() > > Types: at_whatever > > I think a_ is too breif. I think so too... Could mean anything - and many names and words start with an 'a'. > aud_foo(), may

Re: [linux-audio-dev] Plugin APIs (again)

On Saturday 07 December 2002 12.21, Steve Harris wrote: > On Sat, Dec 07, 2002 at 12:25:09 -0800, Tim Hockin wrote: > > This is what I am thinking: One of the flags on each control is > > whether it is a CTRL_MASTER, or a CTRL_VOICE (or both). This > > allows the plugin to define a ctrl labelled

Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1ÂÂ + lowlat +preempt + alsa + jack = dead computer

audality looks good. we are currently using fmod for a large games based arts project that sadly had to be win32 due to the nature of out middleware sponsorship currently i am using the NeL engine and hope to integrate fmo

Re: [linux-audio-dev] lrdf version 0.1.2

On Sat, Dec 07, 2002 at 09:16:29 -0500, Taybin Rutkin wrote: > > There is a new libraptor out with the patches I need applied, I guess > > people would prefer it if I just depended on that, rather than including > > it? > > I would. OK, sounds sensible anyway. liblrdf 0.1.3 http://plugin.org.uk/

Re: [linux-audio-dev] lrdf version 0.1.2

On Sat, 7 Dec 2002, Steve Harris wrote: > > Actually, those programs in there don't seem to work at all. > > OK, I've fixed the problems, I just needed to RTFM a bit better. > > There is a new libraptor out with the patches I need applied, I guess > people would prefer it if I just depended on t

Re: [linux-audio-dev] lrdf version 0.1.2

On Fri, Dec 06, 2002 at 11:08:10 -0500, Taybin Rutkin wrote: > On Thu, 28 Nov 2002, Steve Harris wrote: > > > examples/example.rdf contains a slighly out of date description of my > > plugins. There are some example programs that show how the API works. > > Actually, those programs in there don't

Re: [linux-audio-dev] Plugin APIs (again)

On Sat, Dec 07, 2002 at 12:25:09 -0800, Tim Hockin wrote: > This is what I am thinking: One of the flags on each control is whether it > is a CTRL_MASTER, or a CTRL_VOICE (or both). This allows the plugin to > define a ctrl labelled (for example) VELOCITY and the host can connect it to > any MIDI

Re: [linux-audio-dev] lrdf version 0.1.2

On Fri, Dec 06, 2002 at 11:08:10 -0500, Taybin Rutkin wrote: > On Thu, 28 Nov 2002, Steve Harris wrote: > > > examples/example.rdf contains a slighly out of date description of my > > plugins. There are some example programs that show how the API works. > > Actually, those programs in there don't

Re: [linux-audio-dev] Plugin APIs (again)

So, I'm incorporating the things that were discussed this week into my API proposal. It's starting to take shape, and I really appreciate the feedback I got (why I can't get that level of feedback even at work, is beyond me). I've hit a couple of large questions that I want to bounce off you all.