Transposing instrument playback incorrect pitches on
Comiple MuseScore 3.2.2 release on Raspberry Pi 4 running Raspbian Buster in qtcreator debug mode. I'm discovering that transpoing instruments are off...listen to this audio of concert C chromatic scale, first on piano correctly, then on alto sax with some incorrect pitches, then on tenor which is always off.
| Attachment | Size |
|---|---|
| saved-on-RPi4.ogg | 284.91 KB |
| chromatic-scale-transposing.mscz | 11.62 KB |
Comments
I guess I should have posted in technology preview...but let me say this is a feature request to get transposing instruments working correctly on arm cpus.
My guess is this has to do with the requirement that "signed char" must be explicit.
In reply to I guess I should have posted… by ericfontainejazz
indeed, whether a unspecified char is signed or unsigned is implementation defined. We've been bitten by that more thasn once in the past.
In reply to indeed, whether a… by Jojo-Schmitz
That would be a code refactor I'd support.
Here in dayjob having unspecified containers flags errors and all types need to have their bitsize included (so int32_t is required instead of int etc (going by 32-bit platforms)). Helps the portability if you still have to mix 16 and 32-bit processors..
My first suspicion would be some signed vs. unsigned char issue or an 16bit int where others have 32bit ints.
Any compiler warnings to that effect?
In reply to My first suspicion would be… by Jojo-Schmitz
there are so many compiler warnings that it would be too hard to search. I'm looking at transpose.cpp for anything suspicious...the only use of char here I see is for legitimate letters for note names. And I only see "int" but no int16 or something like it...but I'll keep searching.
In reply to there are so many compiler… by ericfontainejazz
I'd also hunt through note.cpp and utils.cpp
class Instrument's char _minPitchA, _maxPitchA, _minPitchP, _maxPitchP seem suspect...
changing to signed char and recompiling.
In reply to class Instrument's char … by ericfontainejazz
maybe even make those ints. Seems there are tests for < 0 and > 127 in Instrument's write() function...
In reply to maybe even make those ints. … by ericfontainejazz
Their accessor functions return ints. And in class EditStaff, those same private variables are ints.
In reply to Their accessor functions… by ericfontainejazz
also anogously InstrumentTemplate has char min/max Pitch A/P. I'm making them ints...
In reply to also anogously… by ericfontainejazz
well...that didn't do anything...but I still think it should be done...
So I'm begining to think the problem doesn't lie with score processing, but rather with sound production. Because I'm noticing that the F# in alto sax sounds somewhere between it's G# and A...almost a quarter step between. So I'm going to look at synthesizer code now...
In reply to So I'm begining to think the… by ericfontainejazz
looking at the EventMap array, the PlayEven midi values seem correct. The are at least identical for a piano and alto sax playing the same note... So maybe it is just the sound rendering.
In reply to looking at the EventMap… by ericfontainejazz
the problem seems very much with the synthesizer. I've been comparing my x86_64 computer and RPi4 computer side by side and watching carefully the values changes. It seems for the problematic notes, the actual midi events seem correct...however the fluid synthesizer Voice::write function is indicating that for D#5 in Alto sax, while Voice's pitch value is correct at 6600, however root_pitch is different...the correct x86-64 computer has it as 6708 (542.73 Hz) while the incorrect RPi4 has it as 6452 (468 Hz). In other notes that sound correctly on the RPi, the value of root_pitch would be the same as on the x86_64 computer. So I'm going to check where that root_pitch gets set...
In reply to the problem seems very much… by ericfontainejazz
root_pitch gets set in voice.cpp line 986 in Voice::update_param():
root_pitch = sample->origpitch * 100.0f - sample->pitchadj;I'm noticing that sample->pitchadj is different on each computer...the incorrect RPi4 has it as 248, while x86 has it as -8.
Considering that 248 minus 256 equals -8, that seems to suggest the source of our problem...clearly a char issue.
In reply to root_pitch gets set in: … by ericfontainejazz
char SFont::READC() seems to be the culprit.
In reply to char SFont::READC() seems to… by ericfontainejazz
issue filed as: #291756: fluid synth's sample pitchadj signed char value incorrectly read on ARM cpus, causing incorrectly-pitched synthesis