Hi, I understand where Peter is getting at, and I think I may be able to clarify things a little bit more, so that MuseScore core developers, should they see fit, may think thoroughly about his implementation.
What Peter wishes to implement is something called “soundset file”, or “dictionary file”. I know that commercial notation programs rely on these files to communicate with external devices (hardware/software synthesizers and samplers). When such devices are GM/GS/XG compatible, those files allow notation programs to tell the devices which program/bank to use and what MDI CC messages they should listen to. This is essentially what “instruments.xml” is used for in MuseScore, regarding fluidsynth and Zerberus, right? If MuseScore had MIDI actions already implemented, a user could write in the score (maybe as hidden objects) a series of incremental CC7, or CC11, values above a crescendo sign, and fluidsynth would read them accordingly and raise the sound volume for that instrument, thus creating the crescendo effect. How does fluidsynth know what CC7, or CC11 mean in terms of MIDI protocol? Because “instruments.xml” tells it what they are, acting as sound configuration (“soundset”) file. If playback devices are strictly GM/GS/XG compatible, than, as long as the software allows the user to directly input MIDI Messages (Actions) on the score, and the user knows the effect each MIDI CC has in playback, it is possible to achieve a greater degree of realism in playback, by using the notation software as if it was a sequencer (without it actually being one), regarding the possibility of sending MIDI CC messages to the playback devices to affect the sound. This is the approach that igevorse was trying to implement with his MIDI Action code. But when it comes to sample libraries and playback devices not GM/GS/XG compatible, they don’t recognize Program Changes (MIDI CC0) and don’t apply MIDI CCs in the same way as GM/GS/XG compatible ones. And there isn’t a standard for their use of MIDI CCs. With respect to sample libraries, each vendor/creator attributes functionalities to the various MIDI CCs according to their conveniences — although they might try not to alter too much the functionalities of the most common CCs (CC7, CC10, CC64, for instance). That’s way it is not possible to have a single “soundset file” for all sample libraries and external synthesizers. Now imagine a scenario where a MuseScore user employs 16 different third party libraries/synthesizers on 16 different tracks and wishes to input some MIDI Actions on the score (if this was already possible in MuseScore) to control playback. He would have to remember all the different Program Changes, Keyswitches and/or CC attributions for each library as he was writing those actions on the score, according to his needs. That’s where Peter’s approach, regarding the use of separate and more elaborate “soundset files”, would come in handy. If there was a separate “soundset file” for each library, describing how the various Program Changes, Keyswitches and/or CC attributions operated for that specific library, and the different articulations the library’s instrument patches allow, the user would just need to introduce text elements like “pizz.”, “arco”, “spicc.”, “col legno”, “cresc.”, or “dim.” and those would be translated by MuseScore — according to the information contained within the “soundset file” specified for that track — into a stream of MIDI Messages sent to the appropriate playback device loaded with the library, along with other regular MIDI Events needed for playback. Thus, the playback action of each library could be controlled by a separate “soundset file”, without the need for the user to tediously input numerous Keyswitches and CCs on the score, by hand, for each track with a different library. I guess that Peter’s idea of an abstraction layer relates to the possibility of allowing the future implementation of different communication protocols (like OSC), other than MIDI, to control playback devices, and also the possibility of addressing all playback devices, including the internal ones (fluidsynth and Zerberus) using a single and common function within the MuseScore’s structure, a function that reads each soundset file and translates them into a stream of MIDI Messages (correct me if I’m wrong here). Regarding the question of VSTi, it isn't being asked to turn MuseScore into a VSTi host, at this point. There are freely available software able to do that (in Windows, Mac and Linux [both with and without using wine]), allowing to use a VST plugin/sampler as a standalone external (MIDI) device. What is being asked is to allow the communication with such external devices (via Jack MIDI, I suppose), to control/manipulate a specific software/hardware synthesizer, or a specific sample library loaded into that plugin/sampler. Regarding the latter, as I mentioned above, the idea isn’t to control the sampler itself, but rather to tell the sampler how to control the library loaded into it: which samples to activate, what control changes to perform, in which MIDI port/channel or instrument patch, etc. Finally with respect sample libraries and articulations, to my knowledge, there aren't — yet(!) — any freely available sample libraries using multiple articulations (other than the usual sustain/staccato/pizzicato ones), but there are some SFZ (open format) based commercial libraries, like GPO4/5, which allow the user to access the SFZ instrument definition files, which define how the samples for a particular instrument patch should be played. In such libraries, the licensing for samples is still restricted (no modification, duplication, releasing, etc.), but the instrument definition settings may be changed by the user, as long as he knows what he's doing. So, those files can be viewed, analyzed, studied, changed and saved. Of course, Zerberus isn't able to load such libraries, but MuseScore should be able to communicate with external samplers loaded with commercial or freeware sample libraries alike. Best regards! -- View this message in context: http://dev-list.musescore.org/Playback-abstraction-layer-tp7579762p7579786.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
