this is not meant to intimidate, rather to be a wake-up call.
it seems almost unreal (and certainly unprofessional) to me
that an instrument plugin api is being discussed here by a
bunch of people who have little to no experience in the field
of software sequencers. going into implementation details at
the current level of understanding of the problem space is,
excuse me, ridiculous.
after all, what is going to drive your instrument networks?
punched cardboard? certainly not. you'll either use realtime
input, or a sequencer, or, most wanted, a combination of both.
the closer the integration of the event/plugin system with the
sequencer, the more uses the api can be put to, with less pain.
stopping short of the mark where the api becomes useful for
more applications than basically sample-rate dependent
event->audio converters is narrow-minded. viewing the 'host'
as a blackbox supposed to 'do the rest' without caring about
its internals is blatant ignorance.
i do think it's reasonable to ignore my personal input since
i don't offer published code to back up my views, and when i
do, you'll find it centered around my personal musical needs.
however there are, afaik, people from the rosegarden team on
this list. it would also be helpful having werner schweer of
muse fame participate in some way or other. you might also want
to look at other free/open sequencer engines. for one thing,
you'll find that most, if not all, are tick-based.
vst[i] is a bad candidate i think because few people here will
have vst host-side coding experience, and the api itself is
bound to be centered around the particular coding needs of a
specific company, for a specific application that drags code
with it that originated in the eighties and never was subject
to public source-level review.
in short, the more people with hands-on sequencer experience
participating, the better. none are just too few.
tim
ps: if this post hasn't substantially changed your ways of
perceiving this matter, please don't bother answering.