Weekly status update July 18th to 24th

Posted 2 years ago

Hi,
a new small update for this week. This week was a lot about fixing small bugs and testing things on different platforms!

Because of my work on MidiSpanners I found some more bugs with midiAction. It didn't use the right channel. Instead of using the the actual channel number to emit it's Midi Messages it emitted them on the channel relative to the current Instrument. (Meaning a instrument can have multiple channels and midi Actions was using this channel index as the channel number)

After that I noticed that if you don't use JackMidi the channels do not get reinitialized after stopping playback or starting it again. Resulting in wrong playback sound if a MidiAction changed the program of the channel.

Then lasconic noticed some distortion on OS X with the new sample accurate volume envelopes in Fluidsynth. I found that there was a bug in the amplitude increment update method. It did update it one sample to early resulting in wrong end values of the amplitude resulting in endless correction of the amplitude.

For testing I also have now a development setup on OS X. (With the windows setup from last week I'm able to work/test on all three major desktop operating systems)

After all these changes I wanted to find out how things were on ARM (since we changed a lot of values to qreal instead of float - which caused problems on windows (see my post from last week) - and qreal is float on ARM but double on x86) and installed Archlinux ARM on my raspberry pi 2. There are some forum posts saying that playback on the raspberry pi in MuseScore is very sluggish but my experience was that MuseScore actually works quite well on the pi. The playback also works for big scores in MuseScore 2.0.3. I tested the part 1 of Beethoven's 9th symphony (the one I used in a earlier post to demonstrate improvements to Zerberus) and it did play back with just two little dropouts.

Playback with the current master works as well (I did it with a distcc setup to compile the current git version - this was actually quite simple - if you're interested in more details on using MuseScore on the raspberry pi feel free to ask! I'll post more information about it if you like!) but the performance is quite worse than with 2.0.3. This is probably due to the increased accuracy of sample based volume control and dropped optimization - Fluidsynth in 2.0.3 removes voices that are extremely quiet or having a volume of 0 and do not change. Because of the different way volume works now I removed these optimizations. The tests of the raspberry pi showed that it might be worth it to restore them again. Also having more Fluidsynth threads might increase the performance on the RPi 2 since it has 4 cores and just 2 of them are actually used by MuseScore (and as far as I can see just one by Fluidsynth!).

So I have a linux setup, a windows setup, a OS X setup and a RPi setup - so I can test things now on all supported platforms.

Despite all what I wrote here I also worked on the MidiSpanners most functionalty is now implemented. But I like to clean up the code and change some things because I don't like how they implemented right now. All sound stuff is just implemented for Zerberus right now and I want some more GUI to setup things for the SoundBanks. I hope I can do another screencast and show you how awesome it is to work with soundbanks!

Last but not least we started creating a google document containing information on freely available sfz files. (Some are free as in free beer and some are free as in free speech) Have a look here. Once we have enough information we might put it in the manual. Feel free to add comments to the document or in this blog!

The future plan for default soundfonts is starting of with a SFZ version of the current Fluidsynth soundfont and then start replacing things with VSCO because it is CC Zero.


Comments

The last sentence is very interesting. If the default sound library is in SFZ instead of SoundFont format, it seems to me that will require some extra work. The Zerberus synthesizer would need to load something like 200 SFZs at startup, rather than Fluid loading a single SF3 SoundFont, and the instrument list in instruments.xml would have to connect each instrument to its correct sounds in some way other than the current GM mapping. This is what you're thinking of?