13 Dec
2002
13 Dec
'02
6:47 p.m.
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? 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. 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.) 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! :-) What if we
have a host->get_event_port(..., XAP_event_port
Yes. (I was thinking "cookie", but didn't get any further...) 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...! :-)