Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 22.41, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 10:16:30 +0100, David Olofson wrote:
> > JACK client:
>
> ...
>
> > =09- Linux still breaks JACK out-of-process latency... :-(

Seems to be a scheduler issue, but I don't have first hand experience=20
with this. I don't know if it's been fixed yet, but Paul have been=20
complaining about it every now and then.


> > XAP plugin:
> > =09+ You don't have to worry about audio I/O.
> > =09+ There is a comprehensive instrument control protocol.
> > =09+ Control and audio routing and transport is integrated.
> > =09+ You're running in-process, which works well on any LL kernel.
>
>         - Doesn't exist yet ;)

That's a point! :-)


>         - Each point in the overall graph will be a different
>           instance

Yes, but that applies to JACK and applications as well. I don't see=20
what you mean.


>         - Making the threading work well with all hosts will be
>           hard

Possibly. Do you have some details on this? (Conflicts with what the=20
host is doing or whatever.)


>         - No way of receiving arbitary MIDI data (is that useful?)

It's not useful for normal stuff, since you can map all RT MIDI=20
events to XAP events one way or another through a standard=20
driver/translator plugin. In fact, you can even pipe SysEx through=20
XAP (as data controls), so there might just not be a need for MIDI at=20
all; just a standard way of passing "non-standard" stuff to plugins,=20
if they want it. (You'd just have input ports for SysEx if you want=20
it.)


>         - No direct JACK i/o

Why would you need that if you're a XAP plugin? It's the host that=20
decides where your audio ports are connected. That's one of the few=20
really significant differences between JACK and LADSPA, XAP, VST etc.


> The obvious solution is to provide the services as both XAP and
> JACK.

Yes... Although I don't see why you couldn't provide your own=20
JACKified XAP host that automatically loads and hooks up=20
LinuxSampler. XAP would just be the native API of the synth - wrap as=20
you like, using standard or custom wrappers.

Or you could just make the sampler a lib with whatever interface you=20
like, and then implement "wrappers" for JACK, XAP, VST or whatever.=20
Not sure I see the point in designing your own private API just for=20
that, though.

I was going to do something like that with Audiality, but haven't=20
decided how to do it yet. I might just make it a XAP plugin, as XAP=20
and Audiality internals have lots in common anyway. There will still=20
be an easy to use "games sound engine" style API as well, but that=20
could be implemented as a specialized XAP host for Audiality (or=20
maybe even a "real" XAP host), rather than Audiality itself.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---