On Tuesday 27 Apr 2004 11:24 pm, Jens M Andreasen wrote: > I find the following to be an overcomplication. First you have: > | <base path>/program > | Make a program change on the plugin. Takes two int arguments, > | for bank and program number. (required method) > > .. and then just after: > | <base path>/midi > | Send an arbitrary MIDI event to the plugin. Takes a four-byte > | MIDI string. ... > > .. which covers program change very nicely and even covers > multitimbral synths receiving on several channels (which is for > some reason not covered by the required method?)
We should have been a bit more explicit about this. The intention is that a DSSI synth only has one channel. It should ignore the channel on incoming MIDI events. If you want more than one channel, you instantiate more than one synth: the host does the routing and the result should be the same. I would assume that the plugin developer was sensible enough to share any shareable data behind the scenes. As Steve points out, the /midi method is optional, and it's really only intended for sending test tones. The host uses a specific API to query and select programs on the synth rather than use MIDI program changes, because it wants to know about the available set of programs and what they're called: given that the host isn't using MIDI program change, it makes sense that the UI shouldn't either. We have generally tried to reduce the number of cases where the plugin may end up with more than one code path to achieve the same result. Like most of the decisions in a design like this, you can argue this either way. We reckoned it was a bit simpler to write and understand the plugins this way, with no visible difference to the user. Chris
