Ok, here are my thoughts on a possible implementation. This isn't intended
as a finished design, just a starting point for discussion.
Let's start with the file format for describing synthesizers. I propose
using an XML based format. The root tag would be <Synthesizer type="midi">.
Or alternatively, type="fluid" or type="zerberus". It could be extended in
the future to support other technologies, like type="osc" or type="vst".
The <Synthesizer> tag would contain some number of <Instrument> tags, and
each of those could optionally contain some number of <Articulation> tags:
<Synthesizer type="midi">
<Instrument id="violin">
<Articulation name="legato">
...
</Articulation>
...
</Instrument>
...
</Synthesizer>
The instrument id must match the corresponding one in instruments.xml. For
type="fluid" or type="zerberus", there's not a lot more than that needed.
It just needs to specify the soundfont and sound for each one. So for the
rest of this I'll focus on midi, which is more complicated.
Each <Instrument> and <Articulation> would contain an <Activate> tag and
optionally a <Deactivate> tag. Those would specify the midi commands to
send when switching to or from that instrument or articulation.
There would be several other tags defining the midi commands for performing
certain actions: <SetDynamics>, <BeginSlur>, <EndSlur>, and possibly others.
Those could appear at any level of the file. If the current articulation
specifies it, that gets used. If not, it falls back to the instrument's
definition. And if that doesn't define it either, it falls back to the
definition in the root <Synthesizer> tag.
Next let's consider how those tags define midi commands. Each one contains
a list of commands. Those would include all the standard things you'd
expect: <NoteOn>, <NoteOff>, <ControlChange>, <ProgramChange>, etc. There
would also be tags for <NoteOnVelocity> and <NoteOffVelocity>. Those don't
send any commands themselves, but they set the velocity to be used for later
notes.
For example, an instrument that bases dynamics on velocity would specify
<SetDynamics>
<NoteOnVelocity>value</NoteOnVelocity>
</SetDynamics>
One that bases dynamics on the expression controller would specify
<SetDynamics>
<ControlChange id="11">value</ControlChange>
</SetDynamics>
"value" is a special keyword that means to use whatever value is being set
for the dynamics. It can also specify a particular number. For example:
<Articulation name="marcato">
<Activate>
<NoteOnVelocity>127</NoteOnVelocity>
</Activate>
</Articulation>
The file would also need a way to specify percussion kits. That could be
done with a <Kit> tag. It would contain many of the same tags as
<Instrument>: <Activate>, <SetDynamics>, etc. It would also contain a list
of the instruments contained in the kit, and the notes for each one.
Ok, now let's consider how the user interface for this would work. The user
would be able to load any number of these files. I'll call them
"synthesizer configurations" (not necessarily a great name, but it will do
for the moment). It will clearly require minor changes to several windows,
including Synthesizer, Pianoroll Editor, and Staff Text Properties. But the
most important changes will be to the Mixer window.
Currently, it includes a menu for each instrument where you can select any
sound from any loaded soundfont. I suggest a simple change to those menus:
add entries (at the very top, separated from the rest of the list by a
divider, selected by default) listing all loaded configurations that include
that instrument. You could still override it by choosing a different sound,
but by default it would play that instrument in whatever way was defined by
the configuration.
This design would also involve a larger change. Currently, the mixer has a
separate entry for every articulation of every instrument, and takes up a
separate midi channel for each one. Clearly that can't scale to large
numbers of articulations, and even with the current limited set it's
problematic. Create a standard five part string section, and you've already
used up 15 of the 16 available midi channels! So I would change it to have
only a single line and use only a single midi channel for each instrument.
Changing between articulations would be done however it's specified in the
configuration file. I think this is a much better approach, but it does
create issues for backward compatibility. I don't know whether that's
considered a problem or not.
--
View this message in context:
http://dev-list.musescore.org/Playback-abstraction-layer-tp7579762p7579763.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
