On Friday 13 December 2002 23.42, Tim Hockin wrote: [...] > > > > > 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?
Well, there are still two ways of doing the same thing. I think the whole "Master" term has become a bit too important. It's existence is only motivated by two things: 1) It can have a bunch of (optional) controls that are meant to always affect the whole plugin. 2) It's a "shortcut" for the Host to get the right Event Queue for host<->plugin communication. I'd say that unless some things change, 1) is invalid as well, since those Controls are just another control channel! There is nothing special about the Master whatsoever, unless it has some non-optional Controls that are defined in the API, and meant for important host/plugin communication. The normal Master controls are just meant to be used as any Controls. Did I forget something? I'm not so sure about 2), but it seems like we don't have any specific host->plugin events anyway. Everything is done through function calls. [...] > > an event equivalent to "stop all notes" or something... > > yes, that is needed Is that perhaps, our first host->plugin event? Good thing with host->plugin events is that you can *totally* ignore the ones you don't care about. They just fall through to your default case, and then the event goes back to the pool like the rest. :-) > > 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. Exactly - that's most important, especially if you have only softsynths, and your studio mixer is virtual! :-) > > 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 :) Ok. BTW, I just remembered that there is a distinct difference between TRANSPORT_STOP and setting tempo to 0. The latter can't replace the former, since then all you tempo sync'ed effects will die! Better let the tempo run and really have POSITION_START/STOP. Tempo-only plugins would just ignore all POSITION* events anyway, but timeline locked plugins will need all of them. > > > 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? I guess not... Doesn't seem like we need any non-optional Controls - but then, max block size, sample rate and that kind of stuff must be passed through various function calls. I would suggest that "max block size" could be an optional Control, though. Not all plugins need it, but some *definitely* do. If there's no Master Control for it, the Host won't send it... > > > 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). Send control events *where*? An RT host will have to instantiate plugins in a separate thead, and event Queues are not thread safe... So you must absolutely not send events anywhere other than to the host - which may in fact not at all be the host you're going to be under when you're in the RT net. Yeah, this has to be dealt with as well. The host must be able to tell the plugin that it belongs to another host. The plugin must not do anything that not RT safe as a response to this. > 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. Yes. > > reason. I'll dig through the VST and EASI docs again... (Yeah, > > EASI - > > please do, I don't know VST from an API pov. Well, I don't seem to get around to it for some strange reason! ;-) [...] > > > 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? Maybe, for debugging reasons. After all, any full RT host will have at least two host structs - one "fake" for instantiation, and one for the actual engine. It might be nice if plugins could print out which host they're under at any time. (Addresses aren't all that nice to read, and you may not want to, or be able to hack the host for this.) So, throw it in, but let's make sure to tell everyone not to get any ideas about it... :-) [...] > > 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. Ok. > > > 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. Yeah. Very, very basic, I'd say. Until we actually know what is needed, at least. Maybe when Linuxsampler is ready for prime time, we'll know enough to extract truly useful mechanisms and put them in XAP 2.0. So, just make it a basic async RPC style call. Give the host a function, some data and the queue where you want the completion event when the function returns. You *can* still actually use that as a real thread, but you'll have to make sure the host doesn't "cheat" (see below), and you're on your own when it comes to sync and stuff. > Can we say that > plugins can count on pthreads being available? Not sure... pthreads isn't exactly portable, especially not when it comes to non-Unix platforms. SDL has it's own API (nice and simple), and there's a reason for it. I think having plugins to drag in pthreads just to read a file as a response to a Control change is a bit much to ask for something this basic. Besides, if we're talking *real simple*, a basic "semi-RT" host might just do this: int start_thread(queue, func, arg) { result = func(arg); return XAP_send(queue, XAP_A_THREAD_DONE, result); } No need to really *deal* with this; plugins that just need to read a file in an RT safe manner and that kind of stuff will still work. > 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... Right. I think it can be kept very simple for now. There are basically two kinds of background jobs; "do some work and end", and "keep working until I tell you to stop". The latter implies communication, synchronization and stuff, and takes a "real" API to be of much use. The former though, should require little more than what I suggested above, and will *work* with even the simplest hosts, although you'll need a proper RT host for that full, glitch free experience. [...] > 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. Reminds a whole lot of my background. Windoze music software and Windoze itself was getting on my nerves for a good while, until I came in touch with Linux. I started hacking stuff on Windoze as well, but dropped it when I realized it was just not worth the effort - lightyears away from real time. (This was 95 and NT...) I'm still haing trouble focusing on one project for very long, but at least, there's Kobo Deluxe and Audiality. Two projects that are well beyond the "hack 5 weeks without seeing anything" stage. I guess I'll dropp back to music for longer and longer periods when I can work entirely on Linux - but hey, then I'll be able to fix anything that's getting on my nerves! :-) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---