Re: [linux-audio-dev] PTAF link and comments

WELCOME! I'm excited to see one of the more well-known plugin companies chiming in. I'm also excited that XAP and PTAF are not too far from each other. Hopefully we can reconcile our efforts and just have one API, and not two very similar ones. We store all the metadata external to the plugin. Getting metadata is a pointer to a plugin-owned struct. You only instantiate when you want to use a plugin. This leads us to have a lot of metadata, or a static meta-data query method. We currently have extensive structs. I'm questioning whether having a simpler query based system may be easier. I don't like the idea that you have to instantiate to query, though. hmm, I'm not sure I buy this - how does this matter? "host"? Defining a proper cross-platform GUI system will be fun. I see four levels of UI from plugins: 1) none - host can autogenerate from hints 2) layout - plugin provides XML or something suggesting it's UI, host draws it 3) graphics+layout - plugin provides XML or something as well as graphics - host is responsible for animating according to plugin spec 4) total - plugin provides binary UI code (possibly bytecode or lib calls) Actually, I prefer this situation to appear broken - you should NOT have interleaved control sources. Tokens need to be forecefully grabbed with that model. If I see a knob that is turning via some old automation, I should be able to grab it in the UI and take over. It is not clear to me, however, whether the host should remember that and leave control with the highest prio controller, or just make it temporary. This needs more thought. It may not be the domain of the API at all, but the host. I think that if you want to push a true cross platform API it should be pure C. The spec should not dictate ABI, either. The ABI is an articat of the platform. If my platform uses 32 registers to pass C function arguments, it is already binary imcompatible with your PC :) I agree that it is simplest for host developers. Do we want to make life simpler for host developers or plugin developers. I've advocated staying simple in the past on this subject. I could be convinced that a slimmed down system that was somewhat in the middle of our two proposals is best. I don't like using variable arguments in an API, however. plug->run_func(enum cmd func, ...); That scares me as a source for big bad runtime bugs, and just passing a void pointer doesn't naturally handle all cases. but by writing it in C++, you require a C++ compiler. Actually, I don't see much point in anything complicated. Localization should be separated from the plugin. I much prefer something like getttext(). The plugin provides keys (generally an english string) and the key is looked up for translations. It requires very simple processing by the host, and frees the plugin from worrying about it. UTF8 is fine because it tastes like ASCII to me, so I don't have to deal with it. I don't know if it is useful to spec UTF8 you'll get a lot of arguments about that on this list - linux people tend to have a 486 or pentium stashed somewhere. :) This I might buy. I'm really unsure. As a producing company of several respected plugins, I'll have to take your word for this. I am a big fan of simplicity. I'm leaning more towards the idea that if a plugin can do in-place processing, it may be asked to, but it should have the ability to specifiy for itself. Agreed - but they also attach value to efficient software. I think this is at MOST a suggestion to host developers. It should not be part of the API in any way. We've just spoken of calling the process() function with a duration of 0 samples. Events are then processed immediately, and no second API is needed. Unlike some people here (I haven't gotten into it yet with them :) I think ramping is an add-on to discrete values. I think all controls should support discrete SET operations, and RAMP opertaions are an optional extension that the host can use IFF the control says it supports it. Internally, all SET operations should be ramped, even if it is a fast linear ramp. Right and wrong. We've agreed that a RAMP operation is a target and duration, but that does not imply a stop. A control must reach the target at (or slightly before) the end-point. Beyond that, it is undefined. It may keep ramping, or stop, or whatever. The host should send a SET event (which cancels any pending ramps) to stop a ramp. Now it may instead be useful to just say that ramping WILL continue, and get rid of the undefined BS. A VVID is a virtual voice ID. It is an unsigned int. It is owned by the host and is global to a plugin (and optionally to the host, but plugins don't care). When a host wants to turn a voice on, it tells the plugin to allocate a VVID. The plugin does what it needs to do to allocate space. The host can then send events for that VVID. The plugin does NOT make noise for the VVID yet, until a voice-on. When the host has sent all the initial values it wants, it sends an event to the VOICE control, saying VOICE_ON. The plugin can then make sound. This gives the plugin a chance to have parameters for a voice BEFORE starting it. Which is good for things like init-velocity, etc. The host sends VOICE_OFF to end the voice, but the VVID is still alive. The voice enters the release phase, and events are still tracked (as in your model, I'm glad to see). When the voice is done, the host can de-allocate the VVID. Same as your model. Where we differ is these two things. Once a VOICE_OFF has been delivered, the host may call VOICE_ON again. This re-using of a VVID provides a way to do closer MIDI emulation, as well as portamento, possibly. The second difference is that a VVID can be de-allocated without VOICE_OFF. A simple step-sequencer might do this. Send initial parameters and then 'detach' from the voice. ick - if there is a balanced (or even unbalanced) spectrum of values, center it at 0, please :) this has been well explained in another message :) I rather like normalized values. I've been contemplating this problem, myself. I don't like having to call normalize functions for every translation, though. Can the translation overhead be minimized? I actually have this in my own notes for XAP - an optional way for the plugin to save 'extra stuff' with a preset or document. This is getting fun! Hopefully my DSL will be up soon, so my latency won't be so high. Tim