Tim Hockin wrote:
On Fri, Nov 07, 2003 at 07:13:17PM -0700, eric wrote:I believe it's possible to separate the basic plugin spec into different layers, including one that handles things like port datatypes, memory buffers, whatever. So we start with the generic spec, and create an audio datatype for GMPI V1, and then when video is added in 2, 3, or 4, we can stay pretty much backwards-compatible with v1. This will also help resolve potential GMPI version transition issues, allowing smooth transitions similar to w3 standard versions.
OMS native plugins. Please have a look. I've raised a few points which may or may not have been discussed on the list, but I think they are important (at least to me), and should be given some consideration.
I'm reading it now.
Re: your assertion that any DSP (including video) should be allowed
GMPI V2. Or 3 or 4. We can't be everything to everyone. Our mandate is to do a Music/Audio plugin format. Certainly it would be nice to encompass video. Later. Maybe.
Re: NetworkingLet me clarify: It would be cool to keep multiple hosts in perfect sync over a network, and allow plugins on one system to communicate with plugins on another. I do NOT think that the networking details should be specifically addressed by plugin standard, but it should be fairly easy to create a network sync plugin that will bus clock and plugin data back and forth. This would allow render-farm-like functionality not for a single plugin, but to allow a single project to use many hundreds, or even thousands of plugins in a single rendering network. This would be especially useful in high-end studio productions, and a portable standard like GMPI could make it easy to create very powerful render farms on comodity hardware.
Distributed rendering does not always or necessarily make sense. It is very dependant on the graph structure. To date, we have assumed that anything outside the local graph is outside GMPI. What exactly are your proposed requirements in this area?
Re: thin layers of architectureFor example, a plugin description language (like one I've envisioned that I was calling the Open Media Plugin Language) could describe a host or plugin's capabilities, and list parameters and services. I envisioned that to work something like this:
Explain more what you want to see?
Re: NSPRGood stuff. However, we may still have to deal with technical issues such as timer granularity. I haven't tested it yet. At any rate, it could provide us a very good starting point, and the licensing is very flexible.
Thanks! Bookmarked.
Re: notifying CPU hungry pluginsI don't know.. this is just a requirement collection doc, not implementation details.. =) I figured if a plugin is using too much time, the host sends it a signal (via the standard event system, perhaps through a dedicated host/plugin communication parameter), and the plugin takes whatever measures the plugin developer deems necessary to fix the problem.. if the plugin continues to use too much time, the host developer can decide what they'd like to do about it. I don't know if we should dictate exactly what goes on, because the apropriate action might vary from one situation to another.
What is the mechanism you want to see, and what do you expect a plugin to do about it?
Re: TimeWhich specific requirement needs more explanation? I thought I'd been fairly clear. Anyway, I think that all of my requirements can be satisfied with the currently proposed solutions:
Can you explain more? I'm not clear..
Re: ParametersWhat effort? Do you agree that parameter types should be extensible?
I agree more or less about using generic parameters for many things. I don't know that making it totally extensible is worth the effort.
Can you describe a specific problem you are envisioning? Maybe we're just not speaking the same language yet. =)Over categorization is bad.
In this context, that's exactly what I mean.A plugin that provides the well-known parameters for a particular interface (say the instrument interface) can be said to implement that interface. I think that is what you mean by thin layers.
I would agree, but how does a plugin announce it's capabilities? =) I suggest the capabilities declarition in the plugin description spec (another thin layer). =)However, I don't think I want to see a plugin saying "I am an instrument". The fact that a plugin implements the instrument API should be sufficient.
Exactly what I propose.That said, if an API is sufficiently complex, maybe it is easier to provide a list of interfaces the plugin implements? Anyone have comments?
Re: save/restore stateWave-tables, for instance, but plugin developers may want to save stuff that we can't predict, and we should allow them to. Perhaps this should not be implemented via the stata mechanism that was proposed, but I know that at a minimum, I'd like to be able to store my currently loaded wave-table set for a sampler, and my current sequence for things like little beat-sequencers. These things are state-related, and not tied to parameter settings, from where I'm sitting.
Can you provide concrete examples of what you need to save besides parameters?
re: fully extensible parameter typesI'm not sure it's required in this particular situation, but if it's not implemented in the spec, and somebody needs something different, we're going to have hosts and plugin developers creating cheap hacks to get arround my lack of vision. IMO, that's worse than the added complexity at an early stage, as long as we still satisfy the #1 requirement: keep it simple. =) When I start doing test implementations, I'll let you know if I come up with a brilliant mechanism to make it happen. ;)
We have to balance simplicity vs extensibility. Convince me this level of complexity is needed.
No worries. I'm doing this work anyway.. I might as well share.Thanks for the doc! I've taken a number of notes from it, and if we can answer these questions, I'll have more.
-- ~ <http://www.dilvie.com/>
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
