Re: Reason SSL Mixer Hardware Controller
Posted: 04 Oct 2017
Hi Allison - just curious if you've worked on anything else for this?
Hope all is well!
Hope all is well!
Hey Chris! [emoji112]Chris_ocon wrote:Hi Allison - just curious if you've worked on anything else for this?
Hope all is well!
Oh most definitely is it a lot of work. I have crowdfunded products before that ended up hitting their goal, that were then commercialized and sold directly. So hopefully the only issues that remain right now are mostly "known unknowns" and not too many "unknown unknowns", which are the scariest ones!
Something you said above caught my attention. This could totally be the wrong way to go, but allow me to run with it for a bit to see how it "feels".amcjen wrote: ↑13 Oct 2017So first task for me is to get a solid Remote connection over USB-MIDI, working bidirectionally between a single physical push button and a single Reason mixer button. Then I’ll add the touchscreen support for some on-controller info and UI. From there I’ll expand to pots, and then groups of pots for each section of the center channelstrip (EQ, comp/gate, etc), then to fader, and so on. I intend to keep all sections separate physically so they can be moved around and used in different configuration layouts. My hope is that this will allow the ideal physical layout to emerge through significant use by several Reason users.
That's what I'm after at this point. I've given up on my original vision because, quite frankly, it wasn't well thought out, and this thread revealed a lot more consideration than my "hey all you know what would be cool?" ramblings early on. So let's dig into this!
Okay, now you're talking. I think this is a really cool approach for a couple of reasons. One, the Reason mixer in the program itself will continue to change (delay comp being one of the most recent ones. A mono button will certainly show up soon enough too). So this lets single modules be swapped out/upgraded as needed.selig wrote: ↑15 Oct 2017What we need is a foundation to build upon. A protocol for connecting hardware to Reason, with all the tough bits worked out for us! I’d love to build a few modules myself, but not if I ALSO had to deal with the power supply, the chassis, the communications etc. It will be enough work just to build a module!
Yep, exactly like this. I'm not into modular synths but familiar enough with the idea that it could work really well to standardize on one of these existing layouts that most closely matches the mixer channel widths. I know there's the 500 series, then all the modular stuff (MOTM, Eurorack, Moog, etc). In quickly looking at it, I think MOTM is a preferred choice b/c it's already 1.75" wide, and 8 of them gets you just over the 13" for an 8-fader bank.selig wrote: ↑15 Oct 2017Sure, I’d also love to have all the modules built for me, but with the option to choose which ones to add and when to add them. Sort of like how modular synth guys like MOTM (module of the month) and many others did it. You can buy the kits, or you can buy the modules - we also provide the power supply! Or you can design your own modules and integrate them into our system.
Yep, exactly. I feel comfortable about protocols/comms. Need a little coordination and research to determine what the appropriate bandwidth should be between modules, and across the whole system. Reason supports 64 channels IIRC, what does Remote bandwidth requirements look like when 64 meters are bouncing along? I've no idea, but really want to know, as this will dictate what protocol to use.
It totally does.
Awesome! Will definitely need the Remote help—so glad you know it well!Catblack wrote:Wow Allie, I finally understand the scope of this! I'm totally down with an extensible euro-rack-esque modular midi controller. I never thought about using those size/power standards. Amazing. I'll help however I can with the Remote side of things.
This sounds really cool, and I was following what you described up until you mentioned showing what your controllers are controlling while cruising around the rack. Would you explain a little more? My curiosity is piqued!“Catblack” wrote:On a side note, speaking as someone who delves into Remote and can't help buying random midi controllers (seriously, I've got at least 5 that need codecs sitting right here, and more in storage,) I think part of the general problem is that one doesn't know just is mapped to what. I believe there's a great solution (that a couple of other Remote devs, not me, have gotten working) in using WebMidi on a localhost served web page to display data values and remotable names out of Remote. The potential for this would be to have a web app that uses css to arrange the data and show you what your controllers are controlling, as you cruise around the rack. It's going to be sometime next year before I get around to working on this; I'll make a thread asking for help at some point.
There's a pair of Utility functions, remote.is_item_enabled() and remote.get_item_name() that can be paired together with the "Constant Value" (as the Remote dev manual refers to it) trick to detect when your device changes. Then you could tell what has been assigned to what controller in the .remotemap file, and pass the name of the remotable out to your display as ascii sysex. This is what the Novation Automap codec is very concisely doing. You can take a look yourself, look at remote_set_state(). That codec, bit hard to read, defines 256 knobs, 256 buttons and then passes it back to the Automap program for display. (Generating a more complete Automap .remotemap or Automap xml files is one of my backburner projects.) The big plus is that you only have to define what is mapped inside the .remotemap and then parse that once per device each time the script runs as the device gets selected. A little extra coding for a second constant value for the group variation and you could use the .remotemap groups feature too.
I think I'm getting it but it's become clear to me that I have some work to do to get caught up on the Remote protocol (I didn't know there were even a groups feature, for instance).Catblack wrote: ↑16 Oct 2017There's a pair of Utility functions, remote.is_item_enabled() and remote.get_item_name() that can be paired together with the "Constant Value" (as the Remote dev manual refers to it) trick to detect when your device changes. Then you could tell what has been assigned to what controller in the .remotemap file, and pass the name of the remotable out to your display as ascii sysex. This is what the Novation Automap codec is very concisely doing. You can take a look yourself, look at remote_set_state(). That codec, bit hard to read, defines 256 knobs, 256 buttons and then passes it back to the Automap program for display. (Generating a more complete Automap .remotemap or Automap xml files is one of my backburner projects.) The big plus is that you only have to define what is mapped inside the .remotemap and then parse that once per device each time the script runs as the device gets selected. A little extra coding for a second constant value for the group variation and you could use the .remotemap groups feature too.
This sounds amazing. I'm sure there will be Javascript devs who will reach out. If you come up short, I could help with a quick and dirty interface for this (though I have my work cut out for me with this comms/power/audio protocol now!)Catblack wrote: ↑16 Oct 2017It was just an aside, but I imagine being able to use an old monitor and a raspberry pi accepting midi to give me a view of what my controllers are mapped to. I would need help with the Webmidi/javascript side of things, but I do believe it's a project that would benefit a large amount of Reason users. I was planning on starting on it next year, but if any javascript programmers want to PM me, maybe we can get it rolling a little early. I do think this idea could pair well with your project.
Woah, that last one sounds horrible. How do you work around it? Do you just feed it an Active Sense (sysex 11111110) every 300ms or something so it keeps processing?Catblack wrote: ↑16 Oct 2017There are some gotchas with Remote to watch out for. Mainly that Remote gets a low priority and is suspended when song files or samples load. You can't really get an accurate display of the transport bar position. And also what I refer to internally as "the wall", which is that Remote won't fire off messages back into itself independently, (ala remote.handle_input(),) and needs an inputted midi signal to come into remote_process_midi(). I call it "the wall" because sooner or later you'll come up with a cool Remote idea and hit it.
amcjen wrote: ↑16 Oct 2017
Woah, that last one sounds horrible. How do you work around it? Do you just feed it an Active Sense (sysex 11111110) every 300ms or something so it keeps processing?Catblack wrote: ↑16 Oct 2017There are some gotchas with Remote to watch out for. Mainly that Remote gets a low priority and is suspended when song files or samples load. You can't really get an accurate display of the transport bar position. And also what I refer to internally as "the wall", which is that Remote won't fire off messages back into itself independently, (ala remote.handle_input(),) and needs an inputted midi signal to come into remote_process_midi(). I call it "the wall" because sooner or later you'll come up with a cool Remote idea and hit it.
Ah wow, yeah, that sounds like a mess. I don’t yet see how this could bite us on this project, but from the sound of it, it very well will happen. Hmmm.Catblack wrote: About a year ago I suggested adding "remote.generate_input()" to get around this. If they added something like that, you'd be able to do my 6 button pitch wheel, or auto generating drum patterns from inside Remote or a host of other things. I doubt they are going to change much about the Remote system other than make it more efficient, like they did with the last 9.5 point upgrade.
Yep! This is how I’m thinking of it now too.Chris_ocon wrote:I am really digging the modular approach!! It allows people to fine tune to their needs and budget. And you can hone in how YOU want to mix-- if you never use inserts don't use the money or space on that module.
Oh totally. The way you describe it, I could see specific modules for sections of the mixer (compressor, EQ, etc), but then probably also general knob/button modules. Might have to consult with Catblack on how to make those knobs re-mappable to devices dynamically without editing Remote map files, but def could be awesome.Chris_ocon wrote:It also makes me think, (along the lines of what Allison said about the RE controlling some hardware modules that are installed along with the mixer modules) you could maybe make some modules work to control other things in Reason too. For example, I have an audio splitter after my main out giving me two stereo pairs. Each go into their own Selig Gain then to a hardware out pair 1/2 & 3/4. The first is for my monitors and the second for headphones. I then have the faders of the Selig Gains mapped to some faders on my Akai controller allowing me quick hands on monitor level control. Seems like I could just work a couple extra faders into the mixer for this. Possibly even motorized so they would reset accordingly when opening a new project.
I’m so glad you mentioned this! When I was thinking about this project on Sunday, I was like “I would love to have a single Pulveriser control—I use it all the time”. Let all the hardware effect modules bloom. . A Tsar-1 would be amazing too.Chris_ocon wrote: It further makes me think about (and this might be pushing it) making almost dedicated mini effects controllers. Example, if you always keep a Tsar-1 in your first send you could maybe put together a module that you map to the parameters on there, allowing you the feel of having outboard effects.
Awesome! So glad to hear. I’m sure there will be lots of work ahead.Chris_ocon wrote: Everything about this project is awesome!! I'm happy to help any way I can
Code: Select all
F0
<device id bytes>
<byte for module config request>
<byte for module number, 0 is main module>
F7
Code: Select all
F0 <device id bytes>
then for each control
<byte for control's channel>
<byte for control's CC or note #>
<byte consisting of bits telling us about control:
is_input/is_output/bits for type of control, button, delta, value, ...?>
[emoji7]. This sounds amazingCatblack wrote:I hope my Remote digressions haven't been too confusing.
From the Remote side, I'd like to see the main module respond to the standard midi sysex request. ("f0 7e 7f 06 01 f7" I think?) and have the return sysex ID string have a couple of extra bytes that will let us determine how many submodules are connected to the main module. Then we could tailor things to have multiple secondary sysex requests to the main module -- one for each module connected -- so that the sysex returned from the device isn't as large. I'm imagine it'll be 2 or 3 bytes for each control, which could add up. Keeping sysex strings smaller is always better, I think.
As long as we have a way to query and build up an internal picture of what we have to work with, we should be able to map controls to Remotables. So if we had a request:and the return:Code: Select all
F0 <device id bytes> <byte for module config request> <byte for module number, 0 is main module> F7
I'm pretty sure if we set it up this way we'll be able to define items dynamically in the lua. If not (possibly because of the loading order of remote_init) we'll define a slew of items and then map them to the expected midi that the sysex describes. (Another side note: You can define all the Items in the lua you want, you only get an error if an Item is in the .remotemap that isn't in the lua.)Code: Select all
F0 <device id bytes> then for each control <byte for control's channel> <byte for control's CC or note #> <byte consisting of bits telling us about control: is_input/is_output/bits for type of control, button, delta, value, ...?>
Indeed! If you had per-module undo/redo, It would let you A/B any change on any module. You could then A/B a different change on another module simultaneously.Oh and don't forget when thinking up modules that having external Undo and Redo buttons is really quite awesome!