[Mac PPC] MIDI import quantise does not work

• Oct 23, 2011 - 12:30
S4 - Minor
won't fix

The MIDI import feature pops a window that says «Durata minima nota importata:» giving the option to chose from a drop down menu listing 1/4, 1/8, 1/16 and so on. While the quantisation works fine in Windows 7 and in Windows XP, it does not work at all in Mac OSX (I'm running MuseScore on an OSX 10.4.11 system). This bug makes importing MIDI files that are not exactly quantised as needed in themselves a "nightmare", as the score opens with lots of overlappings and too literal use of note values and rests. Please check and see what can be done.


Many thanks for your attention, lasconic. Of course I can provide an example. Here we go,

1. test1.mid is a perfectly quantised 4 measures MIDI file.
2. test1_import.mscz is the result of importing test1.mid with a "shorter note" value set to 1/16. As you can see the transcription is rather correct, I would have used a dot instead of a tie, and I would have chosen a different beaming pattern, but those are minor issues -- the trascription remains easily readable and can be "fine tuned" in a matter of seconds..
3. test2.mid contains the same 4 measures as test1.mid, but I didn't quantise them in advance, so the single notes are in time, but not perfectly aligned to the grid.
4. test2_import.mscz is the result of importing test2.mid with a "shorter note" value set to 1/16. The result is correct, but almost unreadable due to what I call a "literal trascription". The 1/16 limit has been ignored, and rests as short as 1/128 do appear! Many notes are splitted and tied together again in order to obtain the correct values. The "dirty notes" give life to overlappings that confuse even more the reader. Such a transcription would need a big effort to be translated into a readable form.

If the examples are not clear, just ask and I'll try to provide what is needed.

Attachment Size
test1.mid 116 bytes
test1_import.mscz 1.38 KB
test2.mid 116 bytes
test2_import.mscz 1.52 KB

Errata Corrige: test1-mid and test2.mid do not contain 4 measures. They contain 4 beats organised in a single 4/4 measure.

Status (old) needs info active

Thanks for the test files. It will make the life of the developer who wants to take a look to this bug a lot easier. To be sure I understand it well, the first file "test1.mid" does not import the same on Windows and on Mac PPC right ?
On a Mac Intel I got the same than "test1_import.mscz".

What you hightlight in #2 is different, MuseScore don't deal well with non quantized MIDI. That's another bug/feature request.

Well, test1.mid (the quantised one) imports exactly the same on both the platforms, while test2.mid imports the same as test1,mid on Windows machines (both test1.mid and test2.mid give the same, good result), and in the unreadable test2_import.mscz way on my PPC Mac OSX 10.4.11. In other words, just the Mac version of MuseScore looks unable to properly quantize a MIDI file during the import procedure. Now, I'm not a serious developer at all, but for what I can IMAGINE, it looks like the Mac import does not even TRY to make any quantization, and I suggest that it might bypass some relevant sub-procedure -- maybe someone just forgot to include the proper function call?

I mean:

proper sequence: 1. ask the user 2. read the user's option 3. quantize MIDI data 4. translate MIDI data into notation
wrong sequence #1: 1. ask the user 2. read the user's option 3. translate MIDI data into notation (ignoring the user's instruction)
wrong sequence #2: ask the user 2. quantize MIDI data (ignoring the user's instruction) 3. translate MIDI data into notation

In other words, maybe the correct functions are there, but they are simply not called when compiling for the Mac?
Just trying to guess.

What should happer? Well, this is free software, so I don't expect anything but what I already have -- the quality/price ratio is incredibly high! Nevertheless, the import feature does not work on Mac OS 10.4, PPC CPU. Is that system obsolescent? Well, I don't think so, unless one loves considering pretty working hardware obsolete in a matter o a few months (it is called "planned obsolescence" and it's nothing but a nasty marketing strategy). Can that bug be fixed? Good. Can't it be fixed or no one wants to fix it? Good as well. But, PLEASE, consider how wrong it is implying that Mac OS 10.4 for PPC is "obsolete". I still have (and use) a perfectly working Mac 7.1 system running on a '96 LC475 motorola 68k CPU. Great software. Great hardware. It depends on what you need it for.

It's important to reach as many operating systems as possible, of course.

However, there's a number of reasons why support has ceased. I'm sure the developers could detail better than me.

Regardless of how you feel, PPC support is disappearing quickly evidenced by Apples removal of Rosetta in OSX 10.7. When Apple moved to Intel they left the rest behind very quickly, as they always do to older tech, so most if not all of the blame for lack of PPC support would rest squarely on Apple. The first Intel Imac was released in 2006, and all the PPC units are now 6+ years old and either unsupported or classified as "vintage" by Apple meaning hardware support is very limited.

This is exactly the reason why I will keep on using my "old" Macs while they work, then I'll dismiss Apple and its nasty policy with no regret. A six years old computer can't be regarded as "obsolete", its owner can't be literally forced to spend his valuable money for the sake of a software/hardware house wealth. I'm a user and a customer, not a cow to milk. That's it.

Your 6 year old computer still fulfills the task it was bought for 6 years ago, so why complain? You didn't buy a "free update for lifetime" package and wouldn't have wanted to pay the price for one in the first place. But we're drifting off topic...

I didn' t see this discussion until now. Apple is making a good job selling his hardware and software, call it the way you want, planned obsolescence, good marketting but they are releasing a major version of the OS every year. Small projects can't keep on with this peace, and they have to support the Windows and Linux users too...

The problem here is probably fixable. It's probably a byte order problem while reading the MIDI file since PPC has a different byte order than Intel, bugs on this platform are most likely due to that. That being said, I don't have a PPC at home and time is better spent on painful issue for the majority of people. So, we/you need a developer, with a PPC, and the good motivation to fix this bug if you want to use this feature on your 6 year old mac.