[gmpi] Re: Requirements
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 14 Nov 2003 12:44:25 -0800
On Fri, Nov 14, 2003 at 10:38:36AM +0100, Vincent Burel wrote:
> 1.3 : definition of "Control" !?
ok.
> REQ 3
> for the processing function and internal parameters of the algorythm, it
> make sens... For the rest of the plug-in, i'm not really agree.
If you use platform specifics inside your plugin, your plugin is harder to
port. Of course, it is your plugin, do whatever you want. All it says is
that the API must use standard type names.
> REQ 8 : what does it means ?
I expanded this
> REQ 9 : redondancy with 1.3
1.3 is an overview, this states the requirement that it must be 0 or more,
and is arbitrary.
> REQ 14 is not according REQ 15
> if the GMPI does not provide specific mechanism for managing real time , it
> has to explain strictly WHICH function can be called WHEN. For example to
> forbid the call to Create/Destroy/ChangeFormat during processing function or
> with different thread can be one of the strict recommandation of the GMPI
We don't provide realtime guarantees. We can't unless we're on an RTOS.
I'm sure there will be rules as to what the host should or should not do in
realtime threads. I'm not clear on what you take issue with?
> REQ 17: so we have to provide a way to let the processing function get
> parameters or dats comming from different PIN or PORT (whatever the name)
> coming from GUI, remote surface, autmation sequencer etc..
That is explicitly required later, it's just the host's problem.
> REQ 20 : it should be interesting that the host can fixe a granularity to
> let us optimize many algorithme. for example a garnularity of 8 or 16 is
> already a good point to make big optimization. (but ,never 0, it will avoid
> us to make a useless test in all the processing function of all plug-in)
Hrrm, do I need to ammend it to say that the host will never call process
for 0 frames?
> REQ 23,24 : not clear.
Intentionally. I hate the idea and I want it to go away. If it doesn't go
away, I expect the people who want profiles and who want non-FPU support to
step-up and clarify.
> REQ 27 : the host can provide both absolute and relative time, this can
> avoid to the different plug-in to make a redondant substraction.
See the FIXME - this needs to be resolved.
> REQ 29 : ramped !? (lexic)
I've expanded on that.
> REQ 36 : host provide all time format in the same time, why losing time in
> converting in plug-in.
It's just a requirment. It might be that the host sends all the time
formats at the same time. Doesn't matter now.
> 3.11 also parameters include a lock/unlock or touch/release field.
Explain more? Is this the gesture-start gesture end idea? We need clarity
on what the requirment is and some acceptable explanantion.
> REQ 52 : what does it means ?
I've expanded on it.
> REQ 55 : if the host want to map itself MIDI input into automated parameters
> , i'm not against , buy i want to be able to receive MIDI data for example
> without HOST mapping.
I knew MIDI might start fights. I don't want to see MIDI inside the GMPI
graph.
> REQ 63 : what is that !?
I've expanded on that
> REQ 69 : well , this is interesting but this can make some stuff more
> complicated ...
it's already more or less solved, I think
> REQ 70 : to do what !?
Make management easier. I guess I don't care TOO much on this one, but no
one seemed to disagree when we discussed it last week. Anyone else want to
weigh in?
> REQ 71 : non sens !
Several people indicated this as a requirement. I can re-word it so that
your plugins require registry cruft. The point is that the simplest
plugin installs by copying. As with VST.
Installing a GMPI plugin must be possible by simply copying the plugin
file to a directory. Nothing more is required. Some plugin vendors
may require additional actions for their plugins.
Better?
> REQ 72 : why going against the system !?
Eh? This is a REQUIREMENT for UNIX systems. Users are non-privileged.
> REQ 73 : it means that all the plug-in of every company can be in the same
> directory, this is not acceptable.
If the user wants to do that, why is it not acceptable?
> WHERE IS THE REQ TALKING ABOUT A UNIQ IDENT TO DEFINE THE PLUG-IN !????
later.
> REQ 81 : but mustn't forbid or bore it by a bad organization.
All this says is that we don't know what the requirements are. If you do,
or if anyone knows what the plugin API needs to do for copy protection, let
us know! I am not against supporting it, I just don't know what it needs
> REQ 82,83 : don't understand .
Internationalization? Running a plugin so it displays in French, German,
English, Japanese, etc. All from the same binary.
Great feedback. I took a number of notes. There are a few questions in
here that we need to decide before I merge them in:
Do we need a req for the control gesture idea? What is the req?
Should we dump the idea that plugins are bundled together into a single
file? I still like it, but I don't care THAT much.
Should we note that the hosts never calls process for 0 sample frames?
----------------------------------------------------------------------
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
Other related posts:
