New audio output architecture for MuseScore 2.0
A recurring criticism from MuseScore users is the audio rendering quality. We have always maintained that audio comes second to notation and it continues to be the case.
Back in version 0.9, MuseScore was playing every instrument with a piano sound only. It wasn’t until version 0.9.6 that it played all General MIDI instruments. As is possible in MuseScore 1.3, we are able to choose any SF2 soundfont to render the score. So you may wonder, what is planned for MuseScore 2.0?
As a teaser, listen to Reunion by Marc Sabatella, rendered by the current development version using FluidR3_GM.sf3 and Salamander Piano SFZ and rendered by MuseScore 1.3 using TimGM6mb.sf2. Read on while listening!
How audio rendering works in MuseScore
Sound generation from the score is done in two steps:
- Create a MIDI-like representation of the score
- Have one or more synthesizers playing this representation and output it to the system sound card.
There are several improvements in MuseScore 2.0 regarding the first step. Crescendos, mordents and tremolo will be played, for example. There is still much to do in this area (rallentando, ritardando, more articulations and crescendo on one note, etc...), however.
For this post, we focus on the second step. Currently, MuseScore 1.3 uses a modified version of FluidSynth to read SF2 files and then output the result via the audio driver selected in Preferences → I/O. MuseScore 1.3 comes by default with a small SF2 file, TimGM6mb.sf2 (5.69 MB). We could have included a better and bigger SF2 file, but it would have largely increased the size of the MuseScore installation package. FluidR3_GM.sf2 for example, is 141 MB.
Improving the default playback and the SF2 standard
Why are SF2 so big? Internally and as a standard, they use uncompressed sound samples (WAV). Werner, however, had an idea of changing the standard and create a new format using compressed samples (OGG). He named it SF3 and added support for it in MuseScore.
The result is spectacular! FluidR3_GM.sf3 is only 19 MB in size and the difference from the original SF2 is not audible. The next version of MuseScore will be packaged with this soundfont and only at an increased size of 15 MB.
In addition, it will be possible to load several SF2/SF3 files and select instruments in these soundfonts in the Mixer dialog.
More synthesizers
MuseScore uses FluidSynth and therefore, requires SF2 soundfonts to reproduce sounds. Advanced users tend to want more options, however, so in MuseScore 2.0, the code has been made more modular and two new synthesizers have been added.
Aeolus
Aeolus is a synthesized - not sampled - pipe organ emulator by Fons Adriaensen in MuseScore. Being synthesized, Aeolus is also small but very realistic.
Zerberus
Zerberus is a new synthesizer built from scratch by Werner Schweer. The goal is to support a limited number of free SFZ soundbanks. For MuseScore 2.0, it will only support the Salamander Piano SFZ. Salamander Piano is a very high quality sample library recorded by Alexander Holm in 16 velocity layers from a Yamaha C5 Grand and licensed under Creative Commons Attribution. The full version of Salamander Piano is sampled in WAV format and is sized 1.9 GB as a result. The sound quality is extremely good, but it will cost some disk space and memory.
Effects
MuseScore has two effects: reverb and chorus. Once the sound is generated by the synthesizer, MuseScore 1.3 applies both effects. The gain of each effect can be changed in the Synthesizer dialog.
MuseScore 2.0 will provide two chained effect racks - each can host one effect. Currently, MuseScore provides only one effect Zita-rev1. More effects could be implemented/integrated - another reverb effect Freeverb is being worked on.
.png)
Saving synthesizers and effects parameters
MuseScore 1.3 doesn’t save any synthesizer settings in the score file. Changes to the soundfont, master tuning, synthesizer volume and reverb are not stored in the file, so if it’s opened elsewhere, it could sound different.
By default, MuseScore 2.0 will not save synthesizer parameters (soundfont, tuning...), or effect parameters (gain, etc...) in the score either. Nevertheless, it will be possible to save these parameters by using the “Save to score” button in the Synthesizer dialog. It will, of course, be possible to load them from the score at the same place. The other opened scores will then use the loaded parameters.
A note about the soundfont (SF2, SF3, SFZ) files: In MuseScore 1.3, it is possible to load one SF2 file directly from anywhere. MuseScore 2.0 will provide a way to configure soundfont folders. These folders will be scanned by MuseScore for available soundfonts and users will be able to choose from this list. Loading soundfonts will be easier: Just drop them in the soundfont directory and they will be available to use in MuseScore.
Conclusion
MuseScore 2.0 will come out of the box with a better soundfont compared to MuseScore 1.x. Advanced users will have several new ways of tuning the audio output of their scores. For developers, it will be easier to add support for other synthesizers and effects.
Most of the features described in this post are already implemented in the development version, so go ahead and test! Feedback is welcome in the comments or in the Technology Preview forum.
Comments
I never heard about SF3 format. I typed on Google "soundfont sf3" and I haven't found definition of this format or editors, example files, etc. Can you recommend me some SF3 editor?
Nice article... but VSTi will be the best option/solution (in my opinion).
In reply to What is SF3? by Gootector
No wonder you never heard about SF3 before, citatation from lasconis:s article above:
Werner, however, had an idea of changing the standard and create a new format using compressed samples (OGG). He named it SF3 and added support for it in MuseScore.
@lasconic: your link to the technology forum doesn't lead where it should.
In reply to SF3 is Werner's invention by Jojo-Schmitz
Thank you. The link is fixed.
Yes, as Jojo mentioned, SF3 is new invention. An SF3 is the same than SF2 but the samples are compressed in OGG.
There is a crude utility to do the conversion here https://github.com/wschweer/sftools
In reply to Thank you. The link is by [DELETED] 5
Hi, since Opus has been finalised for production use, maybe it's possible to switch from Vorbis to Opus, retain the same audio quality while reducing file size even further?
In reply to Opus instead of Ogg Vorbis - version 3.1 ? by shaunlin
I was looking into Opus yesterday.
I gather there are still a couple of outstanding patent disputes including one from Huwaei?
Probably not a good idea to start implementing this until these are resolved??
In reply to I was looking into Opus by ChurchOrganist
Hi, to allay any FUD, these paragraphs are from http://www.opus-codec.org/license/ .
"The IETF allows anyone (and their dog) to file an IPR disclosures if they think that their patents "covers or may ultimately cover" a standard. In fact, for any organization who can be said to have contributed in any (very loosely defined) way, these IPR statements are not just allowed, but required. It is thus safer for organisations to declare as much as they can. As an example, one can find similar non-free Qualcomm IPR statements on both SIP and SDP. To our advantage, however, the IETF IPR disclosure policies require companies to provide the actual patent numbers. This allows anyone to verify these claims for themselves, which is definitely a good thing.
When it comes to patents, it is difficult to say much without making lawyers nervous. However, we can say something quite direct: external counsel Dergosits & Noah has advised us that Opus can be implemented without the need to license the patents disclosed by Qualcomm, Huawei, or France Telecom. We can also say that Mozilla is confident enough in Opus to ship it to hundreds of millions of Firefox users. Similarly, Cisco and Google are also supporting Opus in some products. More companies are expected to do the same soon."
If Opus is technically superior to Vorbis as is claimed, then I believe the problem is not with patent litigation (because Mozilla will be at the frontline of the battle), but with the time and effort needed to develop Musescore and soundfont derivatives that take full advantage of Opus.
In reply to SF3 is Werner's invention by Jojo-Schmitz
Twould be nice if there were more community options for reading sf3, like "libfluidsynth" but for sf3, so that it could become more common/widespread...until then it will remain a musescore only protocol I'm afraid...
Very exciting - all of it!
This does potentially give a bit of renewed / different focus to the effort to develop a homegrown soundfont. The dream of developing a brand new one from scratch that would be the absolutely the best possible still seems like something worth chasing. However, given that this is an enormous undertaking and still quite a ways off, I wonder if just taking FuidR3 and making a few small customizations - replacing certain certain sounds with ones from other "free" soundfonts - would be feasible for 2.0.
In reply to Very exciting - all of by Marc Sabatella
I had a chance to play with this a bit today, and I'm really impressed. I had forgotten there were also some under-the-hood playback improvements in 2.0 having to do with note attack/release or gating or something relating the sound of note on/off, and that this smooths out some of the rough edges on playback. Between that and the markings that are now supported, I hear a noticeable improvement even comparing playback using Fluid R3 with 1.3 versus 2.0. And having Fluid R3 small enough to include by default is *huge*. People who know only MuseScore playback only through the default soundfont on 1.X are gong to be absolutely blown away by what they hear. Congratulations to all who worked on any part of this!
Is there any chance you made MuseScore an LV2 host and implemented those as LV2 plug-ins? Also, being able to use LV2 versions of Pianoteq and setBFree would simply rock.
In reply to All internal synths? by alexandre_
Yes all internal synths. We didn't want to cope with the many difficulties of LV2/VSTi. We feel it's not the job of MuseScore to enter the battle of plugins compatibilities, and cross platform issues.
Is it possible a similar solution to that adopted Encore in version 5? They plugged a module created with Max/Msp that lets you load VSTs. So were not necessary internal changes in the program and users can use their own sounds.
I know MAX/Msp runtime is free available for Windows and Mac. Dont know if it is possible to use it on Linux.
http://cycling74.com/products/max/
In reply to VSTs with MAX/Msp like Encore 5? by AlvaroBuitrago
MaxMSP is not a free and open source software. Loading VSTi and LV2 is possible in MuseScore using Jack MIDI but it's far from perfect because the UI would need to be changed a lot to be able to select MIDI channels, programs etc... In many ways, it would make MuseScore interface less user friendly.
I thought I'd give the new audio a whirl. Using Win7 and release MuseScoreNightly-2013-04-27-1312-b3e891a.7z I placed a copy of Salamader in the sound directory (image attached). When I run 2.0 and select Zerberus, the sfz dialog box comes up, but the sfz Salamander font is not shown. What's going wrong?
In reply to Trouble testing SFZ in 2.0 by EdwardsRG
It's not the good directory. You should put the SFZ font in one of the folders defined in Preferences -> General -> SFZ folders.
In reply to It's not the good directory. by [DELETED] 5
Thank for the tip. That makes it work fine. I will put together some comparisons and post in the sound font forum.
I've just been checking out the work Werner has done on fixing the Aeolus Pipe Organ Synth in MuseScore and am absolutely delighted.
Here is a rendered version of Buxtehude's Ciacona in E minor BuxWV160 which I reworked for Aeolus over the weekend.
https://soundcloud.com/michael-cowgill/buxtehude-ciacona-in-e-minor
The pieces was rendered in MuseScore 2 commit bc04561 and then had reverb added in SonarX2. The Aeolus synth was configured to play in Equal Temperament rather than the default Mean Tone 1/4
The score still needs some final tweaking, but is attached so you can see how it is done.
In reply to I've just been checking out by ChurchOrganist
Any reason why you didn't use the reverb effect in MuseScore but Sonar?
In reply to Any reason why you didn't use by [DELETED] 5
Purely because of unfamiliarity with the interface.
Something I will be rectifying shortly.
Will 2.0 Soundfonts be able to handle notated trills? Because that would be a major step up. I know there are other free software programs that can do them
In reply to TRILLS by rokr258
A soundfont can handle a trill, including in 1.3. The issue isn't the soundfont; it's whether the program itself knows how to convert a single note with a squiggly line over it into a whole bunch of back and forth notes. I do believe some sort of capability to automate that will be in 2.0, but here again, it's already *possible* to get a trill playback effect in 1.3. You just have to enter al the notes yourself (and then mark them invisible, or put them on a separate playback-only staff, or whatever, if you don't what those notes to print.
Hello
I don't understand that you say score come first and audio after !
Score and audio should be at the same level !
To have the best audio you should not refuse that MuseScore uses other player like VSL
VSL is much more in advance, the piano, the Vienna Imperial has 1200 samples per key !
They have a bank of over 500 GB of samples,
They have Vienna suite that contains many effects, for example there Equalizer has a setup for each instrument of the orchestra.
At long last they have MIR PRO. it is expensive but it worth every euro, I use MIR PRO it is FABULOUS ! http://www.vsl.co.at/en/211/497/1687/2002/1691.htm
If you want MuseScore to be used by a lot of musicians, you should put your development forces in the score and leave the audio to the specialized audio people like VSL, East West .......
I have attached picture of my setup using Logic and MIR PRO, i am fed up of Logic score
In reply to MuseScore 2 by cyrilblanc
Sure, audio is important. So is word processing. So is world peace :-). But you pick which problems you want to solve. MuseScore is a program designed to solve the problem of producing notation to give to human musicians to play. Audio in this context is just a aid to help you make sure your score is correct, maybe to serve as a demo to give those human musicians to listen to.
Supporting VSL sounds nice, but presumably takes effort - effort that could be better spent improving notation features that are more important to most users or they wouldn't be using a notation program program in the first place. On the other hand, MuseScore is open source, so if you or some other motivated person wants to try your hand at adding this support yourself, I'm suspect the core development team would welcome the help!
In reply to Sure, audio is important. So by Marc Sabatella
This is why I have said to use IAC to start first.
Instead to send midi to a physical port you send it to an IAC port (Inter Application Communication)
I am sure you have the equivalent in Window and in Linux
A demo with VSL is much better, and for films that have a low budget a score played by VSL is very good !
You need to have very good ears to noticed it is not play by humans
Sibelius, Finale, Cubase, Notation are interfaced with VSL, PLAY ......
If you want like Logic to stay behind ! This is your choice !
If you want I can help you doing the table of equivalence between the coding that is in MuseScore and the commands of VSL. Most of the time you send a note that is out of the range of the instrument or you send CC# or you send both
The best is to make this file editable by users that have a little experience !
You just need to write the routine that convert and send to IAC
Best
Cyril
In reply to Audio with other player by cyrilblanc
Vienna Symphonic Library is proprietary software.
MuseScore is Open Source.
Do you get why we can't go down that route??
In reply to Vienna Symphonic Library is by ChurchOrganist
What is the problem !
Your software can talk to VSL, PLAY, .... engines ; there is no problem !
A lot of plug-ins are VST, AU, AXX ! some are Open source(free) some are proprietary !
VSL has published the key stroke to change articulations, it is open to software like MuseScore, Finale, Cubase .....
A lot of user will pay 100 or 200 euro to get the interface between MS and other players .
So you leave MuseScore as an Open Source and charge for the interface to VSL; PLAY and others !
I have propose to help doing the the equivalence table ! If you dont want my help, VSL and East/west users too bad !
In reply to What is the problem ! Your by cyrilblanc
I agree that the existence of proprietary systems like Vienna doesn't mean MusScore can never support that type of interface. after all, we support MIDI and MusicXML, both of which can be used to communicate with proprietary programs.
But I think the point is here, MuseScore cannot *rely* on proprietary software. It has to work as is rght out of the box using only free and open spurce components, because tht's that most users expect. Only a fpvery few relatively wralthy users will be interested in spending hundreds of dollars or Euros on add-ons. That's why it is important that MuseScore support built-in playback to the extent it is worth supporting playback at all.
In reply to I agree that the existence of by Marc Sabatella
Notion, Sibelius and Finale have it's own built in sounds, but if you want you can use the BIG SOUND of VSL and MIR
In reply to I agree that the existence of by Marc Sabatella
Excuse me, but how exactly do you rely on proprietary software by providing an option to use a 3rd party VST? Is that some obscure joke?
In reply to Excuse me, but how exactly do by alexandre_
I dont know if I have understand your question !
VSL and MIR are running on there own, just waiting Midi note and commands and outputting up to 7.1 (see picture I have post and see my MIR stage
You can also have VSL running on a farm of PC and/or MAC
Midi can be send either by a IAC, a VST, an AU or an AAX
Where is the joke ?
In reply to I dont know if I have by cyrilblanc
The best is you go on VSL site to listen what you can do with VSL
The piano :
https://www.vsl.co.at/en/211/442/478/1701/1711/1317.htm
VSL + MIR
You have plenty audio demo and Video explanations
https://www.vsl.co.at/en/211/497/1687/2002/2008/1696.htm
You see why !
In reply to I dont know if I have by cyrilblanc
> Where is the joke ?
You are asking the wrong quesrtion to the person :) I was replying to Mark.
In reply to Excuse me, but how exactly do by alexandre_
When I said MuseScore should not rely on proprietary sidtware, that was in response to this:
If you want MuseScore to be used by a lot of musicians, you should put your development forces in the score and leave the audio to the specialized audio people like VSL, East West ......."
That sounds like a suggestion to take develoment effort away from the built in synth that is available for free to all, and instead redirect that effort to supporting an expensive luxury product available only to the wealthy. And my point is that MuseScore needs to work well for everyone - meaning the majortity of effort soent on playback needs to be on the internal synth it ither free & open source options. And since MuseScore is developed by a very tiny team of people, they really need to ficus their efforts on things that be efit everyone, not just the rich. Besides, rich people who don't mind spening hundreds if dollars on music software are likely to just buy Finale!
Again, I'm not opposed to MuseScore someday supporting this type of playback. I'm just observing that the developers already have their hands full just getting MuseScore to a point where it meeds the needs of most musicians. Right now is not the time to steal resource from that effort and redirect it things that only benefit a tiny minority.
In reply to When I said MuseScore should by Marc Sabatella
I am not rich an I bought VSL little by little, Xmas after Xmas, birthday after birday
What is good with VSL if you can start with a few $ and add instrument and articulations little by little
East West and Garritan sounds are cheaper than VSL but are not as good
The big problem of Music on a computer is how the software is wrote, and how fast is the engine
If you take Notion it is ok for a Quator or a short piece but it is impossible to use it on a piece like "From the New World" of Anton Dvorak
With Logic there is no problem ! but the score is not so good and to change articulation you need to add note that out of range of the instrument
Have you listen to the links I gave you, you can see MuseScore has a lot of work to do before arriving to the quality of VSL
You speak of Finale, I have not hear very good feed back about the velocity of the engine
Finale is 600 $ it is a lot of VSL instruments !
So if you concentrate to have a beautiful and fast score engine, when finish you can concentrate on your player.
Why not speak with Garritan, it is included for free in Sibelius, Finale and Notion.
Best
Cyril
In reply to Hi Marc by cyrilblanc
I am not interest in quibbling over how rich is rich. The point is, MuseScore is free and open source software and appeals to a great many people for precisely that reason. It needs to work, and work well, right out of the box - no proprietary add-ons whatsoever.
When everything else about MuseScore is in place and stable and it becomes time to think about what directins to go next, is spunds like a fine avenue to pursue. But for now, there is far to much truly important work that needs to be done first.
Garritan, btw, does not give their stuff away for free. It comes with Finale because Finale pays them money. Well, tht was the case, then they just bught the company outright.
In reply to I am not interest in by Marc Sabatella
The point is, MuseScore is free and open source software and appeals to a great many people for precisely that reason. It needs to work, and work well, right out of the box - no proprietary add-ons whatsoever.
I'm becoming a big fan of musescore and just got more motivated to help by reading this. As a non-rich person (well, at least in terms of money :) I'll give my time to improve the development of musescore as long as it keeps a true free software project.
Anyways, I've just built 2.0b in my Debian box and will release a package very soon.
In reply to When I said MuseScore should by Marc Sabatella
That sounds like a suggestion to take develoment effort away from the built in synth that is available for free to all, and instead redirect that effort to supporting an expensive luxury product available only to the wealthy.
How do you arrive at this kind of conclusions, Mark? :)
I mean, it's obvious that by making playback engines pluggable and making MuseScore a VST host you are basically leveraging this part of the feature set to anyone who cares enough to improve playback features, not mentioning ability to just plug in existing products such as VSL. But no, let's pretend that it's all about "supporting an expensive luxury product available only to the wealthy" :)
In reply to That sounds like a suggestion by alexandre_
I was just reading the statement literally. I realize that English is probably not his native language - and may not be yours either - so perhas he did not mean it the way it actually sounds. But anyhow, my point stands. museScore *must* ork, and work well, without the need to buy expensive proprietary third party add-ons. And it takes a lot of effort to get happening. I for one do not want to this vitally important important effort sidetracked by other projects tht benefit only a small minority. Until MuseScore 2.0 is completed, I can't see any reason to spend development effort n non-essential like supporting expensive proprietary add-ons.
In reply to When I said MuseScore should by Marc Sabatella
Mark, that developers have better things to focus on right now is not even a subject to discussion :) Completely agreed here.
What I'm talking about is the potential.
In reply to Vienna Symphonic Library is by ChurchOrganist
> Vienna Symphonic Library is proprietary software.
> MuseScore is Open Source.
> Do you get why we can't go down that route??
Ardour 3 is free software, Loomer Aspect is a commercial VST synth, and I use them just fine. What is your problem with this kind of a setup? Ideology?
In reply to > Vienna Symphonic Library is by alexandre_
Why the aggressive comments? People will consider your requests and perhaps question them and in the end may accept them. There's no need to ascribe motives that you guess at. Usually that sort of attitude leads to less than optimal results.
Best regards,
In reply to Why the aggressive comments? by xavierjazz
> Why the aggressive comments?
The question was why running non-free software inside free software is not OK. You can choose to participate in the actual discussion, or you can continue discussing the discussion and thus not adding any value whatsoever to it -- that's entirely up to you.
In reply to > Why the aggressive by alexandre_
Exactly.
In reply to Exactly. by xavierjazz
So you can continue to fight but it's useless. Would be better to answer the questions that are worth answering...
Who is up to code or fund the coding (and the long term support of the code base!) of MuseScore as a VST host? If you don't have the answer to this question, there is no need to argue.
As a side remark, the people involved so far, have obviously no idea of what it would take to integrate VST or even MIDI out into MuseScore. "Just send the event to the VST or the IAC" is a joke. You need to send these events at a very precise time, in a precise order, so you need a real time clock and this is not piece of cake for a multiplarform software. Also VSTs comes with a UI, often not multiplatform. This forum would soon be transformed in a list of "Why my super VST YYYYY is not working with your software".
In reply to So you can continue to fight by [DELETED] 5
To Lasconic :
MuseScore has to send midi to the IAC port
If you look at the big diagram starting "Score" it will be at the same level Zerberus
It will work with all standalone player like Kontakt, Play, VSL .....
There is no maintenance, you just send midi to a software midi port instead of a hardware midi port ;)
The only maintenance will be the table of equivalence between MuseScore articulation changes and VSL articulation changes and/or Play and/or ....
If I do VSL's table I will do it's maintenance as I am the 1st interested.
Finale is able to output Midi to IAC ports !
I am trying to get example of coding from the CoreAudio developer forum
Best
Cyril ( I am French sorry for my bad English)
In reply to Midi out in MuseScore, by cyrilblanc
No... It's not at the same level than Zerberus... If it was just that, it would be done already...
(I'm French too...)
In reply to No... It's not at the same by [DELETED] 5
After SCORE on the diagram you have :
IN MEMORY MIDI LIKE EVENT LIST
if it is a Midi event list that you sent to your internal Synth the diagram should be :
In reply to Driver Midi out by cyrilblanc
Yes... but it's not about pushing boxes on a diagram... My diagram might be misleading too... It's a simplification of what is really happening.
The MIDI like event list is not sent to the synthesizer. In fact the audio stack of the system asks for a buffer, so it's the "time master" and MuseScore via the sequencer and the synthesizer (being zerberus, fluid etc...) creates some audio to send back to the audio stack.
In the case of MIDI out, the system would not ask for audio buffer, obviously, so MuseScore would need to send in real time midi events at the right time. MuseScore is not capable of this and that's the main part that would need to be coded. The articulations mapping is something totally different and of course, would be "easier"...
It's for the same reason that MuseScore has a JackMIDI output but no MIDI out (via IAC or on other platforms) (currently the only way to send MIDI events to a VST http://www.youtube.com/watch?v=GgHamEhVbCM) because Jack is the master in this case, and "gives the tempo" on when "events should be sent"
Some posters in this thread sounds like if MuseScore developers were lazy and makes a point of not having VSTi... even if I'm pretty sure they don't believe so. If I'm saying it's not piece of cake, it's because we discussed this issue for years... It's more than an educated guess. Everyone agree that having VSTi / MIDI out support in MuseScore would be nice and would unlock nice audio possibilities. There is just not the time and resource to do it, and to support it in the future, so the core developers needs to focus, and we choose notation first because we believe it's what matters. If someone else wants to tackle this issue, we would be delighted to help. By tackling, I mean coding, or pay for coding, not moving boxes without any audio development background.
In reply to Yes... but it's not about by [DELETED] 5
Just my 2 cents...
Focus is good, especially if resources are limited.
When the time is right, you may want to consider this:
1. For sending the events to a VSTi, I don't believe you need a real-time master clock. What happens is this:
- the host calls the processEvents call with the events to be played (I think only the ones within the next audio rendering slice)
- then on the next audio callback, the host calls processReplacing to fill the next audio slice
2. For sending the events in real-time to IAC (or any other virtual MIDI cable for that matter), you do need to send the events from another highly accurate MIDI thread (unless you can time-stamp the MIDI events, what would surprise me a bit).
3. If you add VSTi support, I would start with only stereo out support: some of the nicer VSTi's have of course surround support, but supporting that as a host is a bit more difficult than just starting with stereo. Not that it's so hard, but you will need mappings of available output channels to your VSTi outputs etc... which then requires some more work.
4. I'm not sure if that would work (I think it is possible) but there is another Open Source (!) C++ framework that is focused on audio stuff, is very actively developed, and has a built-in VST host class: JUCE (http://www.juce.com/about-juce). If you could find a way to connect that to the MuseScore's Qt code base, maybe that would save the hassle of dealing with different types of plugins etc... See: https://github.com/julianstorer/JUCE/tree/master/extras/audio%20plugin%…
5. I think that (from a certain high quality level onwards), the VSTi quality itself might not be the key to super sounding audio: it's the way in which the articulations from the score are transferred to the synth that matters a lot too.
In any case, good to hear that some love to the audio playback is indeed being given to the new MuseScore version!
Good luck!
Koen
In reply to Just my 2 cents... Focus is by KoenTanghe
Thank you Koen for bringing your expertise in this thread!
1- It's also my understanding after some research.
2- Yes. This highly accurate thread MIDI thread is the main pain to implement MIDI out and it's often overlooked... Especially implementing it for Windows, Mac and Linux seems challenging. Time stamping MIDI events would mean being able to know the number of ms since the midi driver is opened, not sure we can do that indeed.
3- Thank you for the advice!
4- I think it's worth investigating JUCE. It's a proven framework with a dedicated developer. Maybe a good topic for Google Summer of Code next year.
5- Agree... Once the "wires" are in place, there is a lot to do to take the most out of it. Mapping the articulations to the VSTi, have more "humanized" velocity and small note shift etc... are all very important. I'm not General MIDI is enough to bring all the necessary info to the VSTi.
In reply to Thank you Koen for bringing by [DELETED] 5
I'm not General MIDI is enough to bring all the necessary info to the VSTi.
The General MIDI subset of MIDI commands may not be flexible enough to do this, but the MIDI 1.0 specification is flexible enough to transmit any kind of performance data that you require.
General MIDI is only scratching the surface of what MIDI is capable of.
The basics are all there - control of velocity channel volume, expression, vibrato, filter cutoff and resonance, there are even aftertouch controllers to be able to control what happens to a note after it has been initiated,
If even more control is desired then using Roland or Yamaha GS/XG extensions by the use of SysEx and NRPN will greatly expand the potential control over a synth, indeed Roland and Yamaha synths are still using these systems today. The only caveat is that the receiving synth must be able to interpret the messages being sent correctly.
The other thing which will need to be done is to increase MuseScore's internal tick resolution to 960 tpq (ticks per quarter note)
In reply to I'm not General MIDI is by ChurchOrganist
>The other thing which will need to be done is to increase MuseScore's internal tick resolution to 960 tpq (ticks per quarter note)
Which means to double it, as far as I can see. Might create the room for adding a 1/256th note requested elsewhere?
In reply to >The other thing which will by Jojo-Schmitz
And indeed 1/512th and 1/1024th which have also been requested.
In reply to I'm not General MIDI is by ChurchOrganist
Before you send note and articulation to the VSTI or to the AU or to the IAC, you need to go thru conversions tables this depending of what VSTI/AU/IAC will be after
For VSL :
For a bass sound send (Bass, bass trombone, ....)
a note C6 to B6 selecting the bank of articulation
CC#1 val with Val = to 0 or 127
a note C7 to B7 selection the articulation
For a high sounds like a Violin,Viola you will send :
a note C0 to B0 selecting the bank of articulation
CC#1 val with Val = to 0 or 127
a note C1 to B1 selection the articulation
In reply to Before you send note and articulation to the VSTI/AU/IAC by cyrilblanc
Thing is that most of this will be synth specific.
The requirements for VSL will be different from other samplers.
So a completely flexible architecture will need to be written which will allow the user to send the messages required to drive the particular synth they are working with.
What we need is someone with experience in writing these kind of drivers - although I have an in depth knowledge of MIDI, sadly I do not have the required programming experience.
As MuseScore 2 is already way overdue it is unrealistic to expect any development on this before that is finally released.
Once that is done, then maybe the structure of this architecture could be discussed.
In reply to Thing is that most of this by ChurchOrganist
Lets use 2 different words Synth and Player , because they are needing different things
Players are PLAY, VSL, Garritan, Kontakt ...
On a synth you will not send articulation changes, just notes and CC
On players you will need one or more translation table per player to convert internal articulation codes of MuseScore to the player
Those translation tables have to be in separate editable files and simple enough so an advance user can make it's own table depending of the collection he own.
I said before that I am volunteer to do the one for VSL.
For VSL we will need at least 2 tables :
- Preset level II collection for the BIG collection
- Table for SE+
In reply to Synth and Players by cyrilblanc
This is quite an old subthread in the comments here. Is there a more up-to-date version of this discussion. I'm not questioning the priorities and of course in the meantime 2.0 has shipped and is awesome. I'd like to see MIDI playback implemented in the future and might be able to help. I'm a software engineer but don't have MIDI expertise and haven't looked at the musescore code yet, so I'd need to educate myself a bit.
Has anyone taken a look at JUCE integration?
In reply to This is quite an old by mcx
The big stumbling block, as I understand it, is that there is no-one on the development team who can write the MIDI internal clock code.
To output standalone MIDI each event has to be time-stamped with Bar, beat and tick information in order for it to be interpreted correctly by the receicving MIDI device. At present JACK provides all this information for real-time MIDI output, and the output of MIDI files is OK because the timestamps don't have to be in real time.
What we need is for someone to write a MIDI clock kernel on which we could hang the rest of the MIDI output code.
This is a very specialist area, and if you decide to take it on you will have to immerse yourself in a huge swathe of MIDI technical data.
I amd willing to do what I can to help - but I'm a MIDI event programmer, although I have a basic understanding of MIDI timecode, I couldn't even begin to start writing the C++ code necessary to implement a timer.
In reply to This is quite an old by mcx
We talked about JUCE several times but we never tried to integrate it. As far as I know integrating JUCE with a Qt program is not easy. They are both primarily GUI toolkits...
I've justed created my first score in 2.0 and exported it as an MP3 file (thanks for the handbook help regarding the requirement for lame_enc.dll) but I've noticed the file size is about 3 x times what I would have expected. Normally a 64 bar piece using the SATB template with no lyrics or extra embellishments is about 900K - 1.5Mb for me (about 2 - 3 pages A4) - this new one is just under 3Mb. Is this what you would expect ?
In reply to I've justed created my first by hopefulstrider
I guess it depends on what mp3 compression / quality / bitrate settings are used. Whatever MuseScore uses by default, I guess maybe you normally use something with higher compression / lower quality. If you need control over the details of the compression settings, probably best to just export as WAV and use Audacity or some such to do the conversion to mp3.
In reply to I guess it depends on what by Marc Sabatella
I usually use Musescore 1.3! What I'm saying is that MP3 files created in Musescore 2.0 are nearly 3 x times bigger than they are in Musescore 1.3. My concern is that I will only be able to get a third as many MP3 files burnt on a CD in 2.0 as I did in 1.3
In reply to I usually use Musescore 1.3! by hopefulstrider
MuseScore 1.3 can't create MP3, so the files can't be bigger than those created from 2.0...
In reply to I've justed created my first by hopefulstrider
are you using the same soundfonts for 2.0 and the other? That could make a difference in compressability of the output...
OK - so in 1.3 I create a score and 'Save Online' and click the prompt OK. When I login to my Musescore account that score is listed. I open the file, and then hit the Download button (its to the right of the score), and from the dropdown menu I select MP3 format and click. The file then appears in my windows Download folder as an MP3 file. Where the conversion takes place I know not - but I don't use any other program or software to do it, and I've done hundreds of these over the last couple of years.
In reply to OK - so in 1.3 I create a by hopefulstrider
1.3 and MuseScore.com (up to now, this may change shortly?) use a rather small soundfont, 2.0 a much bigger one, that would probably explain the different sizes?
In reply to OK - so in 1.3 I create a by hopefulstrider
Hmm, I don't think soundfont size would affect MP3 file that much - more detail means compression is less effective, potentially, but not by a factor of 3. I expect it's just that msuescore.com was exporting to WAV and then converting to MP3 is using some third party software and set to apply very heavy compression, and MsueScore is simply applying less heavy compression. So the sound quality should be better in MuseScore 2. But if you don't mind trading sound quality for file size, you are still welcome to export to WAV and convert to MP3 yourself and choose any sound quality setting you like.
In reply to Hmm, I don't think soundfont by Marc Sabatella
The MP3 file are currently different. The one created by MuseScore.com for 1.3 are 24kHz (dont ask me why...), the one made by MuseScore 2.0 (and by MuseScore.com soon) are 44.1kHz for the moment.
In reply to Hmm, I don't think soundfont by Marc Sabatella
Thanks for that. Do you anticipate that Musescore 2.0 will export to musescore.com in due course?
In reply to Thanks for that. Do you by hopefulstrider
It will. I believe the latest nightlies do already, but I'm not 100% sure. RC should, at least that's the plan
In reply to OK - so in 1.3 I create a by hopefulstrider
@ hopefulstrider... For your consideration ...
Soon, when you are able to upload 2.0 files on your account at musescore.com, try this:
Instead of comparing a version 1.3 file converted to mp3 via MuseScore.com, to a version 2.0 file directly exported to mp3 from within the MuseScore program (via lame), try converting the exact same 2.0 file by each of your two methods (upload/download vs. native export) to see if the resultant mp3 size really differs.
Regards.
In reply to @ hopefulstrider... For your by Jm6stringer
Seems like a good idea.
In reply to Seems like a good idea. by hopefulstrider
@hopefulstrider... Re: difference in mp3 file sizes
Well... yours was a good observation, and lasconic's reply about the different sampling rates (24kHz vs. 44.1kHz) reveals the reason - a smaller sampling rate leads to a smaller file size.
If you are concerned about burning CD's and fitting the same amount of mp3's on a disk, then Marc's advice about exporting from MuseScore 2 to .wav and using something like Audacity (to set your own mp3 conversion parameters) is spot on.
In fact, Audacity has a setting for a 22,050Hz sampling rate - very close to the 24,000Hz (24kHz) used by MuseScore.com - so you should be able to fit the same amount of music on a CD at the same quality.
Regards.
In reply to @hopefulstrider... Re: by Jm6stringer
Be aware though that dropping the sampling rate lowers quality.
CD quality sample rate is defined as 44.1kHz, which is the minimum quality usually output from professional studios.
By using 22.05kHz you will be seriously degrading the quality of the samples, resulting in possible distortion, grittiness and artifacts such as hiss.
This, coupled with MP3 compression applied is almost certain to degrade the quality to an extent that I certainly would not want to play it in public through a sound system.
I'm not sure why you would wish to store on CD anyway? CD is an obsolete storage format which is likely to disappear within the next 10 years. You would be better to store on SD cards of which even the smallest size available will store 10 times the amount of data you can fit on a CD.
In reply to Be aware though that dropping by ChurchOrganist
Yes, I agree. MP3, CD Audio are a relic of the last decade. 320 kbps, 48kHz MP3 file sounds worse than any Flac file. Flac is the format of the future. Among the compressed formats - AAC, MP4.
It may be 2015 but if I even mention SD cards, USB sticks, MP3's or even the word 'audio' to most of the choir their eyes glaze over and they start to talk amongst themselves about what a disaster the Titanic was ....... get my drift ? Getting them to play CD's was a big win! Thank you everyone for your comments on my query - very helpful.
In reply to It may be 2015 but if I even by hopefulstrider
I love the picture you're painting here :-)
In reply to It may be 2015 but if I even by hopefulstrider
So, if you're burning audio CDs, presumably you are using WAVs?
In which case I fail to see the relevance of MP3 here?????
In reply to So, if you're burning audio by ChurchOrganist
Exactly :D WAV = 44,1 kHz, 16-bit, stereophonic PCM = Compact Disc Digital Audio...
In reply to So, if you're burning audio by ChurchOrganist
Data-CD with lots of MP3s, at least that's what I gathered
In reply to So, if you're burning audio by ChurchOrganist
Greetings to all...
Regarding WAV, MP3, and burning audio CDs:
Popular practice in the past was to compose a list of .wav files which was then converted to .cda (compact disc audio) by the burning software - e.g. Windows Media Player, Nero. Total play time of a CD was slightly less than 80 minutes - let's say approximately 20 top ten tunes.
With the advent of mp3 players, consumers could copy .mp3 files directly onto CDs as 'data' - with a limit of 700MB per disc. It became possible to burn, say, 100 top ten tunes - depending on the sampling and bitrates of the (compressed) .mp3s onto a single CD.
Also, many automobile CD players are able to read mp3 discs, so consumers could play back not only music (in a moving vehicle, *audiophile* sound quality may not be as important); but also other recorded audio - language instruction, audio books, etc. - where recording of human voice dictation does not require the gazillion data points as a symphony orchestra + chorale. For something like language, nine hours of recorded content on a single CD would not be unusual.
Alas though, today many car stereos come equipped with USB and/or SD ports, so the compact disc will eventually go the way of the casette.
Regards.
I don't get the point to miss the final rendering of a piece.
You have the score, the synthesizer, the soundfonts and stuff.
But it's still a pain to get to the rendering (aka WAV file).
IMHO just listening the music is not enough.
In reply to I don't get the point to miss by Uqbar
What do you mean - are you saying that exporting to WAV is not working for you? Can you post the score you are having problems with and preecise step by step instructions to reproduce the problem (including mention of what soundfonts you are using)?
In reply to What do you mean - are you by Marc Sabatella
How easy is to render a score with 3 or 4 different soundfonts into a 48Khz 16bit WAV?
Last time I tried it it's been a real pain.
Show me how to, please.
In reply to How easy is to render a score by Uqbar
Not sure what you mean. Do you need helping loading the soundfonts? Once loaded, it shoudl be a matter of File / Export and specifiying WAV as the format. I guess check sample rate in Edit / Preferences / Export first. Depending on which build you are using, you might need to press "Save to Score" in the Synthesizer window. Doesn't seem necessary in current development build, but maybe it was in earlier ones. In any case, that was only one additional one-time-ony (per score) step; I can't see anything about this that could be a considered a
"real pain".
If you are still having trouble, again, please post all relevant information to reproduce the problem so someone can help guide you more specifically.