Hi,

<quote>
Is there someone who's in charge?  Who are the core developers?  How
do decisions
get made?
</quote>
David Bolton's post sums up the situation very well. Werner is still the
one writing most of the code. I'm merging most of the pull requests.
In general, there are not many decisions to be made because most of the
design work is done by Werner. In the rare cases, where decisions are
needed, they are mostly done on the code itself, not on an extensive design
documentation.


Regarding your proposal, my opinion is very close to the one expressed by
Marc Sabatella.
MuseScore is first and foremost used to create sheet music. Werner and I
want to spend our time on the topics that matters for most users. Users
enjoy the fact that MuseScore can play the music out of the box. Most of
them would be happy if the audio rendering would be better (mainly in the
details, more playable elements in particular accelerando, crescendo on a
single note, attack for woodwinds etc...) but they don't want to configure
anything more. The vast majority of users don't use Zerberus, or even load
multiple SF2 in Fluid. Even less users are using Jack MIDI and VSTi. Also,
we like to spend our development time on features we use... Personally, I
don't own or use any commercial sample libraries or VSTi (except Pianoteq)

That being said, we did implement multi SF2 support, Zerberus and the
ability to talk to external synths via Jack MIDI and I would be very happy
if these features become easier to use, especially if it doesn't make it
less easy for the average user to just hear some sound. I would be even
happier if it makes the default sound better.

To the point now. Your proposal only tackle the tip of the iceberg. We can
put whatever XML config in place, with a shiny UI, all the parameters need
to be used at the lower level. Most of the actual changes will need to
happen in rendermidi.cpp. For example, changing dynamics from velocity to
expression or volume needs to be coded there. Any implementation work needs
to cover everything down to rendermidi.cpp.
So at this stage, I wouldn't care much about a possible OSC implementation
in far future or if we call a tag synthesizer/synthesiser...

If you want to move forward with your proposal, take one specific problem
(velocity/controller? send a controller on slur start/end or any other
one), implement a temporary xml format for a synth/instrument link (but
even an hardcoded switch in the code would be fine or now) and implement
the playback in rendermidi.cpp. When it works with GPO, let's see how we
can make it cleaner.
Putting it differently, I do not believe we should discuss right now a
whole XML format for synth definition or even think that a user could load
one because it will cost much time and effort for not much in the end.
Instead let's write some code and get familiar with the whole playback
chain in MuseScore and then gradually a synth definition format will
emerge. (and so in fact my whole post here is summarized in what I said 10
days ago :) show us some code.
https://musescore.org/en/node/104296#comment-468746)


One last thing. About SSO and Zerberus.
You can create a template with the instrument you want. Load the SFZ you
need (if it's not possible to load several SFZ at once, do file a feature
request and feel free to make a Pull Request), select the sound in the
mixer and then in synthesizer, save the configuration in the score file.
Save your score in the template folder and you are good to go. Next time
you need to use the exact same config, you should be able to load the MSCZ,
go to the synthesizer and press "load from score" and the score should be
setup with the sound you want.
And regarding "MuseScore just doesn't accept that brass instruments can
have multiple articulations". You can switch instrument anywhere in the
score, it's more or less what pizz/trem are doing. So you can create as
many articulations you want for brass or any other instrument. Sure, it
will create a new entry in the mixer... but it's possible by modifying
instruments.xml.

Hope it helps.
Feel free to ping me on IRC #musescore on freenode.net if you want to chat
about all this.

lasconic
------------------------------------------------------------------------------
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

Reply via email to