You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a workaround that would keep the timestamps? It seems they are used only for sysex messages, would it be OK to put those calls behind a feature flag so that they can be ignored when not needed? I can submit and test a PR if that's the direction to take.
The text was updated successfully, but these errors were encountered:
I think the timestamps are not only used for sysex messages (at least AudioConvertHostTimeToNanos is called in any case). But I agree that it would be great to find a workaround for the private symbols in order to allow iOS app publishing.
I'm open for a PR that disables these calls based on a feature flag (there are already two feature flags related to timestamps, so adding another one seems okay). It might even make sense to reuse the avoid_timestamping feature that's currently used for input on ALSA. However, because Cargo features shouldn't have negative semantics, it's probably better to have a default-on feature that can be opted out of (and is by default disabled on iOS). Maybe coremidi_receive_timestamped analogous to coremidi_send_timestamped?
If anyone knows an alternative solution that doesn't use the private symbols, that would be great too.
When publishing an app on iOS through XCode / App Store Connect, I get rejected because of using private symbols:
If I remove all calls to these methods and always set the timestamps to 0, publication is successful.
It seems they are available on macOS, but not on iOS https://developer.apple.com/documentation/coreaudio/1422393-audioconverthosttimetonanos.
Is there a workaround that would keep the timestamps? It seems they are used only for sysex messages, would it be OK to put those calls behind a feature flag so that they can be ignored when not needed? I can submit and test a PR if that's the direction to take.
The text was updated successfully, but these errors were encountered: