> 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
