Friday, June 22, 2012

Update: Maybe you should just skip all this and jump right into Part III since there's a link to ready made Remote Templates and some explanation on how to use them :)
But... if you still want to know how those Templates were made, here's some details that helped achieve that:

So, we finally got 3rd party devices inside "THE RACK" uh? :)

After all the fuss, hype...iness, trying every available Rack Extension possible and buying the "must have" ones, there's an issue related with the Remote side of each one of these new devices inside our Reason 6.5 rack:

The only Rack Extension supported by default on all the "factory" provided Remote Codecs+Maps is Propellerhead's own Radical Piano.

Yup... so now what ?

Here's some tricks for every Remote Dev/"hacker"/enthusiast and/or power user that knows how to or likes to keep their own customized versions of their controller Remote Codecs and Maps.

Q1: What's the quickest way to list all the Rack Extension Remoteables ?

A1: Besides the traditional and tedious way of engaging the Options, Remote Override Edit Mode, and going through each of the device controls, hovering the mouse over them and taking notes of its Remote designation, there's a quicker and easier way to do this for the Rack Extensions.

As you may already know, there's a new patch file format introduced with the Rack Extensions known as RePatch (extension .repatch).

This new file type is really, and fortunately (for many reasons, including what I'm about to explain) in plain text format, specifically, it's in XML format :)

Great uh? Yup, it's awesome!

(at this point, you may have noticed that I have to keep answering my own questions -.-')

This new format allows many patch generating/editing tricks (maybe I'll post about it in the future) but, the first thing you'll get out of this is easy access to the internal names of each control (knob/fader/button/...) of the Rack Extension that saved that .repatch file.

...at this point, you may ask:

"What about all the other Rack Extensions that don't have Patch saving capabilities ?"

well... as usual, the Combinator comes to the rescue, in this case too ;)

Simply put the Rack Extension device you're trying to figure out its Remoteables, inside a Combinator, save that as a Combinator patch (.cmb file) and open that file with a text editor (that doesn't get confused with extra non-printable characters!). This will get you access to the same type of information I was talking about in the .repatch file, since all the Rack Extension parameters/controls are also saved in that .cmb file, as an XML block of plain text, which solves our problem :)

Ok, let's see an example, shall we?

Let's say I want to add support to Pulsar on my custom version of the M-Audio Axiom 61 Remote Map.

Here are the basic steps:

1) Start Reason 6.5

2) Create a Pulsar device

3) Combine it (i.e. put it inside a Combinator)

4) Save that Combinator as something like "PulsarInside.cmb" (remember the folder where you saved it!)

5) Start your preferred text Editor and open that same "
PulsarInside.cmb" file with it.

You'll end up with something like this:

...and if you sort those lines, or filter them for "Value property" you'll get something like this:

See? After some Search/Replacing, you'll get this clean list of Pulsar remoteables:

Which is then what you can use (i.e. try) to map to your controller controls with lines like:

MapFader 1Attack

Note that, sometimes, you may need to replace any "_" char for a white space " ", so if there's an internal parameter name like "EG_ATTACK", as a remoteable it might become "EG ATTACK", being the one you want to use inside your .remotemap file!

Also, because internal parameter names used in patches aren't exactly the names declared as remoteables, you should expect some kind of trial'n'error with this, also because not every saved parameter is supposed to be exposed as a remoteable, so... don't be surprised if some of these simply don't work, ok? :) ...this is just a "brute force" way to quickly get everything.

For instance, that raw list will need some adjustments, when you compare it with what you'll get when doing a check of each Remote Override naming.

So, in this case of Pulsar, you see some differences when comparing with this list:

You'll always have to check, but I prefer to edit and correct a raw list extracted in bulk than going one by one and manually taking notes on each Remoteable. Just a personal preference. Now that you know this additional method, you're the one to choose which works best for you :)

Q2: What about the Scope line ? How do I identify the Rack Extension as a Scope?

A2: Well, there are 2 things you'll need to know to make the Scope line: The device ID and... the CompanyID that made it.

So, with those 2 informations, you'll be able to make a line like:

Scope{CompanyID}{RackExtensionID}

...and this is how you get those 2:

1) To get the Rack Extension ID, you'll need to check the folder where the Rack Extensions are kept (saved/installed). I don't own a Mac (sorry!) so I'll give you the Windows path (and maybe someone in the comments can add the OS X equivalent).