https://github.com/musescore/MuseScore/pull/1083 is about assigning
channels/ports to instruments.
This is definitely possible in master if you enable it in Preferences >
Score, you can change channels/ports in the Mixer.
lasconic.
2016-04-11 16:59 GMT+02:00 Marc Sabatella <[email protected]>:
> Michael - obviously I don't know the specifics of what you have in mind,
> but I *can* say that this is indeed the sort of thing I mean when I say if
> there is to be a grand re-design, it should give thought to how it could
> fit within the current model of an internal syntehsizer playng a soundfont
> we provide to everyone. I don't know if there are any standards for how a
> soundfont might be organized to support the kinds of things you have in
> mind, but if so, we should follow it, if not, we should propose one and
> then it's larger in scope than MuseScore itself and that's fine too. But
> these are the questions we need to be discussing, IMHO, and to me, and to
> me, that's why maybe the response to Peter's initial proposal hasn't
> exactly been "that sounds great, go for it". I think it's premature to
> decide on a design without looking at how it might work for the "out of the
> box" case, and also, as lasconic, without looking at what is involved in
> actually implementing any of that.
>
> So on the whole, I'm quite in favor of this sort of work - I just want to
> see it proceed in a way that really works for everyone.
>
> Another comment about brass and articulations - the way we handle trumept
> (open/normal versus muted" is exactly the same as how string pizz versus
> arco is handled: program changes configured into iinstruments.xml. So as
> lasconic mentioned, it's already quite possible to make brass use different
> attacks for different contexts using the exact same mechanisms that is used
> for strings - you just need to configure instruments.xml accordingly, so it
> doesn't *just* have channels for normal versus muted, but also includes
> another channel for slur, etc. *And* have support for those articulations
> in the underlying soundfont. So if we thought the right way to implement
> slurred playback for trumpet was to have separate samples for tongued and
> slurred assigned to different MIDI program numbers, that's almost trivially
> easy ("almost"). But I gather that using program changes is not
> necessarily the way to go about this, and that's where, I assume, the
> larger design comes in - specifying exactly how each articulation is to be
> handled for a specific synth. So that *will* need to happen - but the
> details will depend on how we decide to solve that problem for the
> out-of-the-box case.
>
> Marc
>
> On Mon, Apr 11, 2016 at 8:15 AM Lasconic <[email protected]> wrote:
>
>> Ok. So I read several time about Igevorse's work on MidiAction dialogue
>> but I don't think there is any work to merge currently.
>> There are no open PR for it
>> https://github.com/musescore/MuseScore/pulls?utf8=%E2%9C%93&q=is%3Apr+igevorse+
>> So I think nothing has been done. Did I miss something?
>>
>> In any case, it should already be possible to create instruments.xml file
>> to send CC messages at any point of the score to an external or internal
>> synth, even in MuseScore 2.0.3. Anyone tried it already?
>>
>> lasconic
>>
>> 2016-04-11 16:03 GMT+02:00 ChurchOrganist <
>> [email protected]>:
>>
>>> Just a note from the sound design aspect of this.
>>>
>>> In order to implement what Peter is trying to do for everyone the default
>>> soundfont would have to be modified extensively in order to have the
>>> multi-velocity splits and other bells and whistles available to be acted
>>> on.
>>>
>>> With Igevorse's work on MidiAction dialogue merged with the rest of the
>>> code
>>> this would be perfectly possible without a huge superset of XML based
>>> configuration.
>>>
>>> As FluidSynth is based on the SF2 specification it is at it's heart a
>>> MIDI
>>> synth. Although MuseScore can load soundfonts into it and specify the
>>> Ports
>>> and Channels it receives on it still has to send MIDI messages to get
>>> FluidSynth to play the notes.
>>>
>>> All synths are like this whether they are hardware, VST3, or SFZ- they
>>> are
>>> black boxes into which you send MIDI messages (or maybe in some cases
>>> OSC)
>>> which then do their thing inside them to produce audio.
>>>
>>> Speaking from my experience as a backing track programmer I identify
>>> completely Luis Garrido's comment about "Score Editors Are Not
>>> Sequencers."
>>> He described my workflow pretty accurately in that initial scoring of
>>> orchestral backing tracks would be done in Finale (I hadn't yet
>>> discovered
>>> MuseScore at the time) and then transferred via MIDI file to my DAW where
>>> finishing of the audio would take place.
>>>
>>> Even with the most sophisticated soundset file it is impossible to
>>> produce
>>> audio capable of going for mastering without further tweaking in a DAW.
>>> For
>>> example - the order the notes are played in a guitar chord are different
>>> depending on whether the strum is up or down, and this has a subtle
>>> effect
>>> on a guitar part, which will sound wrong if it is not rendered like this
>>> from the MIDI file. There are many minutiae like this which have to be
>>> taken
>>> when producing something more than just demo standard.
>>>
>>> If the community wish to have a default soundfont like this, then I am
>>> quite
>>> willing to begin to implement it. Indeed it could become an important
>>> part
>>> of music and audio FOSS, but it is by no means a trivial task, and could
>>> require funding to get some of the samples recorded - I have an idea
>>> about
>>> that btw which is more suited to discussion in the open forum rather than
>>> the developer list, but I need to do a little more work before I release
>>> the
>>> idea into the public domain.
>>>
>>> So, I suppose the question is: "Would there be enough interest from
>>> MuseScore's general user base to warrant the enormous commitment in
>>> terms of
>>> time and resources to produce such a soundfont?"
>>>
>>> I do actually support Peter's idea btw despite my so far critical view of
>>> it. I'm just not convinced that his implementation proposal is on a firm
>>> enough footing regarding the basics of communicating with modern synths.
>>>
>>> Regards
>>> Michael
>>>
>>>
>>>
>>> -----
>>> Regards
>>> Michael
>>> --
>>> View this message in context:
>>> http://dev-list.musescore.org/Playback-abstraction-layer-tp7579762p7579800.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/%0Dgampad/clk?id=1444514301&iu=/ca-pub-7940484522588532>
>>> _______________________________________________
>>> Mscore-developer mailing list
>>> [email protected]
>>> 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
>> <http://pubads.g.doubleclick.net/gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532>
>> _______________________________________________
>> Mscore-developer mailing list
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
