[linux-audio-dev] XAP status : incomplete draft

[Tim Hockin]

> 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