MIDI input overload bug w/ built-in touch Keyboard/Pads when using an external audio interface
Hi! I'm new to the forum. I'll try to be as concise and clear as possible to describe the pretty big issue I've just uncovered:
*************************
BUG DESCRIPTION SUMMARY:
*************************
When manually playing notes repeatedly (example: 1/16th notes between approximately 100 and 120 bpm) with Drambo's built in touchscreen keyboard or pads controller while SPECIFICALLY running the app with an iPad connected to an EXTERNAL CLASS COMPLIANT AUDIO INTERFACE, the midi input generated by pressing the touchscreen repeatedly appears to occasionally "overload" something in Drambo temporarily, which ends up causing nasty audible irregularities in the audio playback. Some of the notes end up occasionally being played back in a staggered manner, with their audio playback randomly delayed and syncopated, or not playing at all.
*************************
EQUIPMENT USED THROUGHOUT TESTING:
*************************
- iPad 11" M2 128gb
- iPadOS: 17.1.1
- Elektron Digitakt as class compliant audio interface
- Elektron Digitone as class compliant audio interface
- RME FireFace UCX as class compliant audio interface
- UNI accessories Union PRO + USB-C 8 in 1 Hub
- Apple USB-C to Headphone Jack adapter
- Settings: 48kHz, 128 samples
*************************
DETAILED DESCRIPTION:
*************************
First, here are some scenarios I've identified where:
THE PROBLEM DESCRIBED >>> DOES NOT OCCUR <<<:
a. when the ipad is connected directly with a simple Apple USB-C to Headphone Jack adapter
b. when the ipad is NOT connected to anything
c. when using an EXTERNAL midi controller, such as AUM's built in keyboard to trigger Drambo audio generator built-in modules (example: FM Operator) and when the iPad is CONNECTED to any of the 3 AUDIO INTERFACES mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section. (***VERY IMPORTANT***)
d. when using an EXTERNAL midi controller, such as AUM's built in keyboard to trigger AUV3 instruments loaded in Drambo, and when the iPad is CONNECTED to any of the 3 AUDIO INTERFACES mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section. (***VERY IMPORTANT***)
---------------------------
Second, here are the scenarios I've identified where:
THE PROBLEM DESCRIBED >>> DOES OCCUR <<< (reproducible with a 100% success rate):
a. any of the 3 audio interfaces mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section are connected to the ipad and:
i. Drambo is in Host mode + using Drambo's built in touchscreen keyboard or pads controller to trigger notes repeatedly from built-in Drambo "Generators" modules (example: FM Operator) OR AUV3
ii. Drambo is in AUV3 mode + Drambo's built in touchscreen keyboard or pads controller is being used to trigger notes repeatedly from built-in Drambo "Generators" modules (example: FM Operator)
iii. Any of the selectable sample buffers values have been configured + Drambo's built in touchscreen keyboard or pads controller is being used to trigger sounds (128 or 1024 samples, in my tests it had no impact on the problem)
iv. Any of sub-elements "i" to "iii" mentioned above are attempted after a fresh restart of Drambo as a host and/or AUM and/or an iPad shut down and restart and/or powering any of the 3 audio interfaces mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section OFF and back ON.
*************************
STEPS TO REPRODUCE:
*************************
1. Connect any of the 3 audio interfaces mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section to the iPad 11" M2 128gb. (probably any external audio interface will exhibit the problem)
2. Turn iPad 11" M2 128gb ON. (Restarting it in the first place was not mandatory)
3. After the iPad has finished booting, turn the audio interface connected to the iPad ON.
4. Unload any app from the iPad's RAM. (not mandatory)
4. Launch Drambo in Host mode.
5. Assign a sound generator to Track 1 in Drambo, such as "FM Operator" or an AUV3, such as Twin 3 (the specific sound generator chosen, or specific track doesn't really matter but playing staccato or using plucky sounds will make the issue much easier to hear).
6. Open the BUILT IN DRAMBO PAD (or keyboard) CONTROLLER.
7. Proceed to tap on the BUILT IN TOUCHSCREEN pads in a repeated "machine gun" manner (example: regular 1/16th notes at around 120 bpm) continuously (the issue should be audible within 10 to 30 taps on the pad on average.
8. Eventually SOME notes are either going to:
a. be delayed relatively to the timing of hitting the pads on the touchscreen
b. Rarely feel as if they didn't ring at all despite the touchscreen press
c. Occasionally seem as if their attack volume was fluctuating, as if the start of the note had been muted
SIDE NOTE:
- This problem can also be reproduced even when using Drambo as an External Midi controller to trigger AUV3 hosted instruments in AUM, whereas the problem is non existent when using any other controller such as AUM's built-in keyboard.
- Launching Drambo's sequencer while running this test doesn't appear to have any impact on the problem.
- Attempting to tap the same pad with 2 fingers (index + middle), or any two distinct pads causes the problem without distinction.
- The problem also occurs with Drambo's touchscreen Keyboard controller, not just the pads
- There is a high level of variability with each attempt of this test so depending on your attempt, it might take longer to notice issues, whereas at times the issue can become apparent much quicker, by far the most noticeable scenario I've witnessed is that some notes are randomly delayed.
- triggering a higher pitched sound might help hearing the timing errors in audio playback better while running this test, even though the timing inconsistencies can be very obvious at times, regardless of pitch. I estimate these timing inconsistencies/stutters occasionally as high as 60-100ms.
*************************
FINAL OBSERVATIONS:
*************************
- Seeing as though the common denominator for this issue appears to be connected to the midi data generated by Drambo's touchscreen keyboard/pads surface since the problem disappears when using an external controller, the Drambo touchscreen keyboard/pads surface implementation itself is likely to be where the problem might be originating from.
- Seeing as though all 3 of my relatively high end audio interfaces have made the problem apparent, it is extremely improbable that my equipment is the issue. I imagine the problem must exist with most if not every class compliant audio interfaces.
Thanks for having a look at this :)
Comments
Have you taken steps to assure that there is no Midi Loop going on? What happens if you disable outgoing MIDI on the track?
It's what I thought about initially. I first went into Drambo's settings and tested disabling all Midi inputs, it didn't change anything to the behaviour. Just for the sake of clarity I'd like to emphasize that I've added a specific "STEPS TO REPRODUCE" section in my initial post.
Also, if I try to put myself in the shoes of someone else reading my original post especially considering its very dry nature, I could easily think after speed reading through the post and tapping the pads 4-5 times that there is no problem, whereas in fact there is a problem but I might not have tried to interact with the pads long enough to witness the problem.
For example, at times i could hit the same pad more than 30 times without encountering the problem once. The next moment, if I for instance close everything and start a fresh AUM session and just load Drambo, I could notice delays as high as 120-150ms after hitting the pads 10 times not particularly quickly. Then I might try again with Drambo in host mode and immediately notice the issue with just 5-10 taps. There really is a lot of variability with this issue.
Sometimes the delays can be low enough that someone who wouldn't be super analytical about this might feel that something was a bit off timing wise but think that they were just inconsistent with their playing whereas in fact the bug occurred.
Edit: Oh and just one last reminder, in order to encounter this bug there MUST BE an external AUDIO INTERFACE connected to the ipad (M2 chip)!
Does this bug happen if you bypass the USB-HUB and connect the audio interface(s) directly to the iPad?
A USB-C to USB-B cable may be needed for direct connection to the iPad from the mentioned audio devices.
Not all USB-HUBs behave the same…
I have tested your procedure with two of my audio interfaces (Audient ID4mk2 and Steinberg UR-242) connected to my 11” M1 iPadPro both directly and using LinQ USB-C dongle powered with a 65W USB-C PD charger and can not reproduce this bug…
Thank you for having taken the time to test this with your audio interfaces :)
I have also thought that not excluding the hub from the equation caused a weak link in my test, but unfortunately I do not own a USB-C to USB-B cable.
I will say however that
contributes to reinforce that the problem is tied to the Drambo controller surface implementation in some way. I also use the "Anker USB-C GaN II 100W Charger" and the "Uni 100W USB-C to USB-C Fast Charging Cable" in the setup.
The main difference I can see between our setups is that I use an M2 iPad Pro whereas you use an M1 one. On one hand I'm glad you're not experiencing this problem but on the other hand it's bad news for me because it means this bug is harder to reproduce :(
Hopefully someone with an M2 iPad Pro with an external audio interface could try to reproduce this and share their findings.
Also maybe one last bit of information if it can help: I'm testing with "Sugar Bytes drumcomputer" inside Drambo (Host mode), and when I'm using drumcomputer's built in 8 pads and tap the same sound repeatedly for 1 minute straight (1/16th notes at a bpm of 105-120 with or without activating the sequencer), there is NO PROBLEM WHATSOEVER. However, when i start using Drambo's pad controller to trigger the AUV3, then I start noticing the irregularities again typically within 20 pad hits (I could be alternating between 2 separate pads triggered with the index and middle finger of my right hand or just hitting the same pad with my middle finger repeatedly for example).
Sometimes, when using Drambo's built-in pads, it can take around 30 hits or maybe even up to 50 hits on the same note until a note isn't heard at all, or until a note is delayed to a varying degree that i estimate anywhere up to 150ms. Other times it can take just 10 hits for me to detect the problem (could be a delay in the note, or the perceived absence of a note being played at all).
There is a strong correlation between the RATE at which the pads are hit and the likelihood that there will be a problem. For example:
If I tap the same pad repeatedly hitting 1/16th notes at a bpm of 80, out of 100 pad hits I might hear a delay or a note might not ring just once, even though the UI still lights up.
BUT
If I tap the same pad repeatedly hitting 1/16th notes at a bpm of 120, I am MUCH MORE likely to hear a problem maybe once every 10 to 20 pad hits.
Hopefully it can be imagined with the example just described above that the issue can really easily go unnoticed unless the user is:
There is still a possibility that the issue may be generalized and not device specific but that it is much harder for people to detect than I anticipated or hoped, although I have doubts about that because when a note flat out doesn't ring (even though it might take multiple attempts of 60 consecutive pad hits for people to detect this event even just once), I feel like most people could easily detect that a problem occurred.
Bottom line the implication of this issue is that it makes live recording/playing inconsistent and therefore can create serious distraction that can hinder the music creation process, or cripple a user's progression if the user is actively practising pads/keyboard playing with the touch surface of the iPad.
Settings: 48kHz, 128 samples
you need to set the buffer higher
drambo doesn’t like 128 samples at all
try 256 or 512
As stated in my original post:
[THE PROBLEM DESCRIBED >>> DOES OCCUR <<< (reproducible with a 100% success rate):]
" iii. Any of the selectable sample buffers values have been configured + Drambo's built in touchscreen keyboard or pads controller is being used to trigger sounds (128 or 1024 samples, in my tests it had no impact on the problem)"
and also:
[THE PROBLEM DESCRIBED >>> DOES NOT OCCUR <<<:]
"
c. when using an EXTERNAL midi controller, such as AUM's built in keyboard to trigger Drambo audio generator built-in modules (example: FM Operator) and when the iPad is CONNECTED to any of the 3 AUDIO INTERFACES mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section. (***VERY IMPORTANT***)
d. when using an EXTERNAL midi controller, such as AUM's built in keyboard to trigger AUV3 instruments loaded in Drambo, and when the iPad is CONNECTED to any of the 3 AUDIO INTERFACES mentioned in the "EQUIPMENT USED THROUGHOUT TESTING" section. (***VERY IMPORTANT***)
"
Not able to reproduce this with a12 chip and motu interface
get the cable to make really sure it’s not the hub
if that is out of the loop it must be something with the m2 chip
the midi works if you use some other software to trigger it, (odd) 🤪
not sure I understand that
so the au works, but the standalone version of drambo doesn’t?
not sure what aum does
need keyword drambo standalone or drambo au
I just ran another test to reinforce my current "theory" (which, to reiterate, is that the MIDI input generated by pressing Drambo's built-in touchscreen PADS OR KEYS repeatedly appears to occasionally "overload" something in Drambo temporarily, which ends up causing nasty audible irregularities in the audio playback).
The test is:
I can tap the virtual MIDI controller surface of GeoShred (or Velocity Keyboard) within Drambo for multiple minutes without a single error or delay occurring in the audio output. In fact, no error occurs at all, EVER. This statement alone should dispel any allusion to my USB-C hub being the problem or the sample buffer not being large enough.
If I then reassign the MIDI TO CV input to the Drambo track MIDI output, which will allow me to use Drambo's PADS/KEYS control surface to trigger audio output, I systematically run into the problem described in my original post.
IMPORTANT***
I really appreciate anyone who takes the time to read my post, especially considering how lengthy it is. With that said however I would really be thankful if anyone attempting to reproduce this bug who would report not being able to could please include the exact context in which they ran the test.
For example:
If someone responds to this thread without explicitly giving the specifics of how they attempted to reproduce the issue, as someone trying to arrange a thorough transmission of usable information to maximize the chances that this problem will be addressed, I am left with the uncertainty of being able to clearly identify whether or not the person who attempted to reproduce the issue did so in a capable manner.
If someone was to write back something like this:
"I happen to have a [just an example:] Digitone or a Digitakt as a class compliant audio interface coupled with an iPad Pro M2 and tried to reproduce your bug. I opened Drambo in host mode as you suggested with FM operator, I then tapped the pads during 10 separate sessions of approximately 60 taps each at 1/16th notes at around 100bpm. I found out that .... [just an example:] the control surface response was absolutely flawless"
Then it would be absolutely clear to me that if the person doesn't have the issue what I'm experiencing is not generalized. Until that happens my opinion is that nothing can be concluded. Hopefully that will change :). Help is greatly appreciated!
So you didn’t turn the buffer up, as suggested?
I tried every single buffer value choices, which changed nothing. It would have made no sense either for it to change anything because the problem is gone when using a different virtual midi controller, in Drambo standalone directly.
Short buffer causes hiccups that seem random, sometimes hiccups sometimes doesn’t …
“appears to occasionally "overload" something in Drambo temporarily“
sounds quite like that
I understand that it appears as such lol, which is why I've thoroughly tested the 1024 samples buffer size before posting anything at all. It took a considerable amount of energy for me to write all this to be as thorough and clear as possible, which is why I tested things thoroughly before starting this whole bug report process. I really appreciate your desire to help, however I think in this case it might be preferable if someone with equipment similar to what I have could join the discussion, whether it be a Beepstreet developer or a community member :)
I haven’t seen anybody in the club with an m2 iPad until your post.
they were just released a few month ago …?
never happened to me on m2 mac either, but I don’t enter notes by clicking on the virtual keyboard/pads (like that)
The exact name of my iPad is: iPad Pro 11" 4th generation 128gb
This model was released on October 26 2022, and uses an Apple silicon M2 processor, just like the iPad Pro 12.9" 6th generation. I acquired it on November 24th 2023.
@groovegcs
Can you screenshot your midi settings for both midi input and output in dRambo.
@gravitas I sure can!
I found out something amazing. I randomly clicked on another thread upon doing a bit of research with the keywords "Midi feedback Drambo" once I realized that even if I disabled the MIDI feedback "CONTROL" option, once I killed and relaunched the app it would come back ON (green). That led me to some screenshot that I saw of someone showing an Audio Unit MIDI monitor tool inside Drambo.
Then, by randomly browsing through the list of devices available in Drambo I actually saw that there was a MIDI monitor module available.
Now here comes the good part: by some insane alignment of the stars (LOL), queuing a MIDI monitor module in the chain ELIMINATED THE PROBLEM!!! (There's still a bug but at least I have a usable temporary fix now)
Also I could make a video to showcase this using my phone to film it, but I'm not sure if the forum can host it since I don't have much experience with the forum tools.
There, I actually went through the exercise of making a YT video, it's DIY style but it works :D
https://youtu.be/y_8xDKKKFJM
Any time I stop hitting the pads and point at the screen, it's to signify that an audible anomaly occurred. In this specific recorded session, there were 4 audible issues:
Then, I add the MIDI monitor to the track and run the test again, which makes the issue go away.
@samu Maybe you can have another look at the issue now that I have a video to show exactly the problem and reconfirm whether or not you're experiencing the issue :)
@groovegcs I could not reproduce ths ‘bug’ on my M1 iPadPro…
(Could be because I’m running a beta!?).
I did find a way to re-trigger the pads even faster though by swiping across four pads in a circular motion.
Maybe @giku can take a look at this as well?
Cheers!
the an kick is a really bad audio example, I dont hear it happening in the video
an kick is the feedback loop of the 808 , decay "sums up" over time, if triggered fast enough - that changes the sound - its supposed to be like that (maybe its this what you are experiencing?)
does it happen when u play a static sample like a clap or something? (so you dont get confused by changing sound)
midimonitor in the chain doesn't change a thing ...
it just shows what's going on
so after watching it 5 times , I get the missed trigger
hihi 😂
I have an idea how this happens
it goes as this
please clean your iPad screen and wash your fingers!
and try again with a sample
I get unresponsive screen when display is dirty ;)
@samu a big thanks for having given it another shot. The fact that this could not be reproduced on your device despite an audio interface connection and an M1 iPad really goes to show how sensitive these things can be.
@lala I think what you missed after watching my video is that the problem DISAPPEARS as soon as I add the MIDI Monitor module in the chain. The iPad screen had been cleaned before taking the video.
If you pay close attention to the video you'll see that I don't interrupt my playing after adding the module when I start playing again at 1:22, until I momentarily stop to readjust my fingers to use another technique to tap the pads even faster at 1:35. (Remember that I'm holding my phone freely in my left hand to film the video, hence why I seem so slow once I decide to move my hand around the screen)
The last part of the video, starting at 1:10 until the end is intended to demonstrate explicitly that the problem NO LONGER OCCURS once the MIDI Monitor module is added in the chain. This has nothing to do with the touch screen being unresponsive.
There is nothing wrong with Drambo's sound module itself. As I explained in my original post, I can reproduce this bug with any AUV3 instrument, not just Drambo sound generator modules.
Also, I think I get why understanding my video may have been a little difficult at first, it's because I didn't state clearly in the video that I was making NO significant timing mistakes as I was tapping the pads repeatedly. This implies that whenever I stopped playing, it was because I had noticed that the "system had failed".
we can't reproduce this
it must be a thing that only happens on this generation of device 🤷🏻♂️
midi monitor apparently fixing the issue really makes me scratch my head 🤯
@samu & @lala
OMG ... I just found out what was causing the problem!!!!!!
... It was my Logitech G Pro USB 2.0 wireless transmitter connected to my USB-C Hub.
What happened was I forgot to turn my Digitone Audio Interface ON when launching Drambo just now to test the problem further while my iPad was connected to my USB Hub, and when I heard sounds coming out of the iPad's speakers directly, I mindlessly kept on tapping the pads and noticed the ISSUE WAS STILL THERE even though my audio interface was not involved.
This then led me to run other tests where I disconnected/reconnected stuff in other configurations and realized the problem was gone as soon as I removed my mouse transmitter from the route... The funny part is I don't care about my mouse being connected to my iPad one bit, plus worst case scenario I can just use the mouse with a direct wire if i really need to connect it to my iPad eventually.
I'm so relieved the problem was not my USB-C hub directly, this thing was ultra expensive. Precious lessons were learned throughout this troubleshooting process. Thanks to both of you for your time and help
PROBLEM SOLVED!
u r welcome
@groovegcs so it’s basically user error?
Topic closed.
@gravitas Not quite. Under normal circumstances Drambo's control pads/keys were the ONLY situation in which I was encountering this disturbance, so this brings the question of whether or not I'm at fault for attempting to use a state of the art wireless mouse (Logitech G Pro Wireless) in wireless mode with my iPad?
At the end of the day, I'm just glad I managed to not only isolate what was causing the problem, but I was also able to find a workaround (which was to connect a Midi monitor module in my Track chain).
there was additional hardware involved you did not disconnect.
User error. happens to all of us. ;)
next time you know better.