Hi, First, thank you for the package, it helps a lot.

in the current version, you treat devices only and not ports. there might be devices that have only input or only output ports (like a metronome) also there might be a need to use different input and out put devices. currently, sending data will be forwarded to all opened devices, with the ability to target specific device or port. the same is true for input, all inputs from all connected devices are forwarded to the application and it cannot tell where the data came from.

the problem rises when used in MacOS where you try to send data to IAC driver, the data is echoed back to the application, so you cant tell if it came from a different device or just an echo of the sent data.

to conclude, I think there API should target specific ports and should include port info or handle on all operations.

another issue is with timing.

currently, there is no way to tell the time a midi message was received from the midi device (of course we can take the time from the computer or mobile device, but it is a higher level clock and not device driver clock), but it is not that a critical issue.

but when sending data, a very important element is to tell the device or the device driver, when to play the data.

currently, we have to time all sends through application level timers, these timers are very sensitive to every activity on the mobile or the computer. I know the the MIDI spec and the implementations of the drivers on the platforms, enable the developers to specify the time to play, but this option is exposed to the developer in your plugin.

I think that it will help a lot to add this parameter to the SendData API.

Thanks again Moshe

I have tried the example v 0.3.7 on iOS and MACOS and it works fine.

It fails to show any devices on Android. The app screen is empty with no devices listed. Using SDK 28 and 29 on android 10 on a real device and emulator.

D/FlutterMIDICommand( 8881): tryToInitBT D/FlutterMIDICommand( 8881): Show rationale for Location D/FlutterMIDICommand( 8881): devices [Landroid.media.midi.MidiDeviceInfo;@62e62ae D/FlutterMIDICommand( 8881): list [] I/flutter ( 8881): Error showRationaleForPermission

On iOS (Android is fine) a device will not show in the list of devices on list refresh.

Device will initially show on connection using startScanningForBluetoothDevices, after connectToDevice and a successful connection, the device will disappear out of the list of available devices.

Connected device will still function as if it is still connected, but is not longer in the list of devices.

With this pull request, it is possible to create virtual MIDI devices on iOS. These virtual MIDI devices show up in other apps. Other apps can now send and receive MIDI to or from your own app using these virtual MIDI ports.

While merging this pull request, please do the following steps:

1. Merge my previous pull request to flutter_midi_command_platform_interface.git
2. Edit pubspec.yaml and replace the references to

• [email protected]:gatzsche/flutter_midi_command_platform_interface.git as well
• [email protected]:gatzsche/flutter_midi_command_linux.git

Let me know if you have any questions.

Gabriel

I checked the received MidiPacket.timestamp. Its range seems 0 to 255.

But MIDI specification has 13 bit, so the range is 0 to 8192.

I thought, https://github.com/InvisibleWrench/FlutterMidiCommand/blob/644dd94431eda60724f5ffda4103ac5e096dd263/ios/Classes/SwiftFlutterMidiCommandPlugin.swift#L1043 tsHigh type is UInt8. So we may cast it before shift operation. timestamp = UInt64(tsHigh) << 7 | UInt64(tsLow)

Using: flutter_midi_command: 0.3.0 flutter: 2.0.4 Xcode: 12.4

Reading the iOS native MIDI docs, I found out the packet's timestamp is a value meant to be multiplied by some system factor.

I figured maybe the MidiPacket already did that conversion so the timestamp would be at the same unit regardless of the platform. However, that does not seem to be the case.

So, my question is: does the iOS timestamp need to be multiplied by a factor to be usable? How can I get that factor?

I was playing around with the example given and, in Android, it works fine but in iOS it does not even launch. I have simplified the sketch several times but the result remains the same. Moreover, I created a new project and just updated the xcode min iOS version to let the package work and included de package in the pubspec.yaml and then the flutter example app does not work anymore. Any idea on what could be happening?

Hello, first thanks for the package, very useful.

I found a problem in the following code snippet(File: FlutterMidiCommandPlugin.kt, Line: 389, Column: 34).

Error: Inferred type is String? but Any was expected.

fun listOfDevices() : List<Map<String, Any>> {
    var list = mutableListOf<Map<String, Any>>()

    val devs:Array<MidiDeviceInfo> = midiManager.devices
    Log.d("FlutterMIDICommand", "devices $devs")
    devs.forEach { d -> list.add(mapOf(
            "name" to d.properties.getString(MidiDeviceInfo.PROPERTY_NAME),
            "id" to d.id.toString(),
            "type" to "native",
            "connected" to if (connectedDevices.contains(d.id.toString())) "true" else "false",
            "inputs" to listOfPorts(d.inputPortCount),
            "outputs" to listOfPorts(d.outputPortCount)
          )
    )}

It must be something related to a kotlin update where the type Any is not used for null, but Any? works.

Again, thanks for the package.

When calling MidiCommand.devices, I have always had "Network Session 1" in the list of devices but now "Network Session 1" is not found when running on ioS Simulator and Android Simulator as well as real iOS devices. This causes problems now because I cannot debug application which used that interface to connect to MIDI devices connected to the mac.

Actual USB MIDI devices still appear as wellas Bluetooth devices.

Using v0.2.4

Trying to build example app to run on macos. Does not seem to work using 0.2.4 on macos

Flutter (Channel dev, 1.24.0-6.0.pre, on Mac OS X 10.15.7, XCode 12.1

[!] CocoaPods could not find compatible versions for pod "flutter_midi_command": In Podfile: flutter_midi_command (from Flutter/ephemeral/.symlinks/plugins/flutter_midi_command/macos)

Specs satisfying the flutter_midi_command (from Flutter/ephemeral/.symlinks/plugins/flutter_midi_command/macos) dependency were found, but they required a higher minimum deployment target.

When Android version is higher than 6.0, Bluetooth function cannot be called normally, and location permission is required

  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"></uses-permission>
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission>

Reproduce:

• connect BLE device
• send data to that device
• BLE SysEx data never gets to the device
• All midi messages from the devices does in fact work

Everything works over USB to the device, but not BLE.

Hoping that what I've experienced is related to the android.media.midi bug described here. They mentioned on December 23rd that it's fixed and "will be available in a future build".

This link above says less than 18 or 19 bytes should be working, but for me it's not. I tried breaking it up into chunks of 10 or less bytes.

Every now and then, I'd say about 10% of the time I fresh open my app, I can send data and it does work. When it does work, the BLE midi device shows up twice in the list of devices. Very strange.

Not sure if this affects performance, but I have been getting crashalytics errors relating to a missing cancel method on Android. The errors only seem to be generated while the app is in the background and are as follows:

MissingPluginException(No implementation found for method cancel on channel plugins.invisiblewrench.com/flutter_midi_command/rx_channel). Error thrown Instance of 'ZM'.

When build with targetSdkVersion 31 and run on Android 12 the app crashes, after approving the location permissions by the user. The reason seems to be that the permission android.permission.BLUETOOTH_SCAN is not requested in FlutterMidiCommandPlugin at all.

See android documentation for the changed requirements: https://developer.android.com/guide/topics/connectivity/bluetooth/permissions

A workaround is to set targetSdkVersion of the app to a maximum of 30 (Android 11). Then the legacy layer avoid the app crash and the permissions are correctly handled.

Hi everyone,

I have made an app for my self designed for desktop and mobile.

Works perfectly on desktop, but on iOS it am not able to send MIDI messages to my connected Bluetooth MIDI device.

I can receive messages and display them, but cannot send them to the device.

Have you experienced something similar?

Has anyone had luck using Bluetooth Midi with this package between an Android phone and Macos?

Steps I have been following:

1. Bluetooth pair phone to macbook
2. open Audio Midi Setup on mac and enter bluetooth settings
3. advertise bluetooth midi device
4. open Flutter Midi Command example app on phone and search for bluetooth devices -> macbook is visible
5. connect to macbook, which "appears" to be successful
6. check midi monitor app and/or ableton for any midi devices -> None visible!

if i run the example app in debug mode it will only show reoccuring onScanResult messages.

Any tips? Could there be a connection bug that I could try and find in the example app or Kotlin code?

edit: I dont have an iOS device to test it there. This comment is only regarding my Android experience.

Currently there is no way for a platform plugin to indicate that it doesn't support bluetooth, so on Linux for example this causes the following exception:

[ERROR:flutter/lib/ui/ui_dart_state.cc(198)] Unhandled Exception: UnimplementedError: get onBluetoothStateChanged has not been implemented.
#0      MidiCommandPlatform.onBluetoothStateChanged
package:flutter_midi_command_platform_interface/flutter_midi_command_platform_interface.dart:47
#1      MidiCommand._listenToBluetoothState
package:flutter_midi_command/flutter_midi_command.dart:49
#2      new MidiCommand._
package:flutter_midi_command/flutter_midi_command.dart:28
#3      new MidiCommand
package:flutter_midi_command/flutter_midi_command.dart:22

Perhaps MidiCommandPlatform could have a boolean getter added that platforms could use to indicate whether or not they support bluetooth and then the code that setups the _onBluetoothStateChangedStreamSubscription stream could check that before attempting to listen to that stream?