The problem with Reason Remote

This forum is for discussing Propellerhead's music software. Questions, answers, ideas, and opinions... all apply.
User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 27 Mar 2018

I came to think of this again in another thread and I mentioned this a few times but I'd like to get a few opinions on this matter. It's about the situation with Reason Remote, i.e. the way MIDI control surfaces are integrated into Reason.

IMO the Props coded themselves into a corner with Remote support and now REs. Its not clear who should update the scripts / mappings. Because all plugin mappings are contained in the script for the control surface who's supposed to update them for each new RE? The Props because they put them out? The hardware manufacturer for each RE that comes out? The plugin manufacturer for each control surface that exists?

As said, the issue is that the mapping is in the script for the controller. There is no general mechanism for control surfaces to map controller knobs to "parameter 1 of plugin", "parameter 2 of plugin" etc. and RE's don't have to care about any mapping either. So it can't currently be solved like in other DAWs where usually the general functionality of the control surface is handled by the DAW but the single parameters are "filled in" from what the currently selected plugin supplies.

So yeah, on one hand, the way I use control surfaces with Reason is mostly combining a few synths and effects and then mapping single parameters to the connected control surfaces by hand, creating a massive "modular synth" so all of the default mappings don't really apply except for the one BCF 8-Fader main mixer control...

On the other hand this (and the poor integration of the Mackie Control surface with only one XT supported) has kept me from trying to set up my mixing place with Reason at least as an alternative to my usual mix-job go-to Logic. I do like to mix hands-on instead of using a mouse but with Reason it's all kinds of backwards doing that, starting with the fact that theres no "fixed" place for plugins (rack) and ending with this funny Reason Remote situation.

Another option would of course be a very powerful editor for the actually very powerful underlying script and mapping system... :o :geek:

So if anyone wants to ramble about this stuff as well.... ;)

tanni
Posts: 97
Joined: 19 Jul 2015

Post 28 Mar 2018

Well, I dont use the "normal" mappings, I only use Remote override mapping, because I only use it for Live and music-sessions when I want to record my playing data and the controller data, like filter cutoff, pattern changes etc. in the sequencer. You need the surface locking feature for that when you will adress different reason devices from one controller (like AKAI MPK261) and record the data in the sequencer all simultaneously in the different tracks.

With the koshdukai channel driver you can adress now each of 16 midi-channels for one controller device with the surface locking feature. Only then the controller data were record correctly in the tracks.
Why do propellerheads dont support Midi channels here in the drivers ? My Akai MPK261 has two usb driver in windows with each 16 channels. Only the koshdukai driver solves the problem to adress all 16 channels to different devices in Reason from one physical controller.

Further there are a lot of hardware controllers which are still not implemented in Reason generally. Im not a programmer and I cant write these Lua scripts, Im a musician.

Yes, thats the question, who has to write the scripts ?

The Nectar keyboard with all these implementations are nice, but I dont need that for all devices. If I use controllers I want to use them blind, without having to look in a further display on the controller and switch in menus. I only use 1 to 1 settings. Like the Behringer BCR2000, it has a directly response feedback on the LED on the controllers. So I see directly were my step ist and were I begin to change it when I for example change the cutoff from a filter.

What I further would like to see is a dedicated Channel strip controller from Propellerheads. That would be amazing, so you could mix and handle the EQ and compressor and volume etc. from this without a computer mouse and without need the Pc-monitor. With directly feedback like in the LED on the Behringer BCR2000.

hope it makes sense what I write here, english is not my native :)

User avatar
artotaku
Posts: 472
Joined: 09 May 2015
Location: Munich, Germany

Post 28 Mar 2018

normen wrote:
27 Mar 2018
As said, the issue is that the mapping is in the script for the controller. There is no general mechanism for control surfaces to map controller knobs to "parameter 1 of plugin", "parameter 2 of plugin" etc. and RE's don't have to care about any mapping either. So it can't currently be solved like in other DAWs where usually the general functionality of the control surface is handled by the DAW but the single parameters are "filled in" from what the currently selected plugin supplies.
Do you mean that it should be possible that the lua codec can query which plugin/RE is currently selected in Reason (either if the controller is locked to the device or its MIDI track is selected)? If so, this is possible if you set a remote item (e. g. "deviceName") to a hardcoded value e. g. "Thor", in the scope for the device in the remotemap which can be queried from the codec and you can execute specific logic for e. g. Thor.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 28 Mar 2018

artotaku wrote:
28 Mar 2018
Do you mean that it should be possible that the lua codec can query which plugin/RE is currently selected in Reason (either if the controller is locked to the device or its MIDI track is selected)? If so, this is possible if you set a remote item (e. g. "deviceName") to a hardcoded value e. g. "Thor", in the scope for the device in the remotemap which can be queried from the codec and you can execute specific logic for e. g. Thor.
Way too complicated, this still leaves data that should be manipulated by many in a single file managed by one. Meaning the Props or the control surface developers have one file where all RE developers would have to enter their specific parameters (and plugin names).

The REs should report their parameters, ideally in an oder they would want it displayed on a generic control surface and the plugin should arrange those parameters and display "forward/back/mode" buttons etc. But as it is now thats not the case.

RobC
Posts: 1161
Joined: 10 Mar 2018

Post 28 Mar 2018

I'll just build an Arduino-based MIDI controller myself, with what I need, and just create the Remote/MIDI for the devices I use. Nobody's gonna shape anything for an individual's needs, so gotta DIY. I mean, you can make everything professionally in the tiny field of a complete profession, with a little effort. (Likewise, you can draw a technically perfect, professional triangle - even if it won't make you an architect.) "Be friend, my water." - or so the quot goes. xD

User avatar
artotaku
Posts: 472
Joined: 09 May 2015
Location: Munich, Germany

Post 28 Mar 2018

normen wrote:
28 Mar 2018
artotaku wrote:
28 Mar 2018
Do you mean that it should be possible that the lua codec can query which plugin/RE is currently selected in Reason (either if the controller is locked to the device or its MIDI track is selected)? If so, this is possible if you set a remote item (e. g. "deviceName") to a hardcoded value e. g. "Thor", in the scope for the device in the remotemap which can be queried from the codec and you can execute specific logic for e. g. Thor.
Way too complicated, this still leaves data that should be manipulated by many in a single file managed by one. Meaning the Props or the control surface developers have one file where all RE developers would have to enter their specific parameters (and plugin names).

The REs should report their parameters, ideally in an oder they would want it displayed on a generic control surface and the plugin should arrange those parameters and display "forward/back/mode" buttons etc. But as it is now thats not the case.
Yes, that would be very handy. I think the current implementation is getting worse, since more and more devices (due to RE format and VSTi) and (cheap) midi controllers are available in Reason which makes the amount of custom configuration for codec developers a big effort.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 18 Apr 2018

So with the possible advent of a Reason remote control hardware platform I think this topic deserves some thought again.

I hoped some Props representative would at least give a hint at their view on things but apparently theres generally few ideas on this.. From what came up in this thread it seems that users mainly seem to want to create very personalized setups - so maybe actually thinking about an editor is a good idea?

I'm thinking about a very lightweight LUA "base script" framework to handle the most typical tasks (layer switching etc.) which can be extended using a GUI. That GUI could be based on Node.JS / Electron which would possibly simplify collaboration as JavaScript is a relatively easy and platform-independent language and theres a lot of web designers out there to make the GUI pretty. Or something like that, whatever language or framework.

...now obviously I'm not saying I want to do all that work :) But if theres some possible partners in crime I'm all ears.

User avatar
QVprod
Posts: 2338
Joined: 15 Jan 2015

Post 18 Apr 2018

Agreed on the problem the current system causes. Its quite capable but a lot of work for the user to customize themselves. However I'm not sure if any DAW has a better solution. I know you mention how the Mackie control works, but the whole selling point of the NKS format is the plugin mappings the developers provide themselves. Perhaps a system like that could be implemented for at least REs. Aside from that Remote's major limitation for effective mapping for mixing is the fact that every device requires a sequencer track in order to be controlled without locking a control surface to the device. That definitely needs an overhaul.

User avatar
ljekio
Posts: 680
Joined: 21 Jan 2015

Post 18 Apr 2018

With all its shortcomings, Remote more convenient to use and configure settings than in any other DAW where I worked.
At least, you will not have routine settings in every new project, just set up (yes, the threshold of entrance is complicated and high) once as necessary for me.

User avatar
amcjen
Posts: 202
Joined: 14 Apr 2017

Post 20 Jun 2018

normen wrote:So with the possible advent of a Reason remote control hardware platform I think this topic deserves some thought again.
I see what you mean in this thread, on how it puts a bit of an unknown on who should maintain the scripts. I can speak at least for myself that for the hardware project linked above, the controller creator should maintain their own scripts. Specifically because they’ll understand what controls should be connected to what hardware components.

But my perspective is different than most in that for most cases I’ll likely have a 1:1 relationship from an onscreen controller to a particular physical controller, for each channel.

But I can see how this is difficult for a controller manufacturer who wants a genera purpose controller for all current and future REs. That’s rough.
normen wrote: I hoped some Props representative would at least give a hint at their view on things but apparently theres generally few ideas on this.. From what came up in this thread it seems that users mainly seem to want to create very personalized setups - so maybe actually thinking about an editor is a good idea?
I would think an editor would be a great idea.

I’ve asked for Remote additions like assigned track color to be included and while they were quick to respond, they made it clear it’s a low priority.
normen wrote: I'm thinking about a very lightweight LUA "base script" framework to handle the most typical tasks (layer switching etc.) which can be extended using a GUI. That GUI could be based on Node.JS / Electron which would possibly simplify collaboration as JavaScript is a relatively easy and platform-independent language and theres a lot of web designers out there to make the GUI pretty. Or something like that, whatever language or framework.

...now obviously I'm not saying I want to do all that work :) But if theres some possible partners in crime I'm all ears.
If you look on the SSL hardware controller thread, there are a couple people who have offered to help in this exact area. I’m game too though my time priority goes to HW first. But I know I’ll need an editor for my project, and would rather collaborate on one that is more robust than one that is particular to a certain controller.

On the other hand, some tools like this that don’t have strong product ownership and management tend to become malnourished projects. If it makes sense to make an editor as part of the SSL project, I’m happy to give it a home there. If it’s something someone else wants to give a home to, cool with that too. Either way I’m down to help.

jlgrimes
Posts: 355
Joined: 06 Jun 2017

Post 20 Jun 2018

normen wrote:
27 Mar 2018
I came to think of this again in another thread and I mentioned this a few times but I'd like to get a few opinions on this matter. It's about the situation with Reason Remote, i.e. the way MIDI control surfaces are integrated into Reason.

IMO the Props coded themselves into a corner with Remote support and now REs. Its not clear who should update the scripts / mappings. Because all plugin mappings are contained in the script for the control surface who's supposed to update them for each new RE? The Props because they put them out? The hardware manufacturer for each RE that comes out? The plugin manufacturer for each control surface that exists?

As said, the issue is that the mapping is in the script for the controller. There is no general mechanism for control surfaces to map controller knobs to "parameter 1 of plugin", "parameter 2 of plugin" etc. and RE's don't have to care about any mapping either. So it can't currently be solved like in other DAWs where usually the general functionality of the control surface is handled by the DAW but the single parameters are "filled in" from what the currently selected plugin supplies.

So yeah, on one hand, the way I use control surfaces with Reason is mostly combining a few synths and effects and then mapping single parameters to the connected control surfaces by hand, creating a massive "modular synth" so all of the default mappings don't really apply except for the one BCF 8-Fader main mixer control...

On the other hand this (and the poor integration of the Mackie Control surface with only one XT supported) has kept me from trying to set up my mixing place with Reason at least as an alternative to my usual mix-job go-to Logic. I do like to mix hands-on instead of using a mouse but with Reason it's all kinds of backwards doing that, starting with the fact that theres no "fixed" place for plugins (rack) and ending with this funny Reason Remote situation.

Another option would of course be a very powerful editor for the actually very powerful underlying script and mapping system... :o :geek:

So if anyone wants to ramble about this stuff as well.... ;)

The issues I have with Remote.


1. Props haven't updated it in awhile. Their controller support for codecs are lacking. One their website they show an Akai Advance but yet they have no codec for it. Akai doesn't have a preset for Reason. So you are stuck with Remote overrides.

2. They don't allow users to create Codecs. Problem 1 wouldn't be a big deal if they opened up users to creating Codecs. Ableton allows for all types of hacks which works for situations when the company can't work fast enough using M4l.

3. Midi map mode could be faster. In Ableton you can midi map a whole list of parameters fast in one swoop and set ranges. Reason works more primitive. Using the Combinator gives you more flexibility though.

4. REs are pretty much left in the dust for many controllers.


Back when Remote came out it was special as Reason did a better job of supporting a variety of controllers. Their support is slipping though now.

With Codecs, Remote works pretty well.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 21 Jun 2018

jlgrimes wrote:
20 Jun 2018
The issues I have with Remote.


1. Props haven't updated it in awhile. Their controller support for codecs are lacking. One their website they show an Akai Advance but yet they have no codec for it. Akai doesn't have a preset for Reason. So you are stuck with Remote overrides.

2. They don't allow users to create Codecs. Problem 1 wouldn't be a big deal if they opened up users to creating Codecs. Ableton allows for all types of hacks which works for situations when the company can't work fast enough using M4l.

3. Midi map mode could be faster. In Ableton you can midi map a whole list of parameters fast in one swoop and set ranges. Reason works more primitive. Using the Combinator gives you more flexibility though.

4. REs are pretty much left in the dust for many controllers.


Back when Remote came out it was special as Reason did a better job of supporting a variety of controllers. Their support is slipping though now.

With Codecs, Remote works pretty well.
1) Probably a result of what I say here imo - or do you think theres other reasons?
2) Isn't really true, you can create your own Remote plugins no problem.
3) The MIDI mapping isn't really part of Remote.
4) Thats what I'm talking about and looking for solutions to here :)

So in terms of solutions? Any ideas? :)

@amcjen: Good. (Is all I can say right now ;))

mcatalao
Posts: 1027
Joined: 17 Jan 2015

Post 21 Jun 2018

normen wrote:
27 Mar 2018
IMO the Props coded themselves into a corner with Remote support and now REs. Its not clear who should update the scripts / mappings. Because all plugin mappings are contained in the script for the control surface who's supposed to update them for each new RE? The Props because they put them out? The hardware manufacturer for each RE that comes out? The plugin manufacturer for each control surface that exists?
I think it's any of them. Including the user (at least for the remote file), but maybe you're refering the lua codecs.
Anyway, I parcially agree with them being on a corner, because i trully believe remote is one of the most versatile midi controller interface that exists.

That being said, i would like to see something inside reason that took care of the remote file. I understand that a lot of users are not as "script editing" savvy as I so it would be great to see something that would allow a user to edit his remote file.

PS.: I use solely reason as my main daw and i am mixing hands on with 3 BCF2000 and a BCR2000. I can control all channels of reason's mixer (24 at a time), and i can even focus on a channel and control all of the channel parameters with the BCR2000.

Image

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 21 Jun 2018

mcatalao wrote:
21 Jun 2018
I think it's any of them. Including the user (at least for the remote file)
But at the moment we get most of the scripts from PH, some from others, some hardware manufacturers update for plugins, some plugin devs update for hardware..

Maybe just having a central github repo for codecs would make sense? And a way for Reason to update from that repo - even with different branches like „Stable“ „Experimental“ „PH Only“ and such? And maybe even the option to use a completely different fork...

Any ideas on that from PH even?

mcatalao
Posts: 1027
Joined: 17 Jan 2015

Post 21 Jun 2018

Normen,

Here are 2 interesting resources:

A list of all devices that have remote and Lua Codecs and are supported by reason (8 and beiound). 153 devices were logged in the site at the time. I don't know if we can say the same for other daws.

http://remote.artotaku.de/remote-codecs

Second, an SOS article about remote, including an explanation for Lua Codecs (they can be edited by the User, as Lua codecs are simple html and descriptor files). From my interpretation the Lua codecs, define the device behaviour and the Remote Maps, map reason functions to what you defined in the codec.

https://www.soundonsound.com/techniques ... les-reason

From my interpretation, Propellerheads created a way for anyone create and extend the remote functionality and the responsability to do so stands with the manufacturers (again MY interpretation).

I still lack to understand how this works for the BCF and BCR2000 as none of them have Lua codecs: Still reason makes a midi dump to it when you open reason connected to a BCF/BCR2000, so this functionality might even be in the application or in the BCF's.

mcatalao
Posts: 1027
Joined: 17 Jan 2015

Post 21 Jun 2018

Oh and additionally...

As far as my knowledge goes, to create codecs ditributable with reason, you must be a registered developer. That might explain why the inclusion of new codecs is a bit slow.

User avatar
Carly(Poohbear)
Posts: 2357
Joined: 25 Jan 2015
Location: UK

Post 21 Jun 2018

normen wrote:
21 Jun 2018

Maybe just having a central github repo for codecs would make sense? And a way for Reason to update from that repo - even with different branches like „Stable“ „Experimental“ „PH Only“ and such? And maybe even the option to use a completely different fork...

Any ideas on that from PH even?
John at "Reason remoter" is trying to centralise things http://www.reasonremoter.uk/

OUR OBJECTIVE
Our aim is to help more Reason users benefit from the use of custom MIDI Remote codecs/maps for better control over Reason by joining Remote authors and Reason users together. A place where you can share Remote codecs/maps or documentation, make wishes for new codecs/maps and generally help you take control over using Reason in a hands-on way.


I've been looking into this as I'm looking for a new home for the Nektar maps as I have an idea of allowing customers to customise the maps via dropdown boxes etc..

FYI I have a database with over 3000 remote maps.

PoohBear

----------------------------------------------------------------------------------------------------------
T&T's viewtopic.php?f=5&t=7503909
My Youtube channel https://www.youtube.com/channel/UCqCNsA ... p4cQF4j-8A
----------------------------------------------------------------------------------------------------------
My Soundcloud Page ....... Nektar Mappings
----------------------------------------------------------------------------------------------------------

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 21 Jun 2018

Carly(Poohbear) wrote:
21 Jun 2018
John at "Reason remoter" is trying to centralise things http://www.reasonremoter.uk/

OUR OBJECTIVE
Our aim is to help more Reason users benefit from the use of custom MIDI Remote codecs/maps for better control over Reason by joining Remote authors and Reason users together. A place where you can share Remote codecs/maps or documentation, make wishes for new codecs/maps and generally help you take control over using Reason in a hands-on way.


I've been looking into this as I'm looking for a new home for the Nektar maps as I have an idea of allowing customers to customise the maps via dropdown boxes etc..

FYI I have a database with over 3000 remote maps.

PoohBear
There, now thats what I mean. Do you know if they tried to get PH in the boat somehow? I don't know since when they're doing this but afaics the situation gradually got worse as outlined in the OP.

Edit: Invited him to the thread.

User avatar
Carly(Poohbear)
Posts: 2357
Joined: 25 Jan 2015
Location: UK

Post 21 Jun 2018

normen wrote:
21 Jun 2018


There, now thats what I mean. Do you know if they tried to get PH in the boat somehow? I don't know since when they're doing this but afaics the situation gradually got worse as outlined in the OP.

Edit: Invited him to the thread.
I don't think they have tried getting PH onboard and it's quite a new site.

jlgrimes
Posts: 355
Joined: 06 Jun 2017

Post 21 Jun 2018

normen wrote:
21 Jun 2018
jlgrimes wrote:
20 Jun 2018
The issues I have with Remote.


1. Props haven't updated it in awhile. Their controller support for codecs are lacking. One their website they show an Akai Advance but yet they have no codec for it. Akai doesn't have a preset for Reason. So you are stuck with Remote overrides.

2. They don't allow users to create Codecs. Problem 1 wouldn't be a big deal if they opened up users to creating Codecs. Ableton allows for all types of hacks which works for situations when the company can't work fast enough using M4l.

3. Midi map mode could be faster. In Ableton you can midi map a whole list of parameters fast in one swoop and set ranges. Reason works more primitive. Using the Combinator gives you more flexibility though.

4. REs are pretty much left in the dust for many controllers.


Back when Remote came out it was special as Reason did a better job of supporting a variety of controllers. Their support is slipping though now.

With Codecs, Remote works pretty well.
1) Probably a result of what I say here imo - or do you think theres other reasons?
2) Isn't really true, you can create your own Remote plugins no problem.
3) The MIDI mapping isn't really part of Remote.
4) Thats what I'm talking about and looking for solutions to here :)

So in terms of solutions? Any ideas? :)

@amcjen: Good. (Is all I can say right now ;))
I guess I need some help in setting up an Akai Advance so it will at least have some basic controls.


All I have is basic transport, changing tracks saved in a template. Every thing else is remote overrides.

djsmex
Posts: 53
Joined: 23 Aug 2016

Post 21 Jun 2018

Hi, I'm the guy behind www.reasonremoter.uk and I don't have any direct association or afiliation with PH but do have some ideas to assist with remote mapping. I currently maintain a complete list of remote info files for all Reason REs and devices but don't maintain any third party VST remote info files.
I did contact PH before setting up the site and although they were happy for me to do so independently they didn't wish to have any direct links with the site or any responsibility over the site. This may be a resources concern within PH as there are so many controllers on the market and so widely varied user requirements.
To answer some questions, I believe the BCR and BCF were part of the original remote system, before LUA codecs and as such are hard coded into the software. That said, it does not stop people writing new LUA codecs for these devices. However, I also believe these controllers are discontinued so I wouldn't think PH or Behringer will be writing any new codecs.
Anyone can register for free with PH as a developer for Remote codecs, you will need to know a little about LUA scripting and have a good grasp on MIDI as well as details of the MIDI I/O of any control surface you wish to write a codec for.
Go to: https://www.propellerheads.se/developer
The reason for having separation between codecs and remote maps, is the codec acts as the MIDI interface between your hardware and the Reason software, while the remote map is how you configure the controls defined in the codec to work with devices in Reason. This gives the freedom for users to configure remote maps without knowing the LUA codec or MIDI I/O.
I totally accept not everyone is ready to learn LUA scripting and may not understand how the tabbed delimitated remote map files work. This is why I started the reasonremoter site.
As for who should write LUA codecs for specific control surfaces, I think PH wanted both hardware manufacturers, RE developers and Reason users to have the freedom to do so without the limitations of a single intergrated solution. As LUA codecs can be not only hardware specific but can also have functionality for specific REs like the codecs for the Grid64g & Grid64n by Retouch.
I don't know why MIDI controller manufacturers are not doing more with Reason and I don't understand why some manufacturers keep their MIDI I/O data private. Akai apc mini, for example, doesn't publish the MIDI data for the pad LEDs, I found this out from a third party.
My idea is to use my site to bring Reason users and codec developers together, a place to find custom codecs, remote maps and related resources.
I also have plans to attempt to develop a web based collection of tools that can help people create their own LUA codecs, remote maps and perhaps remote map documentation as a reference of remote mappings.
I have the idea of using the WebMIDI JS API, to create a simple MIDI learn function together with a simple web UI that can create basic LUA Codecs. It gets a lot more involved when looking at adding MIDI feedback to controllers as this is very manufacture specific and there's no easy way of ensuring it will play nice with any controller.
A similar web UI tool can be used to create remote maps. It will need data for specific codecs built-in so the user need only select their controller (if available) and then select a remote item for each available control surface item. Its would be made more complex when adding the option for remote map groups and even more tricky if it uses a graphic UI of the control surface and Reason device, RE or VST.
The idea for a document tool, is a web UI that can scan a remote map and generate a PDF document that shows what control surface item does what on what device when in focus. This may be tricky for controllers that have multiple functions on single controls like the FaderFox LV2/LC2. It may also be tricky to show graphically when remote items don't match up to on screen controls or when a device has multiple display modes.
The last idea I had was a web based tool a little like the Novation automap, but instead of being manufacturer specific, have it use MIDI learn type features so people can build up their own control map with one or more controllers and have work with a single codec and remote map. This could act as a control display as well as a easier way to configure remote mappings through a simple web app. It may not be for everyone and like Novation's Automap will require the remote map updated with each new device.
I do think there is some limitations with how MIDI focus is given to devices in the rack and the tracks in the sequencer. As I understand it, you can only give MIDI focus to a device in the rack either by it's associated track in the sequencer or by clicking with a mouse in the rack to place the MIDI focus icon in the left edge of the rack. While you can switch sequencer tracks via a controller, I don't believe you have the same feature of switching MIDI focus between devices in the rack via a controller. You also don't have any MIDI remote access to the browser panel.
You do have the controller lock feature in reason, so you can have a specific controller codec locked to a single device which allows for things like having the keyboard control a synth while the knob/faders on the same controller control a player or effect device.
There are also options like the Hamu rack extensions or the EMI device with midiloop that can add flexibility to remote mappings.
If anyone would like to contribute their codecs, remote maps or wish to share usefull resources on reasonremoter, please get in touch.
It's a relatively new site and I am hoping to make some site improvements, I do this work in my spare time but do my best to keep the information current.
The site is free to use and join, and if anyone is able to help with any of my above ideas, please get in touch.
best, John - djsmex

User avatar
amcjen
Posts: 202
Joined: 14 Apr 2017

Post 21 Jun 2018

djsmex wrote:Hi, I'm the guy behind www.reasonremoter.uk <snip>
The site is free to use and join, and if anyone is able to help with any of my above ideas, please get in touch.
best, John - djsmex
Super cool of you to share your vision and goals with the site. I’m really glad you are doing this and looking forward to the web-based tools!

Allison

User avatar
theshoemaker
Posts: 588
Joined: 21 Nov 2015
Location: Germany

Post 21 Jun 2018

djsmex wrote:
21 Jun 2018
Hi, I'm the guy behind www.reasonremoter.uk and I don't have any direct association or afiliation with PH but do have some ideas to assist with remote mapping. I currently maintain a complete list of remote info files for all Reason REs and devices but don't maintain any third party VST remote info files.
I did contact PH before setting up the site and although they were happy for me to do so independently they didn't wish to have any direct links with the site or any responsibility over the site. This may be a resources concern within PH as there are so many controllers on the market and so widely varied user requirements.
To answer some questions, I believe the BCR and BCF were part of the original remote system, before LUA codecs and as such are hard coded into the software. That said, it does not stop people writing new LUA codecs for these devices. However, I also believe these controllers are discontinued so I wouldn't think PH or Behringer will be writing any new codecs.
Anyone can register for free with PH as a developer for Remote codecs, you will need to know a little about LUA scripting and have a good grasp on MIDI as well as details of the MIDI I/O of any control surface you wish to write a codec for.
Go to: https://www.propellerheads.se/developer
The reason for having separation between codecs and remote maps, is the codec acts as the MIDI interface between your hardware and the Reason software, while the remote map is how you configure the controls defined in the codec to work with devices in Reason. This gives the freedom for users to configure remote maps without knowing the LUA codec or MIDI I/O.
I totally accept not everyone is ready to learn LUA scripting and may not understand how the tabbed delimitated remote map files work. This is why I started the reasonremoter site.
As for who should write LUA codecs for specific control surfaces, I think PH wanted both hardware manufacturers, RE developers and Reason users to have the freedom to do so without the limitations of a single intergrated solution. As LUA codecs can be not only hardware specific but can also have functionality for specific REs like the codecs for the Grid64g & Grid64n by Retouch.
I don't know why MIDI controller manufacturers are not doing more with Reason and I don't understand why some manufacturers keep their MIDI I/O data private. Akai apc mini, for example, doesn't publish the MIDI data for the pad LEDs, I found this out from a third party.
My idea is to use my site to bring Reason users and codec developers together, a place to find custom codecs, remote maps and related resources.
I also have plans to attempt to develop a web based collection of tools that can help people create their own LUA codecs, remote maps and perhaps remote map documentation as a reference of remote mappings.
I have the idea of using the WebMIDI JS API, to create a simple MIDI learn function together with a simple web UI that can create basic LUA Codecs. It gets a lot more involved when looking at adding MIDI feedback to controllers as this is very manufacture specific and there's no easy way of ensuring it will play nice with any controller.
A similar web UI tool can be used to create remote maps. It will need data for specific codecs built-in so the user need only select their controller (if available) and then select a remote item for each available control surface item. Its would be made more complex when adding the option for remote map groups and even more tricky if it uses a graphic UI of the control surface and Reason device, RE or VST.
The idea for a document tool, is a web UI that can scan a remote map and generate a PDF document that shows what control surface item does what on what device when in focus. This may be tricky for controllers that have multiple functions on single controls like the FaderFox LV2/LC2. It may also be tricky to show graphically when remote items don't match up to on screen controls or when a device has multiple display modes.
The last idea I had was a web based tool a little like the Novation automap, but instead of being manufacturer specific, have it use MIDI learn type features so people can build up their own control map with one or more controllers and have work with a single codec and remote map. This could act as a control display as well as a easier way to configure remote mappings through a simple web app. It may not be for everyone and like Novation's Automap will require the remote map updated with each new device.
I do think there is some limitations with how MIDI focus is given to devices in the rack and the tracks in the sequencer. As I understand it, you can only give MIDI focus to a device in the rack either by it's associated track in the sequencer or by clicking with a mouse in the rack to place the MIDI focus icon in the left edge of the rack. While you can switch sequencer tracks via a controller, I don't believe you have the same feature of switching MIDI focus between devices in the rack via a controller. You also don't have any MIDI remote access to the browser panel.
You do have the controller lock feature in reason, so you can have a specific controller codec locked to a single device which allows for things like having the keyboard control a synth while the knob/faders on the same controller control a player or effect device.
There are also options like the Hamu rack extensions or the EMI device with midiloop that can add flexibility to remote mappings.
If anyone would like to contribute their codecs, remote maps or wish to share usefull resources on reasonremoter, please get in touch.
It's a relatively new site and I am hoping to make some site improvements, I do this work in my spare time but do my best to keep the information current.
The site is free to use and join, and if anyone is able to help with any of my above ideas, please get in touch.
best, John - djsmex
Most of what you write here ... I already have implemented in my python based remote codec. Where I parse the remote info files and autogenerate a codec and the remotemaps. It's very advanced and working, but I need more time to finish and polish it. I had to drop the auto output, but working on implementing it again.

I could generated per device codecs ... So many possibilities.

Here are short demos of a patch morpher based on my RePlay:ReCode SDK (still in Alpha)



and how I use it:



I'm also planning on a companion app for Android and iOS where you can customize and script reason in a more user friendly way.

With the current implementation you can control up to 127 devices without touching reason in any way.
I may provide the SDK in source code given a NDA, because it's still not compiled for early access.

Right now there is no propper value range mapping, everything is min 0 max 127. But that is somthing I can automate and work arround.
:PUF_figure: latest :reason: V10 on MacOS Sierra

User avatar
theshoemaker
Posts: 588
Joined: 21 Nov 2015
Location: Germany

Post 21 Jun 2018

And you could totally run the complete thing on an embedded controller running python, maybe even other implementations of python. Currently I'm using rtmidi which is cross platform binding running on macos, windows and linux. So I'm pretty sure this will also run on embedded devices, but I you also easily swap the midi library for using something else, or very specific.

And if necessary I'm pretty confident I could implement this autogeneration in other languages, too.

The codebase is quite small. Most of the code is generating things everywhere to create this API. So new devices are supported automatically by just exporting the remote info and regenerating. All could be highly automated to get even rid of this step.

Having said that. No need for a controller to develop an own codec.
:PUF_figure: latest :reason: V10 on MacOS Sierra

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

Post 21 Jun 2018

djsmex wrote:
21 Jun 2018
As for who should write LUA codecs for specific control surfaces, I think PH wanted both hardware manufacturers, RE developers and Reason users to have the freedom to do so without the limitations of a single intergrated solution. As LUA codecs can be not only hardware specific but can also have functionality for specific REs like the codecs for the Grid64g & Grid64n by Retouch.
Hey, so cool you got into this talk!

Great to see theres some plan for developing a web utility for this. Looks like theres enough interest/help to make that an open development too?

Otherwise I'll pick out my main concern in all of this right away as everything else you said just makes total sense to me :) Because the core issue still remains. Theres one file that logically "belongs" to the developer of the hardware but the paragraphs in that file "belong" to the plugin developers who have to create their plugins mappings. Thats where the idea for the github repo came from - so any of the three parties you mention can extend the files.

I mean theres more interest on the plugin developers side to have his plugin integrated than there is on the hardware manufacturers side. And if the hardware manufacturers update "their" plugins that means 50 people have to update their file - that takes weeks. The other way around one person has to update 50 files - that takes an evening. :)

  • Information
  • Who is online

    Users browsing this forum: Ahrefs [Bot], CommonCrawl [Bot] and 4 guests