With just "Set Channel Volumes to default" disabled?
Synthesia on iPadOS 17.2 via BT freezes(?) FP-10
When describing problems, always mention your OS and game version (shown at the bottom of the title screen).
If your keyboard has USB or MIDI ports, there is a tremendously high chance (>99%) it will work with Synthesia. See what you'll need on the keyboards page.
If your keyboard has USB or MIDI ports, there is a tremendously high chance (>99%) it will work with Synthesia. See what you'll need on the keyboards page.
Yes... But the weird thing was it also works with, that ON and any two of the other 5 settings OFF.
Literally...pick two at random (of the five defaults) and turn them off...it works!
Slightly strange.
Just to reiterate. I turned the piano off for each setting change, made sure the settings remained when it started again.. played the piano while in settings. Then went to free play and checked there.
Restarted piano, went to free play...checked again.
Literally...pick two at random (of the five defaults) and turn them off...it works!
Slightly strange.
Just to reiterate. I turned the piano off for each setting change, made sure the settings remained when it started again.. played the piano while in settings. Then went to free play and checked there.
Restarted piano, went to free play...checked again.
I checked again. I found out that in rare cases the piano crashes even if you turn off all options when you go to “Hands, colors and instruments” screen and listen to certain instruments of some complex midi files. For example there is an “Electric Guitar (jazz)” on midi channel 4. When I play this track the piano crashes. But when I listen to another “Electronic guitar (jazz)” on channel 5 it works fine.
Apart from that for 99% of my songs it is sufficient to turn off
-‚All Controllers Off’ on all channels
- Set channel volumes to default
These two are critical for me.
Apart from that for 99% of my songs it is sufficient to turn off
-‚All Controllers Off’ on all channels
- Set channel volumes to default
These two are critical for me.
Last edited by Stef231 on 04-24-24 2:12 pm, edited 2 times in total.
Alright, it sounds like the real culprit might be "trying to send too many messages to a Roland keyboard too quickly". The between-screen resets are particularly "chatty" times. You figure each one of those options sends sixteen messages (one to each of the 16 MIDI channels), so if four are enabled that's 64 messages all at once in a burst. So it sounds like reducing the size of the reset was more of a band-aid fix than solving any root cause.
In the "complex MIDI file" case you not only get a reset when you stop the preview but it also happens to send a Note Off for anything that was currently playing, so that might have pushed the keyboard just over the edge.
The better answer for Synthesia than blasting out 48 or 64 messages all the time would be to keep track of what is actually being sent to the device. If there haven't been any Bank Select messages sent to any channels, then we don't need to reset any banks. If notes were only sent on channels 1 and 2 then we don't need to send "All Notes Off" and "All Sounds Off" to channels 3 through 16. If Synthesia kept track of the "dirty" MIDI state and only restored the things that changed, a reset might average two or three messages between screens instead of sixty or so.
That should be enough to make the Roland keyboard problem all but disappear (regardless of the new reset settings).
As for the reason why it only started happening after a particular iOS update, I have no idea. I know they used to automatically bundle several individual MIDI messages into a larger, single BLE-MIDI packet. (Contrast this with Android where you always get a BLE-MIDI message for each MIDI event so long as you're sending them one at a time in your code.) Maybe some of Apple's recent under-the-hood work to support MIDI 2.0 changed some assumptions and now they follow Android's behavior of sending more Bluetooth messages? Maybe we're not hitting Roland's limit on their internal MIDI message buffer but rather their internal Bluetooth data buffer? (Although I remember someone said this also happens over USB... hmm.)
In the "complex MIDI file" case you not only get a reset when you stop the preview but it also happens to send a Note Off for anything that was currently playing, so that might have pushed the keyboard just over the edge.
The better answer for Synthesia than blasting out 48 or 64 messages all the time would be to keep track of what is actually being sent to the device. If there haven't been any Bank Select messages sent to any channels, then we don't need to reset any banks. If notes were only sent on channels 1 and 2 then we don't need to send "All Notes Off" and "All Sounds Off" to channels 3 through 16. If Synthesia kept track of the "dirty" MIDI state and only restored the things that changed, a reset might average two or three messages between screens instead of sixty or so.
That should be enough to make the Roland keyboard problem all but disappear (regardless of the new reset settings).
As for the reason why it only started happening after a particular iOS update, I have no idea. I know they used to automatically bundle several individual MIDI messages into a larger, single BLE-MIDI packet. (Contrast this with Android where you always get a BLE-MIDI message for each MIDI event so long as you're sending them one at a time in your code.) Maybe some of Apple's recent under-the-hood work to support MIDI 2.0 changed some assumptions and now they follow Android's behavior of sending more Bluetooth messages? Maybe we're not hitting Roland's limit on their internal MIDI message buffer but rather their internal Bluetooth data buffer? (Although I remember someone said this also happens over USB... hmm.)
Yes, I can confirm that's my case as well. Sorry, I'm a lousy tester
I was so focused on the "turn off as few things as possible" I totally missed that part of testing.Also I have found one of my MIDI files crashes the app constantly when I try to play it (although it plays in the song list). I sent a couple of debug reports via the system prompt, but that's off-topic in this thread.
Alright, a new build (10.10.5966) just went up. Curiously there was zero review time; it was approved immediately. And I did the "notify testers" step right away this time.
Sorry about the crashes. That's in some other in-progress code for an unrelated feature that wasn't quite ready to go out the door yet. I slapped some flex tape on it so hopefully it won't be so crashy until I get a chance to actually wrap it up.
The more interesting change is a new option at the top of the reset choices list: "Only reset things that've changed". It's on by default but if you beta folks have changed anything on that screen that probably won't get picked up automatically. If you could, please click the reset-to-defaults button on that screen and let me know if your Roland keyboards freeze ever again. They shouldn't.
The new option keeps an eye on every MIDI message sent to a device and when it's time to reset, it will only send messages to those channels and of those types for the MIDI state that has actually been changed. For the rather simple built-in songs this means a reset is now an average of 2 or 4 messages instead of 64. So as long as "Only reset things that've changed" is enabled it should be safe to leave the others on without the danger of flooding the digital piano with too many messages anymore. Best of all this means I don't need to disable any of the reset options by default anymore. So the resets will still be comprehensive, just a lot more polite to the device now.
Sorry about the crashes. That's in some other in-progress code for an unrelated feature that wasn't quite ready to go out the door yet. I slapped some flex tape on it so hopefully it won't be so crashy until I get a chance to actually wrap it up.
The more interesting change is a new option at the top of the reset choices list: "Only reset things that've changed". It's on by default but if you beta folks have changed anything on that screen that probably won't get picked up automatically. If you could, please click the reset-to-defaults button on that screen and let me know if your Roland keyboards freeze ever again. They shouldn't.
The new option keeps an eye on every MIDI message sent to a device and when it's time to reset, it will only send messages to those channels and of those types for the MIDI state that has actually been changed. For the rather simple built-in songs this means a reset is now an average of 2 or 4 messages instead of 64. So as long as "Only reset things that've changed" is enabled it should be safe to leave the others on without the danger of flooding the digital piano with too many messages anymore. Best of all this means I don't need to disable any of the reset options by default anymore. So the resets will still be comprehensive, just a lot more polite to the device now.
Thanks so much! I updated the beta and did a reset to default, enabling the top half of those MIDI reset switches, incl. things that've changed. I did a quick round of screens and MIDI files: no crashes of Roland nor Synthesia whatsoever! Of course I'll give it a proper whirl later on, but so far it looks you nailed the problem 
