Id like to see the console log BUT...
https://cycling74.com/forums/topic/novation-nocturn-usb-protocol
this and the associated code for linux, would seem to imply it is not USB MIDI class compliant but uses its own midi protocol.
note: they seem to refer to the 'novation nocturn controller' its not 100% clear there weren't different models (which i believe there were), and if so if they all followed the same protocol.
EDIT: @johannes, the following linux commit is quite interesting....
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dab9981756dbc3c50c194811f176f0d658c171af
it adds the nocturn to the 'quirks' list, and that quirks header is really interesting, basically lists quite a few devices, where they aren't conforming, but seems with some 'little twists' they can be catered for.
for midi there seems 2 popular 'use-case' quirks, MIDI_RAW_BYTES (old novation products), and fixed end points.
(of course the issue is catering for quirks for devices could easily get out of control... and impossible to test if a developer doesn't have the device to test with... but its interesting to at least 'know about')
EDIT2: after a quick look at the linux midi code...
ok, it looks like, on first glance, raw midi quirk, basically is just treat the usb data as midi... so none of normal CIN/port packet header that is required of the USB MIDI class compliant.
there is also another 'novation' quirk, which again is without header BUT have to strip length data from the usb data.
again, this is just 'scan' of the source code....
(oh, and the novation products with this quirk also appear to need the fixed endpoint quirk)
as i said though, this doesn't solve the 'how to deal with this reasonably' , as i couldn't implement, as I cannot test... and adding lots of quirks for various controllers, could lead to quite alot of firmware 'bloat'.
(its ok for linux, which is most often run on a full-fat computer )