"midiin" missing NOTE ON and OFFs
sugoza
7月 06 2024 | 5:40 午後
Hey Max users,
After using Max for over 10 years, I'm writing in the forum for the first time, because I have a big error.
For my long-term project - a MIDI looper - I bought a new device. The Yamaha Finger Drum Pad FGDP-50 which I really enjoy.
Here is my problem: The „midiin“ object swallows notes that were definitely sent. Sometimes a NOTE ON is missing and sometimes a NOTE OFF. This doesn't happen in the MIDI Monitor app or in Ableton live. No data is missing there! So the device ist working correctly but Max/Msp makes troubles. The same mistake happens with xmidiin, notein, xnotein. I never had a problem with other midi master keyboards.
I've tried a lot of things. I've tried it with the latest Max version and with a older Version. I've tried it with and without overdrive. I am working on a mac.
Could this be a „midiin“ bug? Is there another midi in object? Is there a workaround without „midiin“?
Many, many many thanks!
Best regards,
Peter
Roman Thilenius
7月 06 2024 | 6:12 午後
the question is where it is missing. directly at the [notein] output? (just to make sure)
sugoza
7月 06 2024 | 6:21 午後
hello Roman, thanks! yes directly after the midiin or notein output. I print it out and compare it with midi monitor app. same thing happens when I go to midiparse or something else.
LSka
7月 06 2024 | 6:54 午後
having a quick look at the MIDI implementation of your device https://it.yamaha.com/files/download/other_assets/3/2157353/FGDP_50_30_en_dl_v013.pdf seems like it outputs Note Off with release velocity. [xnotein] should do the trick here.
sugoza
7月 06 2024 | 7:52 午後
hi, unfortunately that doesn't work. I tested it again with xmidiin and xnotein. now with the latest max version and a fresh install. nothing. thanks for your help.
sugoza
7月 06 2024 | 10:25 午後
I have now tested it with the help of Ableton Live. If I go into Ableton with the yamaha device and then forward it via an IAC bus to max, then it works. Max receives all notes correctly with a release velocity of 64. ?
Source Audio
7月 07 2024 | 7:48 午前
If I read that manual - midi implementation correctly ,
then it does not transmitt midi note off at all.
but note on with velocity 0.
But on last page it states that it does not send it at all
x = NO, o = YES
what does it send really ? capture few pad hits using raw midiin.
And turn off midi clock out if possible, and other things like repeat or whatever else it offers ....
I had a short look in the manual of it,
are you sure you set pad note modes etc correctly ?
I don't really get it, do they send anything related to note off ?
I remember something like live treats very low velocities as note off ?
Which could explain what you describe.
If that is so, I would use makenote in max.
Roman Thilenius
7月 07 2024 | 12:51 午後
if it actually has release velocity it would have to use real note off (0x80), but half of these chart suggest otherwise.
it is still unclear why it works in other apps but not with midiin; midiin should transport and output everything, no matter what it is, unless it is invalid.
sugoza
7月 07 2024 | 2:39 午後
Hi, you are right. The device definitely doesn't send a note off, but a note on with velocity 0.
So for example on channel 1:
print: 144
print: 24
print: 95
print: 144
print: 24
print: 0
If I send 32nd notes repeated using the pad hold function and forward it directly via an IAC port in the midi monitor app, you can see that many notes are missing. If I print it in max console directly after the midiin, the result is the same. I tried this with midiin and xmidiin. It looks like max is overwhelmed, but I don't understand that. Could it be that I have too many midi ports? However, I have already tried deactivating all ports.
I made the same test with two external midi routing apps. Yamaha drum device > MIDI Router app or Midi Fire app > IAC Port > Max midiin > Max midiout > midi monitor app. both apps make almost no errors (I have noticed minimal deviations)
I haven't noticed any errors on the device itself. It sends MIDI clock but I can't turn it off. The repeat function works (the error occurs with and without the repeat function). Note pad modes are correct - I've already tried and tested all modes. No, I don't see the problem with low velocity as note off. What I do see is that no note offs are sent. I don´t get it.
I don't understand why midi monitor app doesn't show any errors.
Thank you for taking the time to help me!
Kind regards,
Peter
Source Audio
7月 08 2024 | 7:45 午前
Do you want to use that repeat function or not?
if not, then record pad or pads
in a way that one can see if notes get in max as expected or not.
That is one shot unit, notes are probably very short,
does it make a diffeence if you tap, or hit - hold- release
to note length ?
From that screenshot, one can't tell what is the capture on the right,
why you receive midi from multiple sources in it etc etc.
midimonitor can mixup things, if you set it to rute midi between apps.
I would midiin -> seq - record few pads and save as text.
then post the file here with explanation on how pads got played.
restart Mac , open only Max and run only this :
Source Audio
7月 08 2024 | 9:32 午前
P.S.
seq in max 8 drops first note if it is followed by note off too fast.
IAC Buss s/r tested
delay of 0.01 ms is enough to fix it.
But midiin receives notes as it should.
sugoza
7月 08 2024 | 5:18 午後
Hello, here is the text file. only midiin > seq
the second file is with midiparse to make it easier to read. both data are identical, I checked it.
Only max msp is open and the computer is new restarted.
50 very short pad hits, always 3 notes together. You can see that data is missing. This also happens sometimes with long pad hits.
I don't need the repeat function, it was just to understand the problem better, because you can quickly see that it swallows a lot of notes.
Yes, the notes are very short. As long as I hold the pad it doesn't send a note off, only when I release the pad. just like with any keyboard
I've noticed something else, again in comparison with "Midi Monitor".
If you look at the picture you can see that note on 31 is missing in the black Max console. In the MIDI monitor it is there with the same time stamp as note 24 below, i.e. 18:45:37:806. Could it be that max swallows the note because two different notes are too close together? But i never noticed this with other devices.
thx, peter
Source Audio
7月 09 2024 | 7:38 午前
"Could it be that max swallows the note because two different notes are too close together ?"
That can well be.
But I can not get why ...
I made really speedy test, sending 32 X 3 notes on and 3 notes off using uzi,
and over IP-midi network, old macbook to mac.
Max does not miss a single note.
capture in midimonitor nanoseconds , note events are much closer than
in your capture.
etc ...
here capture to coll.
coll captures exactly 192 note events from notein
midiin to text capture test . same result, sending whole sequence fast
several times - no single dropout
Source Audio
7月 09 2024 | 11:29 午前
More tests.
I assembled arduino 32u4 based USB Midi controller to test USB Midi as such
and sent very fast sequence of notes
3 x On, 3 x Off 32 times.
not a single missed note.
complete transmission took 24 ms
here is midi monitor capture
12:57:43.083 From Leo-Midi-1 Note On 1 22 100
12:57:43.083 From Leo-Midi-1 Note On 1 23 100
12:57:43.083 From Leo-Midi-1 Note On 1 24 100
12:57:43.083 From Leo-Midi-1 Note Off 1 22 0
12:57:43.083 From Leo-Midi-1 Note Off 1 23 0
12:57:43.083 From Leo-Midi-1 Note Off 1 24 0
...
...
12:57:43.107 From Leo-Midi-1 Note On 1 53 100
12:57:43.107 From Leo-Midi-1 Note On 1 54 100
12:57:43.107 From Leo-Midi-1 Note On 1 55 100
12:57:43.107 From Leo-Midi-1 Note Off 1 53 0
12:57:43.107 From Leo-Midi-1 Note Off 1 54 0
12:57:43.107 From Leo-Midi-1 Note Off 1 55 0
..........
same thing in max, all 192 midi events got received correctly
.......
To me it seems that your device does something wrong, it can not be speed.
maybe it drops repeated midi status bytes, and max can't cope with that.
would you try this - in case you only need to play short notes for one shot samples
does it receive at least all notes on ?
sugoza
7月 09 2024 | 2:31 午後
Hello, it's getting hotter. I tested the device with my wife's laptop. A completely MIDI and Audio free computer. Just Max and the Drum device and MIDI monitor. I didn't see any dropouts. The device worked without any problems.
So it must be something with my Max App on my laptop because the device works with other Apps (Live or Midi Monitor etc.) without dropouts and also works with Max on my wifes computer.
Later today, I’m going to delete Max and reinstall it. I've already done that but maybe I have overlooked something. I'll get back.
Thanks for your test. I made the same test here with the help of „from Max“ into Midi Monitor and it was working perfectly. No Drop Outs at all. See in the Screenshot:
I made a short screen video capture of my problem with the device. hope I can embed here:
Thanks!
Best regards,
Peter
Source Audio
7月 09 2024 | 2:37 午後
If you are on mac, there is nothing to reinstall,
but you can trash max settings, only leave your max authorisation.
sugoza
7月 09 2024 | 4:42 午後
Hey, I tried the stripnote thing at first when I noticed that there is a problem. I do not need long notes. But after spending time with it, I noticed that there are also Note Ons missing. So that was unfortunately disappointing.
Now it gets interesting: I've just done a few tests with the Arturia microfreak, with short arpeggios. Shit, I'm having a similar problem. Again, notes aren't coming through, but they are send because they are in MIDI monitor and the way over the MIDI routing software works perfectly... And again, there is a problem with short notes. I don't know if this problem with microfreak is new, I've never needed the box for fast arpeggios. I will take a closer look and then post more.
Maybe I should check my whole midi system (but then I don't understand why other programs work)
Many thanks, Peter
wkwhwh
7月 11 2024 | 11:04 午前
Not sure if it's exactly the same problem but, I was testing today my oxi one, to send noteout to my peak and I am also getting a lot of midi note drops or not offs not being triggered
my patch is very basic, tested the same in ableton live and I have 0 drops of midi notes or note offs not being triggered.
small update: seems like disabling sending midi transport information from my oxi one solved the problem.
sugoza
7月 11 2024 | 10:38 午後
Ok, good to know that midi transport information causes problems.
I think I have found one problem with my Yamaha device. It has something to do with MIDI clock.
The box generally sends MIDI clock, which I cannot switch off on the device itself.
But if I send MIDI clock to the device, the device no longer sends a MIDI clock out and it works much better.
Unfortunately, I was still able to find a few dropouts, but much better than before. I think I can live with that for now.
I really don't know why "midiin" behaves like this and swallows notes, at least on my machine. It should not matter whether it gets a clock or not. So I don't understand what MIDI clock has to do with note ons and offs in this situation.
As soon as I discover something new on the box, I will write here again.
And as for my microfreak problem, I'll look into that later.
So thanks again for the great help and for taking the time.
Best regards,
Peter
Source Audio
7月 12 2024 | 8:28 午前
can you set bpm to absolute minimum to ease things a bit ?
I could not imagine that cycling did not really update midi objects
to face that problem, but you mentioned your wife's computer
does not exibit any dropouts using Max.
What is the difference ? Mac vs Win ?
If notes arrive without dropouts in other apps, then yamaha is not to blame,
even that it SHOULD offer to turn midi clock on or off.
midi clock is top priority in midi stream.
_Antonio
7月 17 2024 | 12:58 午前
Hi all!
I think I'm having a related issue with my Arturia Keystep 37. When the sequencer or the arpeggiator is on, [middiin] systematically misses every note on. If seq/arp are off, playing the keyboard works as expected. The difference is that in the former case Max is receiving midi clock from the Keystep, whereas in the latter it's not. As mentioned before, this seems to be happening only in Max (everything is ok in MIDI monitor and in Logic). What's interesting is that this happens on my (Intel) Macbook Pro running Sonoma, but not in my old iMac running High Sierra (same version of Max in both cases).
Source Audio
7月 17 2024 | 6:31 午前
That is interesting observation, I allways thought this new systems
are blown up unusable resources waisting nonesense constructs.
It can simply be that some backgroung processes interfere with midi server.
Or that apple managed to degrade it.
sugoza
7月 18 2024 | 3:50 午後
Hello, my computer is very old. Macbook Pro from mid 2014. The system runs on Big Sur. But I still can't imagine that there are any problems, because it's just MIDI. But who knows. I have a lot of MIDI devices connected in the studio. But I've also tried testing the Yamaha box with my laptop without anything. But it was the same error.
My wife has a newer computer. Macbook Pro from 2017 with Catalania. And it works perfectly.
It is funny, if I set the BPM to 30, I can detect a few or no dropouts. But if I set the tempo to 300, there are a lot of dropouts again, both note on and note off.
thanks,
peter
_Antonio
7月 18 2024 | 7:49 午後
My wife has a newer computer. Macbook Pro from 2017 with Catalania. And it works perfectly.
Ok. So now we know that this happens in macOS > 10. And so far in Intel macs. I've found another app (Midi pipe) where the same happens: misses every note on if it is receiving midi clock. So maybe it's a CoreMidi issue?