10 thoughts on “MIDIMetaEvent and that damn tuple”

1. Try something like that:

   Swift

   // copyright: J.G. digitster.com public struct MIDIRawDataExtension { // set it to 254 bytes, always check size inside your code with MemoryLayout.size " public var bytes: (UInt8, ... ) } // note: Apple actually does similar things in his/her AudioToolbox code ( i.e. with MIDIPackage ) ! ^^ Then define that: public struct MIDIMetaEventEx { public var metaEventType: UInt8 public var unused1: UInt8 public var unused2: UInt8 public var unused3: UInt8 public var dataLength: UInt32 public var data: MIDIRawDataExtension }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   // copyright: J.G. digitster.com public struct MIDIRawDataExtension {     // set it to 254 bytes, always check size inside your code with MemoryLayout.size "     public var bytes: (UInt8, ... ) }   // note: Apple actually does similar things in his/her AudioToolbox code ( i.e. with MIDIPackage ) ! ^^   Then define that: public struct MIDIMetaEventEx {     public var metaEventType: UInt8     public var unused1: UInt8     public var unused2: UInt8     public var unused3: UInt8     public var dataLength: UInt32     public var data: MIDIRawDataExtension }

   NOTE: It MUST FIT to the layout of the original struct definition of MIDIMetaEvent !!!

   Then actually use THAT NEW structure in your allocation blocks and callbacks…
   i.e.:

   Swift

   let data = UnsafePointer(eventData?.assumingMemoryBound(to: MIDIMetaEventEx.self)) var event: MIDIMetaEventEx = (data?.pointee)! // ... // check size! our 'extended data struct" can handle a maximum of xxx bytes var len: Int = Int(event.dataLength) let max = MemoryLayout.size if len > max { len = max }

   1 2 3 4 5 6 7 8 9 10 11

   let data = UnsafePointer(eventData?.assumingMemoryBound(to: MIDIMetaEventEx.self)) var event: MIDIMetaEventEx = (data?.pointee)! // ...   // check size! our 'extended data struct" can handle a maximum of xxx bytes var len: Int = Int(event.dataLength) let max = MemoryLayout.size if len > max {       len = max }

   You may then iterate the stuff of the tuple with something like that:

   Swift

   // example of a binary access to the elements of a tuple collection : withUnsafePointer(to: &event.data.bytes.0) // addressing the first element of the tuple { p in let p = UnsafeMutablePointer(mutating: p) for i in 0..<len { let value: UInt8 = p[i] // access it // ... // print("\(String(format:"%2X", value))") } }

   1 2 3 4 5 6 7 8 9 10 11 12

   // example of a binary access to the elements of a tuple collection : withUnsafePointer(to: &event.data.bytes.0) // addressing the first element of the tuple {     p in     let p = UnsafeMutablePointer(mutating: p)     for i in 0..<len     {         let value: UInt8 = p[i] // access it         // ...         // print("\(String(format:"%2X", value))")     } }

   or even write to that struct memory to provide data…

   PLEASE NOTE:

   This is a HACK! But it actually works. And it is the only way that makes any sense.
   Why? The reason obviously is (guessing), that SWIFT does not give us direct access to the data in memory, but copies that memory into the structs we provide for the function calls. So it is always on our side to provide the correct sizes!
   Otherwise we actually would pump shit into the memory of the user devices!!!

   Reply

2. Please note:
   The code above is tested SWIFT 3 Code with Xcode Version 8.3.2 .

   You may actually just copy and past that to several projects from Gene at GitHub. ^^

   Reply

3. Hi Gene!

   Did you actually notice the fundamental difference to your code examples?
   It is just your code. I learned so much from you.

   So this way we would be on the save, secure side with our code, but, I guess, that it is nevertheless a quite risky operation.
   Why?
   Because this way one possibly would be able to exploit users data in memory (because you actually are able to read memory areas with that, which may NOT be intended for our eyes ^^)

   Reply

4. .. just took notice, that the editor did screw up my code.
   So i uploaded a SWIFT file with the complete extension definitions to my server here:

   http://digitster.com/MIDIRawDataExtension.swift

   Reply

   1. .. updated the file above to support easy (and save) writing of raw Midi data with 3 class examples ready to use. It simplifies the write and read access to few lines of code…

      Just discovered, that even popular, already released SWIFT MIDI frameworks actually excessively write junk into the memory of the users devices with these wrong pointer operations on uninitialized data structs in memory ^^

      By The way: I am coming from C/C++. These Apple programming languages are just awful! And with each release they will become more terrible. You need XXX times longer to get something useful out of it…

      Reply

      1. Swift as a language is decent. The churn is settling down now, but I’m disappointed that ABI compatibility has been put off after Swift 3.

         Apple’s API “bindings” to Swift have glaring problems. This damn tuple problem is one of them.

         AUGraph is going to be deprecated in favor of the AVFoundation classes.
         It would be nice if they created a usable MIDI replacement in AVFoundation instead of making us use the Core MIDI C API.
         I don’t see that on the horizon though. (I have indeed filed Radars. Everyone should – squeaky wheel…)

         Reply

         1. I do not have any problem with a deprecation of AUGraph, Because it actually is quite superfluos with the available functions of the AV stuff now.. (it’s kind of wrapped now)

            Although, CoreMIDI on the other side is essential to music apps. They surely won’t deprecate that for some certain reasons. Maybe they will dorrect that tuple stuff or at least show us the correct way of using that… ^^

            We can just ignore a stupid AVAudioSequencer class, if we have access to CoreMIDI.

            Reply

5. Hi Gene,

   Did you ever work out a solid solution to this?

   Also, any thoughts on how to use this for setting Key signature? I saw it used for a signature with sharp notes in your Swift3MIDI project, but for signatures containing flats, that requires a negative number (https://www.csie.ntu.edu.tw/~r92092/ref/midi/#meta_event), which of course causes an error when placed into a UInt8 variable.

   Thanks in advance.
   Neil

   Reply

   1. No, I gave up. I use Objective-C++ for meta events. I’ve checked each new Apple release and nothing is being updated. They pretty much responded to my Radars with “too bad”. But if you can, go ahead and file one. Maybe if someone else mentioned it, they’d maybe take notice.

      ps National Chiao Tung University? Back in the 80s, Phil Winsor and I did a lot of planning for their music studios.

      Reply

      1. Thanks for the update. I gathered that you’d likely have a fresher post on this, but thought I’d ask.

         Personally, I ended up using the suggestion made in this Stack Overflow question (which I know you also contributed to), but it’s far from ideal having to use such an elaborate workaround. Also doesn’t seem to work properly for setting key signatures, for some reason (it messes up how the audio sounds – very strange).

         NCTU just happened to be in the top results when looking at MIDI meta specs, but clearly they learned from the best!

         Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.