Crescendo/Diminuendo One Note

• Jan 9, 2013 - 17:41

I do have the plug-in. It works well, but it's not possible to make the Crescendo/Diminuendo solely on one string note so as to make the bow push softer little by little. A very basic and important thing.


Comments

That can't be done via a plugin, or indeed, by any means in MuseScore currently. It requires use of the Volume controller in MIDI, which MuseScore doesn't use. WOuld be a nice enahcnement someday, along with things like the legato controller for slurs, playback support for more articulations, etc. But meanwhile, do keep in mind that playback features are definitely secondary in importance for a notation program and thus lower in priority.

In reply to by Marc Sabatella

I'm no programmer, but couldn't the plugin supposedly control the mixer during playback, and make the volume raise/drop where Crescendo/Diminuendo show up? I know this might be unprofessional to use the mixer as such, but it could make an alternate solution until further arrangements are done at Musescore 2.0.

In reply to by HolyEyE

No, there is simply no way for the plugin to access anything have to do with *volume*. All it can do is access *note velocity*, which normally controls the volume at which a note *starts*. The only way to control volume after a note starts is using the MIDI volume controller, and MuseScore just does not provide a way to access that. Nor would I expect any such major changes to the playback system to come in 2.0 - it's probably a much longer ways off. The playback facilities of MuseScore are really just there to give you a basic idea of how your score sounds. If you really care about such dubtle details as dynamic changes within individual notes, your best bet is to export your score as MIDI and then import that into a program that specializes in playback to the same degree that MuseScore specializes in notation, and use that other program to tweak those details manually.

In reply to by HolyEyE

I posted in another thread of yours, HolyEye, about using Linuxsampler as a backend for Musescore, and yes, it is possible to have crescendo, decrescendo, slides, etc. using the proper samples. It can be done if you use Linuxsampler to produce the sounds, but can't be done with the default Fluidsynth engine that comes with Musescore. I am creating an orchestra in SFZ format for use with Linuxsampler and it will include a host of articulations including crescendo and decrescendo.

In reply to by AnthonyDeaton

I apologize, I haven't seen your comment on my last thread. I just read it now and listened to the two mp3s on your site, it's quite a change. I've tried to put a SFZ before, and stopped middle way through, because I didn't know it had better quality than SF2. I'll look into your SFZ once you finish it, and hopefully my old computer will be strong enough to use it. Also, thanks for the hard work.

In reply to by HolyEyE

It's not that SFZ is inherently better than SF2, or even that Linuxsampler is inherently better than Fluidsynth - it's just that there don't happen to be any SF2's around that are as good as the best SFZ's, because for whatever reason, people are not actively developing SF2's much any more. But I suspect if someone *were* to produce an SF2 version of any given SFZ, and it would oroibably sound more or less the same, and be less work, since you wouldn't need to mess with installing and configuring Linuxsampler and Jack just to get it to work.

See the //musescore.org/en/forum/776 forum for discussion of an effort to develop a series of SF2 soundfonts that should rival any SFZ.

In reply to by Marc Sabatella

I came to this forum to help enlighten people about the use of Linuxsampler and this has turned out to be a disaster. This will be my last post on the Musescore Forum.

Yes, SFZ is inherently better than SF2 as it is much more modern and supports things such as Round Robin. It would take too long to list all the advantages, and yes Linuxsampler is superior to Fluidsynth in a multitude of ways also. Marc, if you really want to help people you need to quit spreading false information.

Yes, for a regular sustain sample it can be coded in SF2 or SFZ and achieve the same sound; however, that it where the similarity ends. SFZ has a plethora of abilities that SF2 does not, as SF2 is a dead format that is no longer actively developed so no new features have been added for some time.

The Fluidsynth team has been talking of adding SFZ support for some time but has yet not come to fruition.

In reply to by AnthonyDeaton

I am not sure why you think your posts have been a disaster. I do hope you continue to participate. I was not aware of the advantages of SFZ, and still don't quite understand what you are saying. So feel free to help me here.

I guess, though, in saying the issue isn't the superiority of SFZ, I mean, there are no advantages I am aware *that MuseScore is capable of taking advantage of*. That is, the specific things you mentioned like different articulation samples, MuseScore simply does not use. Sure, it could be modified to switch channels to achieve different articulations - but then, could it not be done with SF2 too? If not, then I do think it would be most helpful if you could explain further.

Said another way: my impression is that the soundfont format itself isn't the limiting factor to better playback in MuseScore. It's MuseScore itself - it needs to have a better way of dealing with things like articulations, expression controllers, etc. Again as far as I know, you could replace Fluidsynth with the most advanced sampler in the world, and MuseScore *still* wouldn't know how to make it play a slur. Please correct me if I am wrong. It is not my intent to spread misinformation.

In reply to by Marc Sabatella

I really didn't want to respond again, but I can't refuse when someone honestly asks for help in understanding, and for the record, I never said that my posts were a disaster but rather that the response to them has been a disaster. The first two responses to my initial post were by you and Church Organist. Church Organist immediately said that all my hours of work were useless and my library didn't sound any better than FluidR3 (a rude and ridiculous claim). You then immediately took up the mantle of telling me how I should be using SF2 and how it works just as well with Musescore, and have repeated that claim even after I had made it clear that this is not the case. That sure is some warm welcome to the forum, isn't it? By the way no one bothered to say welcome, did they? Why would I want to stay here?

I will, however, answer your question one more time. Yes, SFZ has several things implemented in the format that are impossible under SF2. Not to mention that SF2 is difficult to work with being a monolithic file that cannot be edited with a text editor. SFZ has the wav files in a separate sample folder and the SFZ itself is easily edited with a text editor. It has taken me literally hundreds of hours to code up all the articulations as well as modify the samples that need to be modified, and this amount of time would literally be quintupled trying to do it in SF2 (not to mention that many things simply could not be done). Usually only expensive professional libraries have such attention to detail and such a scope as what I am working on, so it is a little disheartening, to say the least, to be treated as poorly as I was when I arrived on the forum.

The honest truth is even some very simple things are impossible to do in SF2. For example there is a one shot loop mode in SFZ which allows the sample to be played in its entirety. This is very useful for drums, harps, etc to avoid the machine gun effect that is so prevalent in fast passages. Here is a sample of the concert harp that I am working on in my library. Both of these samples are being played directly from Musescore into Linuxsampler. So this is not a Musescore vs. Linuxsampler comparison. Linuxsampler can use sf2 as well as SFZ and GIGA. So here is the same score played by the same harp in SF2 and SFZ via Linuxsampler.

SF2 format http://www.fileswap.com/dl/CUrhdtO21x/

SFZ format http://www.fileswap.com/dl/vHJ75PIVm5/

You will hear a sound that kind of sounds like a maraca on the SF2, and that is where I used a free translator to translate the SFZ to SF2, so that is not what I am talking about. The annoying maraca sound is just to make you upgrade to the professional version, so please try to ignore that sound. What I am talking about is how unnatural the sustain (or I should say lack thereof) is in the SF2 version, as there is no one shot mode available. This will be especially noticeable on the quicker notes.

My library will also have round robin snare samples. These have true left hand and right hand hits that alternate in addition to the one shot mode to further reduce the machine gun effect that you get when playing quick notes. Round robin does not exist in SF2.

The keyswitching that I was referring to in Linuxsampler is where you map a note (usually beyond the range of the instrument) to act as a keyswitch to change articulations. This does not change the midi channel, rather it changes the given channel to the articulation that you want to use. You can then use another keyswitch to shift back or to another articulation. This is easily done with Musescore as you can set the note for the keyswitch to invisible so that it doesn't show up in your score.

It would take too long to keep explaining the advantages of SFZ, so I am done here, but I do hope that my post was helpful, and I hope it helps you to understand why there aren't many people who are making new libraries for SF2. The format is just too limited. As you heard, it literally ruins the sound of the harp runs in the above clip. SF2 is okay for simple instruments like piano, but for percussion, harp, etc. it is very limiting.

In reply to by AnthonyDeaton

I'm sorry you feel you were trreated poorly. That was certainly not my intent.

I understand now that SFZ provides some things that SF2 does not, but when I said that MuseScorte cannot take advantage of them, I still think that is largely true, ast least in the sense I meant. For instance, if the user needs to manually create an invisible note in order to trigger a keyswitch each time he wishes to use an articulation, that pretty much means 99% of users will never see the advntage of keyswitched articulations, wouldn't you agree? The bit about different handling of sustain is new information to me, and that does indeed sound like something that SFZ would provide for free.

But overall, I would say we have different goals here. Yours - if I may try to summarize - is to provide a facility that will produce the best results *if the user if willing to take the extrsa steps necessary in order to get those results*. This includes things like installing and configuring Linuxsampler and Jack as well as hacking one's score to trigger all the fancy SFZ features (invisible notes et al). Whereas my goal is to improve the playback a user can get with no special effort.

Does that give you a better idea of why the differences between SF2 anfd SFZ don't seem quite so relevant to me? It is certainly possible I am still misunderstanding, and something about what you are suggesting will have the reuslt of giving better playback with no effort on the part of the user, but I am not seeing it. So if I am mistaken, and something about what you are doing would allow a MuseScore user to get better playback with no special effort, please educate us. Even if it takes installing Linuxsampler and Jack, that's worth knowing, although again, very few users will go to the trouble of creating invisible notes to trigger articulation playback.

And this is why I was suggesting you make your soundfont available in SF2 form - so the basic samples at least can be available to users who do *not* plan to go to all the effort necessary to take full advantage of your work.

In reply to by Marc Sabatella

I said from the start that Linuxsampler and Qjackctl were involved. I never said this was for everyone. I answered a post by someone who asked a question and the original poster thanked me for the answer. I said from the start anyone who is interested in this method, I will try to help out when I get my library ready.

I named three things in my post that SFZ could do that SF2 could not. Two of them (round robin and one shot looping) require no work on the part of the user as that is done by the coding in the SFZ file. The only one that required anything on the part of the user was the invisible note. So are you honestly saying that a user who would be able to set up and configure Linuxsampler and Qjackctl will find it too difficult to enter a note then right click on it and select invisible. All you do is right click the note, and that is too difficult?

I am really not sure of what you mean by "handling of sustain is new information to me, and that does indeed sound like something that SFZ would provide for free." SFZ does provide it and it is free, so I will assume that you mean SF2. The final release of SF2 was version 2.4 which was released in 2005. It is not being actively developed now so newer features such as I have mentioned are not likely to be added. I don't see E-MU / ENSONIQ reviving it after nearly a decade of hiatus, but I guess you never know.

I could name several other things that SFZ can do that doesn't require any work of the user in Musescore but since I already mentioned two and they were completely dismissed, I doubt that a few more would matter. If you are content with SF2 then, by all means, use it and enjoy it, but to say it is the equal of SFZ even for use with Musescore is incorrect.

In reply to by AnthonyDeaton

Yes, I realize you made it clear - to those of us who have some familiarity with the issues involved - that your use of SFZ meant Linuxsampler and Jack would be involved. But I am not so sure this was clear to the person to whom I was responding.

And I am still unclear on how much *else* is required. If you are saying that somehow, placing just one invisible note in the score will somehow cause *all* articulations to play back using the dedicated samples, that would indeed be great, and not very onerous. But my assumption has been that you mean, you have to do this *each and every time* you wish to use an articulation - switching between samples much like one needs to do to switch between arco and pizz strings or open and muted strings. So for instance, if you have a passage that is quarter notes alternating between staccato and legato, would you not need an extra invisible note for every real note? This is an honest question - obviously, I am not familiar with how these work and have been working on assumptions, some of which are proving wrong - but others of which still seem to be valid.

Anyhow, keep in in mind, my initial post in this thread was not directed at you, and was not meant to be critical of your work in any way. The person to whom I was responding appeared to have gotten the mistaken impression that once you finished your SFZ, he would be able to just load it and find everything magically sounded better. And in particular, note the actual subject of this thread - the ability to have volume changes within a single note. Unless you have some tricks I don't know about, that's *still* not going to happen just by switching from Fluidsynth to Linuxsampler and/or SF2 to SFZ. Again, it's an inherent limitation in MuseScore's playback facility. I suppose using some sort of invisible note trick, you could perhaps make it happen?

So again, my concerns are twofold:

1) Merely setting up Linuxsampler and using a good SFZ will *not* fix many of the most significant playback limitations in MuseScore.

2) Of the improvements that are offered by going the Linuxsampler/SFZ route, some of the most significant requite a lot of work on the part of the user in order to take advantage of.

As far as I can tell, both of these statements remain true. That doesn't mean your work is not valid or worth doing or worth sharing. But I do think it important that people realize these two concerns mean the actual advantage for most of us is not going to be as great as one might hope.

As for my statement "that does indeed sound like something that SFZ would provide for free", that is exactly what I meant. That is, *if* one were to switch to from SF2 to SFZ, then this particular advantage is something that would happen automatically, without the need for hidden keyswitch notes or the like - as opposed to the other advantages you've stated, which would not benefit the MuseScore user that I can see unless he hacked his score accordingly.

So of all the advantages you have mentioned for SFZ, the sustain issue is one one that would perhaps make the biggest difference to the average user. "Round robin" is apparently another, but that is not a term I had heard in this context before yesterday, so I still don't have a sense of what that actually means here. I gather it is of benefit primarily for drum sounds? Seems like both of these advantges that conme "for free" with SFZ are mostly going to be apparent for percussion, then, or is that not a fair statement?

SO I hope you can see that this is a discussion worth having, and that no one is trying to attack you here - you don't need to be so defensive. You know the differences between SF2 and SFZ better than I, obviously, but I am trying to understand the *relevance* of those differences to the average MuseScore user. So if you would care to stop and think about it from this angle - the question of which of the advantages of SFZ would come "for free" (without requiring the user to do anything different except play via Jack/Linuxsampler), this could be very helpful.

In reply to by Marc Sabatella

A list of Advantages for the use of Linuxsampler with Musescore.

1. More sample choices. Linuxsampler can make use of sf2, sfz, and giga files. You can even mix/match the three formats. For instance, you can have and SF2 trumpet, a SFZ trombone, and a GIGA piano all working at the same time.

2. Layering. You can set multiple instruments on one channel. For instance, you can load up four individual french horns and set them all to the same channel so you can create your own horn section, if you only have solo instruments.

3. Better rendering. Some soundfonts don't work particularly well with Fluidsynth, yet all the soundfonts that I have had sound issues with in Fluid have worked well with Linuxsampler.

4. Better performance. If configured properly Linuxsamper is one of the most efficient samplers out there. I have Gigastudio 3 and GIGA files load faster and work better with much less CPU in Linuxsampler than in Gigastudio. The same is true of SF2.

A list of Disadvantages for the use of Linuxsampler with Musescore.

1. Not native. Has to be patched to Musescore via the Jack Audio Connection Kit.

2. GM soundfonts don't seem to work. You must have soundfonts of individual instuments to utilize SF2.

A list of Advantages for the use of SFZ vs. SF2 that require some work from the Musescore user.

1. Key switching. This is of course accomplished with the now infamous invisible note. However, the user can already make use of some articulations in certain instuments in Musescore. A midi volume controller does not create a true crescendo or dimuendo. Using a midi volume controller, especially since most SF2 are single velocity samples, only boosts or diminishes the volume of the given sample. If you were to play a recording of a violin on your home stereo, and you turned up the volume on the stereo when the violinist was playing pianissimo, it would not make you think the violin was being played fortissimo. All you hear is a soft tone being played at a loud volume, as the tone, articulation, vibrato, and bowing or the violist changes at different volumes. The same can be said of the trill. If Musescore were to add playback of a trill, it would be through the manipulation of the samples (either modulating the sample up to the next note of the scale or alternating between two samples). Thus the true articulations of the violinist would be lost, as the trill was "faked" just as the volume was "faked" in the above example. Here is an example from my library of a violin playing a trill and then a decrescendo on a sustained note. These are real samples of a real violinist performing these articulations. You will hear changes in vibrato, bow noise, et. al. This sample was accomplished using nothing outside of the channel changes (Pizzicato and Tremolo) supplied by Musescore. I don't have keyswitching set up yet, so I thought you would like to hear what is possible outside of any "hacks."

http://www.fileswap.com/dl/Ihoh4Gh5h/

Of course with keyswitching you are not limited to just picking three articulations, however, an extra note will have to be entered to trigger the key change and yes, it will have to be invisible not to appear in the score and it will have to appear above every note for which an articulation change is required.

Most professional notation software comes with a default library, such as Finale with Garritan Personal Orchestra, so they are able to add keyswitching into the notation editor itself. When you click on a trill in the notation editor it sends the keyswitch back to the sampler engine so the user can switch from one articulation to another with the simple click of a mouse. That is of course the ideal way for keyswitching to work with notation software. My invisible note was the only work-around that I could think of, and I truly don't find it as difficult or time consuming as using Musescore's current channel switching by way of staff text, as this certainly takes more time and involves more steps than the invisible note.

A list of Advantages for the use of SFZ vs. SF2 that require no work from the Musescore user.

1. One-shot loop mode. This has already been demonstrated in the harp clips above; however, here is another example this time with a Marimba playing 16th notes. The original samples were recorded in a concert hall so no reverb has been added by me. It will sound as though more reverb has been added to the SFZ because the notes will be allowed to sustain and the reverb tails will not be artificially removed.

SF2 --- http://www.fileswap.com/dl/zgP5j4zTrt/

SFZ --- http://www.fileswap.com/dl/g40DJFpfhW/

2. Round Robin. This is where more than one sample is used for a given note. Although it is useful for percussion it is, by all means, not limited to it. For example, you may have four samples of a violin playing C5, so you can set up a sequence in the SFZ file so that the sampler alternates through the four samples. A violinist will never truly articulate or vibrate a note exactly the same in a real performance, so when you play samples that only have one recording per note, it is obvious that you are using samples, because the note sounds exactly the same every time it is played. Say you have four quarter notes on C5 all in a row. The SFZ will cycle through the four samples so that no two notes are exactly alike. Round Robin is useful for percussion to help avoid the dreaded machine-gun effect. Below are two examples of the snare drum from my library which has true left hand and right hand samples. SF2 can only make use of one sample so it repeats one sample over and over. I have artificially panned the two samples in the SFZ to slightly left and right, so that you will hear that indeed two samples are being used and alternated. In the below clip, both round robin and one-shot loop mode are used in the SFZ.

SF2 --- http://www.fileswap.com/dl/EE4HN6Nfq/

SFZ --- http://www.fileswap.com/dl/tJAn7tsBcg/

3. Release Samples. You can add release samples in SFZ so that you can hear the instrument actually release the note. This is useful for such things as a jazz piano piece where as much realism as possible is desired. This is a subtle thing so you may have to turn up the volume or use headphones to hear this. I have scored out the classic jazz 6/9 chord with major 7th on top, and as the chord is released you will actually hear the release of the keys/hammers.

http://www.fileswap.com/dl/nkKoSXXn9/

4. Modulation, EQ and other advances. This is where it gets impossible to explain all the advantages of SFZ, as they are complex and too numerous to go into here. With sfz you get a filter unit, an amplifier, an EQ and a pair of effects sends, so the possibilities are incredibly numerous. For instance, you can set up velocity filtering where you can blend the transitions between velocity layers. My library will switch from the MF samples to FF samples at a velocity of 93. So at 92 the sampler is using the MF sample and at 93 it will use the FF sample. This can cause a "jolt" in the smoothness of a crescendoing or decrescendoing line. The filter can smooth out the transition so that it is barely perceptible that a change in samples has occured. EQ can be added to the samples if needed, and in this case the SFZ when translated to SF2 would sound completely different even for the basic sustain patches as all the equalization would be lost. As I have said, it is too difficult, time consuming, and technical to go into detail here, but the possibilities are astounding.

5. Probably the biggest advantage to SFZ is that it is a living, actively developed framework upon which new features are constantly added. There is no such hope for SF2. It is has been nearly a decade since it has been developed which, in computers, is a long time. Think about the computers and software of 10 years ago and compare those to today's. Then look at my number 4 above. There is nearly 10 years of advancement there and that is why it is too difficult to explain, especially to the layman.

After all this has been said, I will add a few key points. I have tried to avoid using some of the things available in SFZ that could not be translated, as I have expected that people may want my library in different formats. For example, I remastered the original samples in my library so that the samples themselves have been equalized rather than using the equalization available in SFZ, so that if my library were translated to SF2 the basic sound would remain relatively the same; however, there are a lot of things that have to be done within the SFZ as there is no other way to accomplish them and many things that SF2 simply cannot do not matter what provisions are made by me. The velocity filtering that I mentioned above will not be translatable, so the samples will still sound slightly different especially around the pivot points of velocity and the "jolt" mentioned above will still exist. Basically something will be lost in just about every instrument when translated to SF2. Some things will be highly noticeable such as in the harp, marimba, violin, and snare samples above, and some will be less noticeable.

A list of Advantages of SF2 format versus SFZ for the Musescore user.

1. Native.

* I will add that the Fluidsynth team is adding SFZ support to Fluidsynth, so at that point I would assume that SFZ will become native and all the above advantages of SFZ will be available to the Musescore user natively.

In reply to by AnthonyDeaton

Nice writeup - thanks! Will take a while to digest, but there's no hurry.

I'm curious about something: is it your impression that Fluidsynth itself is capable of taking advantage of these SFZ advantages - that it really is just a matter of asdding support for a new format - or would there need to be major upgrades to the "front" end of Fluidsynth to allow a user to take advantage of all this? Some I can see you'd get "for free" - like obviously, Fluidsynth would be capable of using a keyswitch if MuseScore were to send it, and round robin sounds like it is done completely at the SFZ level with no player support needed. And I was not aware SF2 did not use release samples - that does indeed seem a major shortcoming. But what about this capability of "stacking" samples to build your own horn section on a single channel - is that inherent in SFZ, or is that really a Linuxsampler feature thjat Fluidsynth may or may not choose to emulate?

And I am still not understanding your comments regarding crescendo on a single note. Yes, of course I realize that changing volume is not the same thing - if you take a sample of a note played softly and then simply turn up the gain, it will not sound like the note was actualoly played loudly, at least not for most acoustic instruments where the envelope and harmonic structure changes. But if the diminuendo in your psoted sample was not effected using the volume controller, how *is* it effected? That is, what is actually going on? Is there a seaprate sample of a musician playing a note with crescendo, another with diminuendo (or perhaps several samples, for different rates of crescendo/diminuendo) and you are using key switching to switch to that sample at the appropriate moment? Is there logic within Linuxsampler that figures out what the start volume should be, so it can use the ordinary sample for the attack then switch to the crescendo/diminuendo sample already positioned at the point where the volumes match? Or is it perhaps continuously replaying the basic sample at different velocities but with the attack portion removed?

In reply to by AnthonyDeaton

Anthony, I'm sorry that you felt my post was putting down your work.

That was not the intention.

My point in that post was the current limitations of the MuseScore playback engine made any improvements in the samples used irrelevant, and that you need to import MuseScore's results into a sequencer in order to improve the rendition. Unfortunately that obviously wasn't clear enough.

There was actually an improvement in the sample quality, but it was lost in the woodenness of MuseScore's inability to render articulations and the expressions controller.

I've just listened to the two Harp clips you mentioned, and there is indeed a remarkable difference between the two, particularly in the rapid passages.

Given that it is easy for MuseScore to drive LinuxSampler (I assume through Jack Control?) then we should be getting instructions on how to do it into the user documentation for version 2.

In reply to by ChurchOrganist

I am sorry that I haven't responded before now, but as you know I am new to the forum and was not aware of the way responses were posted. Your response was hiding down at the bottom for me and I hadn't seen it.

Everything's cool. I think we just got our signals crossed, as I was only trying to show how much better the sample quality was in my library in comparison to FluidR3 for the original poster. That was an unfinished piece that I am composing that I hadn't added any articulations into and I chose that piece on purpose, so that the original poster could hear how much better the samples were in my library without any extra articulations added. So I think we were just on different pages, and I assure you that I hold no animosity towards you and hope that you feel the same.

I also think that I should apologize to you, as I shouldn't have involved you in this thread. My real problem was/is with Marc's disrespectful attitude, and I made the poor decision to bring you into it. That was my mistake, and I am sorry.

As to your question about Linuxsampler, I really have no idea if they will add documentation in 2.0, as the Musescore team has been really quiet about Jack support, and they consider it to be in it's infancy; however, it does work well ever since 1.0. I'll try to make a video or tutorial before too long so that anyone who wants to take advantage of using Linuxsampler will at least know how to go about it, and yes, your assumption is right; I use Qjackctl to connect everything up and it is quite easy. I am sure you'll have no problem at all.

In reply to by AnthonyDeaton

Still not sure what you thought was "disrespectful" about my attitude. Again, I was not actually responding to you in my post here that you called "disastrous", but instead I was merely trying to caution out the person who posted the question here about crescendo on a single note that switching to a Linuxsampler/SFZ would *not* magically fix this, nor would it automatically improve playback in ways many MuseScore users find important (eg, playback of slurs and articulations) without extra work. The OP had responded saying they were lookinjg forward to trying the SFZ and I got the sense he/she was not aware it was going to be as simple as loading a new soundfont and suddenly finding all the things MuseScore users find limiting or frutrating about playback would go away.

I definitely overstated in saying SFZ had *no* advantages over Sf2, but that was an honest mistake, no disrespect intended. Not sure why you took that mistake on my part so personally. Knowing now the things you've explained, I can absolutely see the advantages of SFZ over SF2. But FWIW, it still seems to me that until MuseScore improves its ability to take advantage of these things - most importantly, like automatically doing the necessary key switching to actually implement the various articulations - moving to SFZ is going to seem a smaller improvement that it couldshould be.

Anyhow, that's a very nice writeup you posted on the technical issues re:SF2 versus SFZ, so thanks for that!

Do you still have an unanswered question? Please log in first to post your question.