Hi everyone,
It seems there are many cool controllers out that are not natively supported by reason.
From what I understand, if I want to change that I need two different files: a remote map and a remote codec.
I get how to write the remote map in a text editor, but I am confused about the codec. Can I create one for any midi controller?
Thanks!
Remote mapping question
-
Carly(Poohbear)
.jpg)
- Competition Winner
- Posts: 2885
- Joined: 25 Jan 2015
- Location: UK
You can create codec for any input device but you will have know about the internals of that device which only the manufacturers will know..
On the Propellerhead website, there is\was a page about how to become a developer for the Codec stuff.
On the Propellerhead website, there is\was a page about how to become a developer for the Codec stuff.
Some midi controller developers such as Novation have a quite good MIDI developer documentation online. I wrote a bunch of custom codecs for different controllers and had no issues so far.
To write a codec you need to learn LUA, a scripting language. If have some experience with other script languages it´s quite easy to grasp.
I´d recommend to apply as Remote developer at https://www.propellerheads.se/developers. I didn´t need a VAT number or registered company for that.
You will then get access to Remote API documentation and some testing tools. It´s by far easier than reverse engineering available codecs.
Knowing in detail how remote codecs work makes it easy to modify existing codecs to your liking or developing more sophisticated stuff like step sequencers, recorders, some kind of clip launching (as far as the limitations in Reason allow) and so on.
To write a codec you need to learn LUA, a scripting language. If have some experience with other script languages it´s quite easy to grasp.
I´d recommend to apply as Remote developer at https://www.propellerheads.se/developers. I didn´t need a VAT number or registered company for that.
You will then get access to Remote API documentation and some testing tools. It´s by far easier than reverse engineering available codecs.
Knowing in detail how remote codecs work makes it easy to modify existing codecs to your liking or developing more sophisticated stuff like step sequencers, recorders, some kind of clip launching (as far as the limitations in Reason allow) and so on.
There is a lot of flexibility to Remote, and when you look at the developer manual, remember that everything it says is exactly, laser precisely as it works.
The remotemap files are best done in a spreadsheet and exported as tab-delineated files.
I would suggest taking a look at Livid's remote codecs -- they are on github. Specifically, see how they use the "constant value" trick (which is mentioned briefly, once in the developer manual) in their remotemaps to tell which device or group variation has scope. Also how they detect things at the start of the remote_parse_midi() is pretty instructive. (Though some of their scripts are written with a second output port which used a max/msp interface, so some of their code is written for that and confusing.)
My advice is to sign up as a developer, which gets you the SDK (with testing tools) which gives you access to the Propellerhead's Remote dev forum. Then I'd start with a blank lua codec file that just has the main remote function defined; remote_prepare_for_use(), remote_deliver_midi(), etc and then start pulling in code blocks from other codecs as you understand them. (Though be aware that some of the hardware codecs that ship with Reason were written quickly when the spec came out, and aren't really the best practices, which is why I suggest looking at Livid's.)
I've also got a post on the Remote dev forum with an table dump routine that could help you debug if you start doing crazy stuff. (Lua calls arrays 'tables', you can nest them and even put functions inside them.)
Good luck!
The remotemap files are best done in a spreadsheet and exported as tab-delineated files.
I would suggest taking a look at Livid's remote codecs -- they are on github. Specifically, see how they use the "constant value" trick (which is mentioned briefly, once in the developer manual) in their remotemaps to tell which device or group variation has scope. Also how they detect things at the start of the remote_parse_midi() is pretty instructive. (Though some of their scripts are written with a second output port which used a max/msp interface, so some of their code is written for that and confusing.)
My advice is to sign up as a developer, which gets you the SDK (with testing tools) which gives you access to the Propellerhead's Remote dev forum. Then I'd start with a blank lua codec file that just has the main remote function defined; remote_prepare_for_use(), remote_deliver_midi(), etc and then start pulling in code blocks from other codecs as you understand them. (Though be aware that some of the hardware codecs that ship with Reason were written quickly when the spec came out, and aren't really the best practices, which is why I suggest looking at Livid's.)
I've also got a post on the Remote dev forum with an table dump routine that could help you debug if you start doing crazy stuff. (Lua calls arrays 'tables', you can nest them and even put functions inside them.)
Good luck!
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
You may want to check out this thread.
viewtopic.php?t=7497305
Also, if you do want to get into Remote programming, the codecs there are written very straightforward and easy to understand.
viewtopic.php?t=7497305
Also, if you do want to get into Remote programming, the codecs there are written very straightforward and easy to understand.
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
Thanks! I had a look at these and bought the launch control xl just to get into it!
Do any of you have some formal pdf documentation etc on the remote protocol? I registered as a developer but di not have a company and so far have been waiting...If you can help pls feel free to PM me
Do any of you have some formal pdf documentation etc on the remote protocol? I registered as a developer but di not have a company and so far have been waiting...If you can help pls feel free to PM me
Writing a specific codec for a controller is a daunting task that is not generally recommended to any beginner. The documentation is for whatever reason under a NDA that anyone who signs up for to get cannot just distribute so I'm not sure anyone will just share the document but if you get it good luck.
However hope is not lost. There is a very easy way to create your own device maps and actually have it show up as an available hardware device with its own cool little picture and everything. You will have to develop your own map of course over time but creating once is all that is needed. This might be long winded but here goes :
Planning :
Most if not all unsupported controllers fall into one of a couple categories that you need to define. First... is it Mackie compatible? Many are or many claim so. If it is you already have a codec right? Use that one. If it isn’t it isn’t necessary to have to create a specific LUA as you can use one of the four (4) provided MIDI codecs. The only difference in having these opposed to having a specific designed one is that LUA codecs for a device name the control conventions like Fader 1 or Button 5 and so on. Maybe not as simple as that but to the layman it is. So out of these four your controller will fall. It is either a controller or a keyboard and it either operates on a single or multi MIDI channel configuration. Most of them are single MIDI channel so it makes it a little easier but if you had one it would open up a lot more level of control. So the very first thing is which one? Decided? OK. The other thing you need to know is what is the default “scene” of your controller? I use that term with a loose title as many manufacturers call it something different but what is by default the MIDI CC values for your controller? You could use custom but if you have to reset your controller you are kinda screwed as you’d have to reprogram the thing or at best have it saved which would still require loading from a backup. The most important is using defaults is that it is sharable among the community.
So second level of planning…..know the MIDI CC values for your controller. THe last level of planning is having the right tools to make this happen. You will need a nice text editor that respects white spaces or tabbing as the format is critical in codecs to work. I recommend a program like Notepad++ or Programmer’s Notepad. There are many others but these are two to start. If you want to make your own neat little PNG image to show up in the dropdown list then you will need a graphic program that supports reading and writing PNG images which is just about all of them. If you don’t have Photoshop or substitute then there are a few free ones out there like GIMP that get the job done.
Creating it :
Navigate to the area on your computer where Propellerhead stores its CODEC files. On a PC it is in the “Program Data\Propellerhead Software\Remote” folder. Let’s assume you decided that you chose that it was a single MIDI channel controller that fits your device description. Go to the MIDI CODEC section and copy two files (MIDI Controller codec and the PNG file of same name) and paste them to another folder somewhere for you to work with away from the rest so that you don’t mistakingly write over anything important. Once you have copied them rename them to your device. Assume you have a Korg nanoKEY Studio name both of them to something like “nanoKEY Studio”. They have to be exact or they will not be recognized.
Now open the MIDICODEC file in your editor. As basic as basic can go… this lists out values for the 127 MIDI CC values. Its data input type is “value”. For most cases this is ok and need not change. But the behavior of certain things like buttons have on/off press/release values. For these you can change the type from “value” to “button”. There are two other types “delta” and “keyboard” Which correspond to specific values between 0-127 and values based on pressing a key on a keyboard. It is unlikely you need to mess with this.
Now that it is open in the editor you need to change a couple things. You need to change the manufacturer and surface model information from <Other> MIDI Control Surface to the name of your device. If it is a brand already established make sure that it is named the same as other established controllers. As an example if your manufacturer is Korg and you name it korg you will have two manufacturer groupings in the end. The other thing that you can change if you like is the setup info text. Whatever you type in here will show up when installing your device. When you are complete just save your work and you are done with the CODEC.
Making an image file is fairly straight forward. They are PNG format images that are 96 x 96 pixels. You can grab a promotional image off the internet for your device that will do the trick. Open up the copied image in your favorite program and open up your promotional image. Copy the promotional image onto the copied image and then save. If you are generally good with this kind of thing you can make something really nice. This is not a tutorial for graphics so I’ll stop here but the basic concept is that you change the image and have it the same name as your CODEC and you are good.
Last thing to do is edit your REMOTEMAP. This is a time consuming thing of course which is more for some and less for others but never without effort for sure. BUT…. only needs to be done once so keep that in mind as you trudge on. You will need to again navigate to the MAPS area of the Remote folder and grab the MAP for “MIDI Controller” and again copy it to your working folder. Name it the same thing as the other files and open it in your text editor. You will again need to change the Manufacturer and Surface model to the same thing you did in the CODEC. If they vary it will not work. That is a trouble-shooting tip for you.
Here comes the fun part. You are now looking at a generic MAP. All of Propellerhead native instruments are represented with corresponding CC values aligning with the remotable name next to it. Do not change the remotable names or they will not work. All you need to do is decide which controls you want to use for your device. This is the tough decisions right? A mixer has 14 channels but my device only has nine faders! Such as this, you are limited of course by that so choose wisely. Once you have decided…. you will need to change the CC values the controller you have sends on a particular control to the remotable. If you have 8 Faders and the CC values on the default setting are CC34 through CC42 you might consider assigning those numbers on the line where Channel 1 – 8 are listed. To keep things simple remove the ones you cannot map. If they duplicate any existing CC values your map will be messed up so keep only what you need. If you need to later change a remote item these are listed in the Reason Literature provided with Reason. It is about as simple as that. You just need to complete it for all devices now. You can grow this map with Re of course by adding the proper Scope for each new device with the set of remotables. There is a whole thread here on ReasonTalk dedicated to remote mapping. All you need to do is append a new set of CC maps and change the Remotables and Scope!
Putting them to work :
Now that you are done place the files back where they need to go. The image and the MIDICODEC file can go back into the MIDI folder and the REMOTEMAP file can go back into the MAPS folder. After you restart you should see this available in your drop down lists.
However hope is not lost. There is a very easy way to create your own device maps and actually have it show up as an available hardware device with its own cool little picture and everything. You will have to develop your own map of course over time but creating once is all that is needed. This might be long winded but here goes :
Planning :
Most if not all unsupported controllers fall into one of a couple categories that you need to define. First... is it Mackie compatible? Many are or many claim so. If it is you already have a codec right? Use that one. If it isn’t it isn’t necessary to have to create a specific LUA as you can use one of the four (4) provided MIDI codecs. The only difference in having these opposed to having a specific designed one is that LUA codecs for a device name the control conventions like Fader 1 or Button 5 and so on. Maybe not as simple as that but to the layman it is. So out of these four your controller will fall. It is either a controller or a keyboard and it either operates on a single or multi MIDI channel configuration. Most of them are single MIDI channel so it makes it a little easier but if you had one it would open up a lot more level of control. So the very first thing is which one? Decided? OK. The other thing you need to know is what is the default “scene” of your controller? I use that term with a loose title as many manufacturers call it something different but what is by default the MIDI CC values for your controller? You could use custom but if you have to reset your controller you are kinda screwed as you’d have to reprogram the thing or at best have it saved which would still require loading from a backup. The most important is using defaults is that it is sharable among the community.
So second level of planning…..know the MIDI CC values for your controller. THe last level of planning is having the right tools to make this happen. You will need a nice text editor that respects white spaces or tabbing as the format is critical in codecs to work. I recommend a program like Notepad++ or Programmer’s Notepad. There are many others but these are two to start. If you want to make your own neat little PNG image to show up in the dropdown list then you will need a graphic program that supports reading and writing PNG images which is just about all of them. If you don’t have Photoshop or substitute then there are a few free ones out there like GIMP that get the job done.Creating it :
Navigate to the area on your computer where Propellerhead stores its CODEC files. On a PC it is in the “Program Data\Propellerhead Software\Remote” folder. Let’s assume you decided that you chose that it was a single MIDI channel controller that fits your device description. Go to the MIDI CODEC section and copy two files (MIDI Controller codec and the PNG file of same name) and paste them to another folder somewhere for you to work with away from the rest so that you don’t mistakingly write over anything important.
Once you have copied them rename them to your device. Assume you have a Korg nanoKEY Studio name both of them to something like “nanoKEY Studio”. They have to be exact or they will not be recognized. Now open the MIDICODEC file in your editor. As basic as basic can go… this lists out values for the 127 MIDI CC values. Its data input type is “value”. For most cases this is ok and need not change. But the behavior of certain things like buttons have on/off press/release values. For these you can change the type from “value” to “button”. There are two other types “delta” and “keyboard” Which correspond to specific values between 0-127 and values based on pressing a key on a keyboard. It is unlikely you need to mess with this.
Now that it is open in the editor you need to change a couple things. You need to change the manufacturer and surface model information from <Other> MIDI Control Surface to the name of your device. If it is a brand already established make sure that it is named the same as other established controllers. As an example if your manufacturer is Korg and you name it korg you will have two manufacturer groupings in the end. The other thing that you can change if you like is the setup info text. Whatever you type in here will show up when installing your device. When you are complete just save your work and you are done with the CODEC.
Making an image file is fairly straight forward. They are PNG format images that are 96 x 96 pixels. You can grab a promotional image off the internet for your device that will do the trick. Open up the copied image in your favorite program and open up your promotional image. Copy the promotional image onto the copied image and then save. If you are generally good with this kind of thing you can make something really nice. This is not a tutorial for graphics so I’ll stop here but the basic concept is that you change the image and have it the same name as your CODEC and you are good.
Last thing to do is edit your REMOTEMAP. This is a time consuming thing of course which is more for some and less for others but never without effort for sure. BUT…. only needs to be done once so keep that in mind as you trudge on. You will need to again navigate to the MAPS area of the Remote folder and grab the MAP for “MIDI Controller” and again copy it to your working folder. Name it the same thing as the other files and open it in your text editor. You will again need to change the Manufacturer and Surface model to the same thing you did in the CODEC. If they vary it will not work. That is a trouble-shooting tip for you.
Here comes the fun part. You are now looking at a generic MAP. All of Propellerhead native instruments are represented with corresponding CC values aligning with the remotable name next to it. Do not change the remotable names or they will not work. All you need to do is decide which controls you want to use for your device. This is the tough decisions right? A mixer has 14 channels but my device only has nine faders! Such as this, you are limited of course by that so choose wisely. Once you have decided…. you will need to change the CC values the controller you have sends on a particular control to the remotable. If you have 8 Faders and the CC values on the default setting are CC34 through CC42 you might consider assigning those numbers on the line where Channel 1 – 8 are listed. To keep things simple remove the ones you cannot map. If they duplicate any existing CC values your map will be messed up so keep only what you need. If you need to later change a remote item these are listed in the Reason Literature provided with Reason. It is about as simple as that. You just need to complete it for all devices now. You can grow this map with Re of course by adding the proper Scope for each new device with the set of remotables. There is a whole thread here on ReasonTalk dedicated to remote mapping. All you need to do is append a new set of CC maps and change the Remotables and Scope!
Putting them to work :
Now that you are done place the files back where they need to go. The image and the MIDICODEC file can go back into the MIDI folder and the REMOTEMAP file can go back into the MAPS folder. After you restart you should see this available in your drop down lists.
Very nice, thanks a lot! I also got approved by Props yesterday evening, so now I also have the official documents on top of your very helpful post!
Have decided to go the LUA route for now (the basics do not seem to be that hard in the end) and the main elements of the codec are already working Now need to figure out some specifics of my controller (arturia beatstep) and think more groups / paging.
Have decided to go the LUA route for now (the basics do not seem to be that hard in the end) and the main elements of the codec are already working
Now need to figure out some specifics of my controller (arturia beatstep) and think more groups / paging.-
Data_Shrine
- Posts: 517
- Joined: 23 Jan 2015
Wouldnt it be great just to be able to save midi mapping inside reason itself ? A kind of "macro" mapping like ableton live has. If its possible.. please enlighten me !
Cool. Good luck. You now have opened the box of the pandora and may end up buying lots of midi controllers and writing custom codecs like I didstp2015 wrote:Very nice, thanks a lot! I also got approved by Props yesterday evening, so now I also have the official documents on top of your very helpful post!
Have decided to go the LUA route for now (the basics do not seem to be that hard in the end) and the main elements of the codec are already working
To help you get started you may have a look at the remote codec I wrote for the Beatstep as I posted in the other thread
viewtopic.php?f=12&t=7494541&p=301010&h ... ep#p301010
Download link: download/file.php?id=2365544
-
Data_Shrine
- Posts: 517
- Joined: 23 Jan 2015
I'm not holding my breath but i think it would really enhance the playability of Reason for a majority of users if they implemented this at some point.stp2015 wrote:I think it is not possible. Inside of reason itself you can only define remote overrides, but those really are not the same as a complete mapping with a codec.
artotaku wrote: Cool. Good luck. You now have opened the box of the pandora and may end up buying lots of midi controllers and writing custom codecs like I did
Thanks! Let's hope I won't go completely overboard... For now, the Beatstep is really cool. I have assigned the large encoder to the song playhead, two of the small encoders to the left/right loop markers and two encoders to device and patch select, respectively.
The function of the remaining twelve encoders changes according to what device is selected (using the mapping).
For pads I have implemented three different layouts (loadable as presets on the Beatstep). In the first one, the top row controls synth parameters, for example the fx buttons on antidote and the loop select in octorex, and the second row does things like undo/redo. In the second pad layout, I can play Kong and Redrum, and in the third pad layout one I can program the step sequencer in redrum.
All of this for 99 bucks, and all the encoders are endless, so they are basically always at the right position. Really happy for now!
One thing I am still trying to do is get LED feedback for Kong pads when the song plays. Of course, when I hit a pad on the Beatstep, the Kong pad also lights up, but it does not work the other way around for now.
For mutes in the mixer, antidote fx switches etc, the LED feedback works flawlessly, i.e. when I change something using the mouse, the LEDs on the beatstep will light up correspondingly.
For mutes in the mixer, antidote fx switches etc, the LED feedback works flawlessly, i.e. when I change something using the mouse, the LEDs on the beatstep will light up correspondingly.
Don´t have any experience with remoting Kong but there is an output remote item called "Hit Indication" per pad, maybe it can be used to light a button up on the control interface.stp2015 wrote:One thing I am still trying to do is get LED feedback for Kong pads when the song plays. Of course, when I hit a pad on the Beatstep, the Kong pad also lights up, but it does not work the other way around for now.
For mutes in the mixer, antidote fx switches etc, the LED feedback works flawlessly, i.e. when I change something using the mouse, the LEDs on the beatstep will light up correspondingly.
Other than that you could connect the CV outs of each pad to a device that has a control that change state if CV comes in. If the control is remoteable you can bind it to your controller. E. g. route Kong Pad CV out to Combinator Rotary CV In and bind the Rotary to the pad of the Beatstep.
Hi again, so I have not yet managed to get this working, but I will keep trying. I think your recommendation to look at the "Hit Indication" item should be the way to go, but no luck so far.
Something else I am trying to do is to hard map some device-independent parameters (that do not depend on the current scope). Basically, I want master volume from the mixer to be on one specific knob, even if a different device is currently selected in Reason. I can do this using remote-override in Reason, but I would like to have it in the actual codec.
If you have an idea, I would be grateful to hear it
I have also emailed Arturia to ask if they can update the firmware such that the shift button will send a midi message (currently it does not send anything). This would be great to extend the functionality and I could probably turn the Beatstep into a great little controller.
Something else I am trying to do is to hard map some device-independent parameters (that do not depend on the current scope). Basically, I want master volume from the mixer to be on one specific knob, even if a different device is currently selected in Reason. I can do this using remote-override in Reason, but I would like to have it in the actual codec.
If you have an idea, I would be grateful to hear it
I have also emailed Arturia to ask if they can update the firmware such that the shift button will send a midi message (currently it does not send anything). This would be great to extend the functionality and I could probably turn the Beatstep into a great little controller.
I know how to do this, have done it. You won't like my answer.stp2015 wrote:One thing I am still trying to do is get LED feedback for Kong pads when the song plays. Of course, when I hit a pad on the Beatstep, the Kong pad also lights up, but it does not work the other way around for now.
For mutes in the mixer, antidote fx switches etc, the LED feedback works flawlessly, i.e. when I change something using the mouse, the LEDs on the beatstep will light up correspondingly.
Remote is a protocol for interfacing between Reason and your hardware. It's the interface between your devices in Reason and your controller. It isn't meant to be an interface between the sequencer in Reason and your controller.
I'm willing to bet that those "Hit Indication" remotables would work when you hit the pads (for lighting up the pads on your controller) and maybe just maybe works when you wire a CV gate into the Kong's pad. They are for output display, they have no input attached. But what you should do to test is this: Make Items in remote_init() for them. Call them "Pad 1 Hit Light" or whatever. As ITEMS they can exist with your regular "Pad" Items. Remember the remotable is only for output, so make an Output for them in that section of remote_init(). These 16 outputs can have the same midi output pattern as your regular pad's lights. Remote doesn't care, it just wants unique names in remote_init() matched to the remotemap. Then put those unique names and the Hit Indication remotables in the Kong section of the remotemap.
If that doesn't work, you'd have to get crazy with opening up a second midi port in your codec and routing a loopbacked External Midi Instrument to it. (That's what I've done with my crazy Launchpad Pro codec so I can see playback even though I've mapped the pads to different colors/notes.)
Good luck.
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
Can you give a specific as to what you mean?stp2015 wrote:Your answer is fine and seems to be something I can try
Thanks!
Oh, and I had originally thought you couldn't do what you were wanting to do. Because I'd wanted my Launchpad Pro to display playing notes from the sequencer (aka the keyboard device and scope in the remotemap) I wasn't able to do what I wanted. But since you have those remotables for hit indication, much like the Redrum ones, you can probably get away with having unique ITEMS with OUTPUTS in your remote_init just for those hit indicators.
I actually have a button mapped to undo and redo on my launchpad, too. Which is part of the Reason document scope which you are always in.
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
Exactly, I think the hit indication removables should do the job, we will see.
As to the other question: Yes, the undo/redo thing is a very good example of what I want to do. Undo/redo remotables are part to the Reason document scope (as you say) and therefore can always be accessed. The problem is that the item I want ("Master Level" of the SSL mixer) is not part of the Reason document scope and therefore not "global" in the same way.
As to the other question: Yes, the undo/redo thing is a very good example of what I want to do. Undo/redo remotables are part to the Reason document scope (as you say) and therefore can always be accessed. The problem is that the item I want ("Master Level" of the SSL mixer) is not part of the Reason document scope and therefore not "global" in the same way.
Try Audio Output Peak Meter in the reason document scope. Maybe that will work? Otherwise you'd have to lock a control to the SSL's meter.stp2015 wrote:Exactly, I think the hit indication removables should do the job, we will see.
As to the other question: Yes, the undo/redo thing is a very good example of what I want to do. Undo/redo remotables are part to the Reason document scope (as you say) and therefore can always be accessed. The problem is that the item I want ("Master Level" of the SSL mixer) is not part of the Reason document scope and therefore not "global" in the same way.
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
-
- Information
-
Who is online
Users browsing this forum: Google [Bot], Trendiction [Bot] and 4 guests
Share and download patches!
Join ReasonTalk on Slack!