I can only speak for myself here, as one of many contributors to MuseScore.
I personally find it hard to get excited about a change that will only
benefit users who are using JACK and external synthesizers. That's
probably less than 1% (most likely *much* less than 1%) of users. I'd be
far more interested in improvement that benefit everyone - which is to say,
improvements that benefit people using the built-in synthesizer. It sounds
like your proposed changes won't help most people. That's not to say they
aren't worth trying to implement, but I do think a design that benefits
everyone, not just a very small minority, would be more likely to generate
interest among the other developers. And given that ultimately these
issues *are* worth addressing for everyone, it seems to me it would be a
bad idea to have two *different* solutions - one solution for people using
external synthesizers with special proprietary requirements, another
solution for everyone else. Better, it seems to me, to have one unified
design that takes all needs into account, even if perhaps the
*implementation* still ends up being a bit different for bthe built-in
syhnthesizers versus external ones.
Again, that's my personal opinion. It's the core developers who ultimately
have the final say on such matters.
Marc
On Sun, Apr 10, 2016 at 10:12 AM pedroseq <th...@portugalmail.pt> wrote:
> 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
> <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
>
------------------------------------------------------------------------------
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
