In the random test, I am getting failures like this:

expected [ '0.000000', '0.7365980', '0.9963679', '0.6111505', '-0.1696881', '-0.8406811', '-0.9674688', '-0.4679768', '0.3344546', '0.9203807', '0.9105090', '0.3112298', '-0.4895204', '-0.9733852', '-0.8271404', '-0.1454558', '0.6303879', '0.9981573', '0.7197811', '-0.02453710', '-0.7529715', '-0.9939785', '-0.5915450', '0.1938183', '0.8537155', '0.9609699', '0.4461515', '-0.3574779', '-0.9296981', '-0.9000890', '-0.2878177', '0.5107691', '0.9787154', '0.8131016', '0.1211359', '-0.6492458', '-0.9993457', '-0.7025307', '0.04905942', '0.7688915', '0.9909905', '0.5715833', '-0.2178318', '-0.8662359', '-0.9538923', '-0.4240575', '0.3802860', '0.9384558', '0.8891270', '0.2642322', '-0.5317103', '-0.9834563', '-0.7985732', '-0.09674298', ...] to deeply equal [ '0.000000', '0.7365980', '0.9963679', '0.6111505', '-0.1696881', '-0.8406811', '-0.9674688', '-0.4679768', '0.3344546', '0.9203807', '0.9105090', '0.3112298', '-0.4895204', '-0.9733852', '-0.8271404', '-0.1454558', '0.6303879', '0.9981573', '0.7197811', '-0.02453710', '-0.7529715', '-0.9939785', '-0.5915450', '0.1938183', '0.8537155', '0.9609699', '0.4461515', '-0.3574779', '-0.9296981', '-0.9000890', '-0.2878177', '0.5107691', '0.9787154', '0.8131016', '0.1211359', '-0.6492458', ...]

Digging deeper into the error, the actual differences are:

69 0.5523313 0.5523314
73 -0.6857775 -0.6857776
85 0.9542708 0.9542709
536 -0.02468337 -0.02468336
752 0.02146683 0.02146682

Essentially just one-offs in the last digit. So the reference solution is doing something differently?

Also, shouldn't floating point numbers be compared approximately instead of rounding them and comparing as strings?

Beautiful DSA problem, magnificent.

Random tests have floating point errors.

The samples should be string values to seven decimal places

But 0 expects 0.000000 instead of 0.0000000, which only has 6 decimal places. Similarly, when values have leading zeroes it expects more than 7 decimal places, like -0.06421801 instead of -0.0642180, -0.004701102 instead of -0.0047011, ... This is actually 7 significant digits, not 7 decimal places.

Seriously, 6 solves without anyone catching this?

The input is not real MIDI: delta time in MIDI note packets are given as integer ticks, not actual duration in seconds. In the current design there would also be possibilities that a note do not last a whole tick.

Why the hell is Test.expectError used with empty string argument, 4 times, in the test fixture? This is intentional hostile abuse of test framework.

Do mods retire abandoned katas like this? Author has been inactive since 2017 (5 years ago as of this comment).

Fun but needs a few more out of range tests:
console.log(getMIDI('D11'));
console.log(getMIDI('Ab0'))
console.log(getMIDI('A0'));
console.log(getMIDI('Bb0'))

http://newt.phys.unsw.edu.au/jw/notes.html this site have the right numbers, the ones in the kata are really wrong.

• needs random tests
• the reference solution (hence the tests) is incorrect: A and B notes are associated with the wrong octave (1 higher than what they should be) description is misleading (see edits below)

EDIT: Mmmmmh, wait... Might be that the description is misleading, without the link, actually... I'm not musician, so I don't know, but does A0 exists or not? the current state of the description suggests it doesn't, hence my second point above, but is that the case, actually?

EDIT²: confirmed, that's the info missing with the link. A0 is considered to be after C0, not before...

because the reference solution is incorrect... ;)

edit: might actually be a problem about not being musician (misleading info, without the link to sort it out)

Why would A#9 equal 118 and Bb4 equal 58 (an octave higher than I would expect it to be)?

Link in the description is dead.

Julia translation kumited. I've changed the description a little, the description of how octave numbering works didn't match the MIDI spec or the test cases.

No random tests. Test.expectError does not provide useful information on fail.