Panerus: Gamelan music authoring

Panerus is unique among my projects because it was something I hadn't intended to use myself. I'd create the software and then the curators at the National Music Museum would use it. It is a great idea and one that I will revisit, but where it stands right now I will have to start over from scratch to achieve my goals. It taught me a bit about tech stacks and the choices one makes when you select them.

What is Panerus?

A Panerus is one of the instruments of a Gamelan music ensemble. I choose it because it had a decently catchy name. The software Panerus is a music authoring program for Gamelan music, which is radically different from western-style music. It's not a complicated system but it does have some aspects of it that make authoring it a challenge. The current best tool is MS Word, which should tell you something. Not knocking Word, it is an amazing tool, but I'm sure "Gamelan music authoring" doesn't show up anywhere in its marketing material. It was not built for this. And the challenge with Word is that the glyphs that are used in Gamelan music are not in Unicode. To get editing in Word to work you have to download a custom font. Then you have to tediously do all of the formatting by hand. The music we used in the Gamelan group at the NMM is copies of copies in part because this process is so troublesome.

This is where Panerus came in. I intended it to be a piece of software that alleviated problems. It would understand the format of Gamelan music and therefore handle all of the formatting for you. It would have the fonts to get things to show up pre-installed, needing no extra effort on the User's part. It would allow you to re-arrange the parts like normal music software does. Allowing you to create a director's sheet or individual instrument sheets. All of this from a mobile device, allowing you to sit at the instruments in question while you worked on your music, another part of life most musicians are used to.

What went right

It worked. I could make basic Gamelan music on my app. You could add lines, instruments, change the diacritical markings, etc. I was pleased with what I made. The discovery of the Gamelan font, KepatihanPro, made everything quite beautiful. KepatihanPro appears to be the result of someone else attempting to make life easier for Gamaelan authors, and they certainly succeeded at making authoring possible. Their advancement fueled mine. Without it, I would have never gotten this far.

When I set out on this project I had been working towards drawing the attention of a potential employer. An employer that utilized React. I created this project then in React Native. I knew at the time that React and React Native were not the same, but the principles and ideas work in both. Using React Native to learn React worked well. I've made a couple of other things with React since and have found it easy to work with based on the experiences I had with React Native. I also choose React Native because it could compile to iOS. Considering I was targeting museums and artsy folk, I figured being able to use this on your iDevice would be a valuable feature.

Overall a lot went right, I was nearly moved to tears when I realized that I had to nix this project because two little details proved to be insurmountable.

So what were the problems?

First problem: The font

KepatihanPro is a nice piece of work that made this project even possible. When I give this project another go it will be a necessary part of that second attempt. However, this is where my technical difficulties began. Just getting the font to show up took way more effort than it should have, but once I finally got it in there I ran into another problem, the pdf publishing library. It had specific attributes for loading custom fonts but I couldn't get any of them to work. Now, the whole point of this program is music authoring. The exporting to PDFs is absolutely requisite for it to be a useful piece of software. So being unable to do that my project hit a dead end.

Second problem: The pdf publishing on iOS

One of the reasons I choose React Native was the ability to compile to iOS. However, the pdf exporting library I found did not support custom fonts on iOS. Poof, my iOS argument was gone. Since this was the only library I could find at the time that would do this specific function I was out of luck. That leads me to question the use of React Native for producing this software. It did serve its original purpose of introducing me to the language and its principles, but without the ability to compile to iOS, it lacked that advantage over just writing native code.

You might argue that I could just write my own pdf exporting library, but the point of using something like React Native is to stand on the shoulders of giants. Writing my own pdf exporter would be a little beyond the scope of this project. If I'm going that far I might as well just write the thing in native code.

Honorable mentions

One minor thing that went wrong first. I had hoped to create a system for storing the music in raw Unicode text files. This would mean that even if my software were to be lost, all the work that the music makers had put in would not be. However, the glyphs needed for Gamelan music are not in Unicode. Because of that, I couldn't use a Unicode file that would make sense. This isn't a deal-breaker, but it was unfortunate, it makes my software less future-proof.

One last thing that bugged me. Speed. There was so much going on under the hood of this app that a lot of very simple operations were quite slow. And since I didn't know what all was going on under the hood I couldn't do much about that fact.

Where are you going to go from here?

At this point, I'm putting this project aside, hence this post mortem. When I return to it I'm going to try to go native, Kotlin. This seems much more my speed to be honest. In my last commit on this project, I describe React Native as standing atop a tower of dominos, dominos whom I don't get to know. Based on my experiences in the past with developing native java applications for android (c. 2015) using Kotlin isn't going to simplify tasks like pulling in new fonts or libraries for publishing PDFs. However, it will remove that tower of dominos feeling. Kotlin is a system designed for Android and so should make the building and deploy process simple and bring with it much fewer moving parts. React Native and Kivy add complexity to make the non-native code work so I can code in a familiar environment. That complexity however I cannot control. So while Kotlin is more complex to use as a developer as it is a new language to learn, it skips the complexity needed to get it to work since it is native. Hopefully, I'm right about this and when I get back to Panerus I'll be successful.