MIDI Designer File Format: Could it be XML?

Question

from: Twitter

Can you please publish the MD file format or use XML? This would enable bulk edit e.g. add named ticks from spec documents.

Answer 1

From Twitter

• they're binary plists, which are a mess, but 
• for named ticks the problem is solved. That last box called "edit text" is made for copy and paste. You can use @notesy (any plain text editor, really) for copy/paste of named ticks. It's a bit kludgey from/to Excel, but it's how we made this midiDR.com/ticksPhat

Note: "mess" is a bit overstated. Just not very human editable... binary plists have a lot to recommend them, though...

 

Also: we'd love to switch to proper XML (probably compressed with Gzip), and it's on the roadmap, but won't happen yet...

 

Thanks for the love and dialogue.

Comments

Thanks for the reply guys and for taking time to bring this back to the forum. The whole Midi Designer experience from app purchase, through learning and support all the way to this forum is just superb!

Well the the first thing that hit me as having an open file format so if I wanted to do some advanced technical specification parsing, I could build a tool on my PC which parsed all the NRPN data from my VG99 midi implementation document and have it build a palette of widgets that I could then use in layouts.

I'm about to publish a new layout for VG99 built from the ground up, inspired by the other available template, but much more powerful.  Whilst building this a few improvement requests have come to mind which I will write up soon.

Yes, that text edit feature, so simple, yet so powerful...a bit of excel magic and it saved me entering 50 lines of text, then checking spelling and numbering etc...awesome!

---

Glad to hear it all and thank you!

Regarding the file format, etc., it's basically just the object model, serialized using Apple's somewhat automatic serialization (or is it Archiving? see my gratuitous question here: http://stackoverflow.com/questions/4288719/serialization-vs-archiving)...

While some obvious pitfalls were avoided, like not serializing actual UI objects, some stuff is handled by the archiving engine, including resolving circular object references and all of that. So TBH we don't actually know what the file format contains, nor even how to deserialize it without a copy of the MIDI Designer code.

As stated, eventually we'll move to something coherent like proper XML (or JSON, or whatever), but that code will have to be optimized properly for speed... so it's a larger undertaking.

Thanks for your kind words, using MIDI Designer, and your patience as we remove the pain points from the App. Note: If you find that you love MD and want to leave an awesome review in the App Store, please do: every review helps attract users to the platform.

Best!
Dan

Dan Rosenstark
Author & CEO
MIDI Designer
dream | create | play

---

Great so I should be able to use the plist pro to edit the files... I'll give it a shot over the weekend

---

Thanks, let us know what you find, please!

---

Dan, I've been out for a while but this Roland gear drives me nuts and I need to go back to Midi designer to solve some of the Roland idiocracies. However, I know that there is no JD-XI template but there is one for Integra or so. The first thing it crossed my mind to just read the layout file somehow (using python) and replace the header for each sysex message so I can quickly take one "zen engine" template to another hardware "zen core"
Can you point me to any GitHub etc that allows to read this apple serialized format with Python ? or Is there any way to search replace 2-4 bytes in sysex string for entire layout . Thanks !
... So to the point is there way to read the MD file with python and replace 3 bytes  in the header message for all sliders etc. ???

---

Hey there, we're not offering programmer support (nor aftermarket product support) for modifying MIDI Designer files at this time. We think it's possible, but then again we've never done it. Good luck and thanks for using MD!

---

If it is only the SysEx header that differs, use StreamByter inbound and outbound rules to modify the header as needed.  I have done this in one Roland layout.  Same length header is trivial.  However, the Juno X and RD-88 have an additional byte in the header (Roland five bytes), so it is a little more complicated, since you have to move everything following the header one byte forward or backward.  I will add posting the flexible version of SysEx header substitution to my backlog.

For big layouts, a SysEx search and replace function could be useful, for exactly this reason.  May add to the list of user requests, but I would not hold my breath, since there is a lot in queue, and since there is a functioning workaround, isn't a critical upgrade.

Answer 2

From Twitter

• they're binary plists, which are a mess, but 
• for named ticks the problem is solved. That last box called "edit text" is made for copy and paste. You can use @notesy (any plain text editor, really) for copy/paste of named ticks. It's a bit kludgey from/to Excel, but it's how we made this midiDR.com/ticksPhat

Note: "mess" is a bit overstated. Just not very human editable... binary plists have a lot to recommend them, though...

 

Also: we'd love to switch to proper XML (probably compressed with Gzip), and it's on the roadmap, but won't happen yet...

 

Thanks for the love and dialogue.