Introduction

In late February, Mike from Soundiron proposed me to join his team for porting their Granada Kontakt instrument to Reason Rack Extension format. I already worked for him as a ReaScript developper, and it happens that the language used by the Reason Rack Extension 2D layout files is the same as the one I use for most ReaScripts, so despite the fact I’m not a Reason user and that I didn’t know how Reason Rack Extension UI binding worked, Mike gave me a chance to handle it. It was not that easy cause it was unknown territories, but in the end, all went pretty smoothly. On 2017-06-07, the instrument has been publicly released on Propellerheads Shop website! (If you are interested by it, there is a discount until 1st July !).

Concepts

UI binding goal is to link parameters to UI elements. It is the task which links code (in this case, the way samples are loaded, the way FX process sounds etc) to graphics (knobs and slider images etc…) so that user can control these parameters in a interactive way.

For virtual instrument, the task requires to know about graphics (how images works, transparency etc), sound processing (to be able to understand and debug the various controls) and code (for the binding itself, the layout, and the various scripts needed to automate some parts of the workflow). As I have experience in all these domains, it was a pretty interesting challenge.

Organization

So here was how we were organized: Jeremy Janzen for the main code, Koke for the GUI design, and myself for the binding.

To make our collaboration easier, early in the project, I created a Trello board to organize our conversations by topics.

Paul Kelett from Ujam helped us on specific points which needed a deep knowledge of Reason Rack Extension creation.

Process

Learning the Doc

In order to understand how a Reason Rack instrument, the first step was to read most of the doc of the Reason Rack SDK, which presents the purpose of the different files, how to compile, what variables have to be set for the UI binding, and what are the requirements for the GUI. Complex but necessary things to learn in order to work on the project.

Creating a 2D Previewer

To prevent having to compile the instrument every time you make a layout change, as it is a very long process with a lot of clicks, there is a previewer in the SDK. But because 2D GUI are pretty recent for Reason Rack, it only works for 3D interface. So there is no 2D GUI previewer in the Reason Rack SDK.

Compiling every time wasn’t conceivable. It was necessary to me to build my own Reason Rack 2D GUI previewer to avoid losing times and repetitive compilations.

I initially though about a web based solution, but as I needed to be operational quickly, and as the language used for 2D positioning is Lua, I created my Reason Rack 2D layout previewer in REAPER, It took me only 2 days to have a working prototype (cropping film strip images, parsing Lua files etc). I updated it few times during the process, but It stayed pretty basic (it doesn’t allow to drag and drop GUI elements, it is just a previewer), but it helps a lot: only few seconds to refresh the preview after a file update; that’s better than no preview at all!

(In the end, I finally make a web based version, but I didn’t have the opportunity to use it on the Granada project, so I’ll talk about it another time :P)

Scripting for Photoshop

The next step was to create a way convert the Photoshop PSD layout to lua files directly, to avoid having to make hundreds of copy pasting of layer position values.

One of the great advantage of Photoshop is its extensive API, allowing third party devs to code custom functions in JavaScript. I never coded for Photoshop, but I know JavaScript, so I decided to give it a shot, and once again I was reading documentation to understand the basic concept of Photoshop scripting. I also had to analyze some existing Photoshop scripts to see how it was done.

After having reorganized the layers in Photoshop and after having renamed them with a custom script-friendly nomenclature I came up with, I made this Photoshop to Reason Rack Extension 2D GUI scripts. In two clicks, the Lua layout files are generated from Photoshop layers!

I was a bit surprise that getting the X/Y top left transform position of a layer wasn’t a built-in feature in the Photoshop API. It is in fact extra complex to get them, something like 100 lines of code (if you consider artboard position)! Without the help of generous people from the Adobe forum, especially r-bin, I couldn’t have exploit this solution with that level of efficiency.

Coding

These generated files wasn’t the end though, just a base for the next steps.

Indeed, it still needed lots of manual adjustments to fit Reason Rack guidelines, tweaking on the artwork, finding the property names linked to GUI elements, adding properties metadata, comparing the results with compiled version (there is always some difference and adjustments to make, especially because Reason Rack GUI are down scaled)… Some of the hardest tasks were finding how to handle text. Also, some requirements weren’t specified in the doc, which makes things quite harder.

Few weeks after, after a lot of back and forth to fine tune things on the GUI and make adjustment to the engine code, the instrument was finally ready to be shared publicly. You can see the result of the Front view (there is 4 views) at the top of the article.

Next

As the collaboration went pretty successful, new Soundiron Reason Rack instrument should come from time to time. As the other instruments will be pretty similar visually to Granada (which will work as a template), and now that we have experience, the UI binding will require far less work. The hardest part has been done. I am ready for the next 😛