Subject: Re: [linux-audio-dev] XAP status : incomplete draft
From: Tim Hockin (thockin_AT_hockin.org)
Date: Sat Dec 14 2002 - 00:42:04 EET
> I'd still like to see a list of fully compliant compilers. IIRC, I've
It's easy enough to get stdint.h from somewhere, too. I'll try not to rely
on it too much :)
> > > > int xap_n_ports;
> > > > XAP_port **ch_ports;
> > >
> > > What are these for? Shortcut to avoid the more complex system
> > > below, when you don't really need it?
> >
> > Audio ports - master audio ports.
>
> And what are those, really? Isn't that the same thing as having a
> bunch of Audio Ports somewhere? This looks redundant to me.
I thought that the master should be analogous to a channel. Simple synths
have no channels at all, and have everything in master? hrrm, no.
Every synth has one channel at least. How about FX. FX can have everything
master. A simple effect has master controls and master I/O.
yes/no?
> For example, audio driver plugins will need to initialize the driver
> and put it in pause mode, or there is a great chance the playback
> will be delayed by a rather significant (and random) amount of time.
> This is mostly a "minor" driver problem with certain sound cards, but
> I think it might matter a whole lot if you happen to have some
> external device that is supposed to sync before you start playback.
> This is the only real issue I could think of right now...
Ok, I'll buy that. I don't know what can't be done in activate(), though.
See below.
> an event equivalent to "stop all notes" or something...
yes, that is needed
> Either way, it's important to note that (at least the way I see it)
> the engine does not stop just because you stop the sequencer. For
I agree. even if I pause the sequencer, I still want my MIDI keyboard to
work.
> there to be any point in that, most plugins should just keep doing
> what they're doing and ignore that the sequencer stopped. Plugins
> that are interested in musical time or other timeline relative things
> will get a nice TRANSPORT_STOP event or something.
I do want to figure a clean way to not-process effects that are not doing
any work. I have an idea, but I want to bring it up in a sepearte thread :)
> > Optional things are controls. It is a nice way of indicating I
> > do/don't support 'feature'. Non-optional stuff ought not be
> > controls, IMHO.
>
> Yes, that's a good point.
That said - are there any controls I've listed that are not optional?
> > What's missing? I thought about state() and decided this was
> > complete. Did I miss something?
>
> prepare()/unprepare(), maybe, but I'm not sure. Can you expand on the
> ACTIVE and INACTIVE states, and the transitions. (What you may and
> may not do, what you're supposed to do, etc.)
Plugin is instantiated: set to INACTIVE (not really a state variable, but
you get the idea).
While inactive the host may: destroy, connect_port, disable_port, send
control events (this is now fun, since note on is an event, uggh). I'm
going to have a bit more think about it now. Whatever we end up with, I
want as FEW states and transitions as possible.
> reason. I'll dig through the VST and EASI docs again... (Yeah, EASI -
please do, I don't know VST from an API pov.
> has to be passed around inside plugins, and 1) that affects every
> plugin author, and 2) there will (hopefully) be many more plugins
> than "feedback enabled" hosts.
fair enough.
> > Do you think we also need a per-host identifier? Is a string good
> > enough? (I don't want to have to manage host IDs and plugin IDs :)
>
> Well, let's put it like this: I *really* hope we won't have to do the
> VST thing and have plugins adapting to the bugs and quirks of the
> most popular hosts! :-)
AMEN! This is why I left it out. That said, do you think it is a good idea
to cover that base, just in case? pass a char *name as part of the host?
> > What if we have a host->get_event_port(..., XAP_event_port
>
> Yes. (I was thinking "cookie", but didn't get any further...)
Good! I rather like that answer.
> BTW, how about calling that queue + cookie struct XAP_event_target or
on my list is to rething names to clarify and shorten :)
> But why not do it right, and just call it host->failure() or
> something, and have an enum argument describing what kind of problem
> you have? Then you could report I/O errors and stuff as well...
works for me.
> On a related matter, I had this idea of providing a simple host
> service that lets you run a function in a background thread, and get
So did I :) host->start_thread(function); The question is HOW FAR do we
want to go with that. Slippery slope. Can we say that plugins can count on
pthreads being available? Or do we need a simple thread API via the host?
How simple? Too simple and plugins will require pthreads or something
anyway. Too complex and we'll spend a lifetime arguing about it...
> > I've completey ignored the pitch thread until I had time to digest
> > it :)
>
> I don't blame you...! :-)
I'm going to have to read it and revive it, I'm sure, just to fan flames.
As soon as I catch up, perhaps this weekend.
As a total non-sequitur:
I once was faced with the decision of spending my time making music or
spending my time making software to make music. I decided on music. Then I
got frustrated with my music software. And I faced the decision again.
This repeated itself about 5 times. Each time I started a proposal and then
got back into music. I finally posted my proposal, and the vigor with which
the discussion has been going has kept me in it. Thanks to everyone for
that :) Meantime, I haven't touched my music :) Oh well, priorities.
Tim
This archive was generated by hypermail 2b28 : Sat Dec 14 2002 - 00:50:11 EET