Reason SSL Mixer Hardware Controller

[amcjen]

Def. Endless encoders (without indents I might add, I hate those), push-button capability, and with LED position markers is an already-have. The touch enabled I’ll be even better once that works.

And this is why designing these sorts of things are so time consuming! Finding cheap, correct size, correct functionality, easy to use, easy to manufacture, high quality parts to all work together. Whew. [emoji41]

[two shoes]

i read about this project when i first started using reason and had forgotten about it but i can't wait to see what you come up with.

[wendylou]

Awesome, I certainly will! I appreciate the help.

When you get to the point of seeking assistance from other makers, start a YouTube channel! Wintergaten, who is building the Marble Machine X music player, has reached out to worldwide makers for assistance on the project and it really has helped him overcome obstacles, even change the design direction with new ideas! Also, glad you're OK! I know too many people that were in accidents caused by distracted drivers.

Here's a video giving credit to all the helpers around the world:

[amcjen]

Oh my gosh. I love this project! And the video is a wonderful idea. Gotta get some video chops now.

[amcjen]

A LOT of Alps encoders arrived. Finding surplus is the way to go—about 85% off of retail.

This should make quite a few prototypes.

[selig]

Totally geeking out right now…
[emoji851][emoji851][emoji851]


Sent from some crappy device using Tapatalk

[vizay]

I imagine that's pretty much how geek heaven looks!

[Karim]

I'm IN HEAVEN!!!!!!

A LOT of Alps encoders arrived. Finding surplus is the way to go—about 85% off of retail.

This should make quite a few prototypes.

[Molotovbeatz]

Woooooowww craaaaazyy.

I wish success for you. Really, is there anywhere a scheme we could also follow if we would like to do a similar project?

[wendylou]

Homer-Reason-Alps.jpg (360 KiB) Viewed 5057 times

Removed by admin I guess...

[AttenuationHz]

[cinhcet]

awesome project.

Just two comments:
Are you aware of the fact that the remote protocol of reason is very limited? For example, the "seq" and "rack" buttons in the mixer cannot be mapped to a remote. Or even record enable is not available (which is very very very strange)
I do not understand why the propellerheads do not improve this protocol. Many people want control surfaces. But if a control surface is not integrated well enough, one quickly will use the mouse again.

As I see you are already quite involved in designing the hardware so it might not make much sense what I am suggesting, but http://ucapps.de/ is a very nice project that has solved many issues with midi control already.

[gscroggin]

awesome project.

Just two comments:
Are you aware of the fact that the remote protocol of reason is very limited? For example, the "seq" and "rack" buttons in the mixer cannot be mapped to a remote. Or even record enable is not available (which is very very very strange)
I do not understand why the propellerheads do not improve this protocol. Many people want control surfaces. But if a control surface is not integrated well enough, one quickly will use the mouse again.

As I see you are already quite involved in designing the hardware so it might not make much sense what I am suggesting, but http://ucapps.de/ is a very nice project that has solved many issues with midi control already.

Out of curiosity, are you referring to some sort of an API call, vs. the keyboard shortcut commands that can be mapped as macros? I ask because I do all the things you mentioned (and more) with my Contour Design ShuttlePROv2, unless I'm completely misunderstanding what you're talking about.

[cinhcet]

awesome project.

Just two comments:
Are you aware of the fact that the remote protocol of reason is very limited? For example, the "seq" and "rack" buttons in the mixer cannot be mapped to a remote. Or even record enable is not available (which is very very very strange)
I do not understand why the propellerheads do not improve this protocol. Many people want control surfaces. But if a control surface is not integrated well enough, one quickly will use the mouse again.

As I see you are already quite involved in designing the hardware so it might not make much sense what I am suggesting, but http://ucapps.de/ is a very nice project that has solved many issues with midi control already.

Out of curiosity, are you referring to some sort of an API call, vs. the keyboard shortcut commands that can be mapped as macros? I ask because I do all the things you mentioned (and more) with my Contour Design ShuttlePROv2, unless I'm completely misunderstanding what you're talking about.

Now I am curious. Can you enable record for a track via your shuttlePro? Can you, if a channel in the SSL mixer is selected, "press" the seq and rack button of that channel via your shuttlePro??
What I am referring to is the reason remote protocol. This allows you to control reason via midi control surfaces. For this protocol, there is a list of remotable items and as far as I know from looking at many remote maps and reading other forum posts, record enable for a sequencer track and the seq and rack buttons in the SSL mixer for a channel are not such remotable items.

[gscroggin]

Out of curiosity, are you referring to some sort of an API call, vs. the keyboard shortcut commands that can be mapped as macros? I ask because I do all the things you mentioned (and more) with my Contour Design ShuttlePROv2, unless I'm completely misunderstanding what you're talking about.

Now I am curious. Can you enable record for a track via your shuttlePro? Can you, if a channel in the SSL mixer is selected, "press" the seq and rack button of that channel via your shuttlePro??
What I am referring to is the reason remote protocol. This allows you to control reason via midi control surfaces. For this protocol, there is a list of remotable items and as far as I know from looking at many remote maps and reading other forum posts, record enable for a sequencer track and the seq and rack buttons in the SSL mixer for a channel are not such remotable items.

Gotcha. I don't know if there's a command to arm a specific track(s), but I do have buttons mapped to record and switch views between the rack, sequencer, and mixer (or split-screen combinations of each of them). Everything I've programmed the Shuttle to do came from here: https://a.phcdn.se/Reason10/Manuals/Rea ... mmands.pdf

cinhcet, not sure if you read the whole thread from start to finish (I have), but IIRC way back there was discussion with a member that has dev experience as far as programmability goes with the Reason API. I think there was something about transactions per second as it relates to multiple encoders being used at once, the resolution of the transactions, etc.

Sorry to OP if this is getting off-topic, but I guess it's somewhat related to the project...?

[mcatalao]

To my knowledge record and automation arm are sequencer functionalities only, both bound to that and also (to my knowledge) not remoteable (wich is crap btw). I got to a point where i can use almost NOT use my mouse.

The sequencer and mix buttons on the mixer ARE ALSO NOT REMOTEABLE, and worse, they do not activate context on either one. To me these buttons are worthless, as in reality if you use the mixer as the centerpiece of your DAW, when you select a channel it's track should be selected on either sequencer or the rack. TBH, any selection should guarantee the the selection on any other window, so that the remote surfaces control the needed parameters. A surface that is slaved to the SSL is not a problem, but a context surface, like a BCR2000 as a master device, will lock to a selected device, and that is great because the Remote files will "renew" the surface to control each device. The problem is that this context is not set when you select a channel on the Mixer.

Conclusion (IMHO) what we would need for getting this working, and it's SOLELY on the side of reason:
- Kill the Seq and Rack buttons, and a simple context button like in Redrum (select button on the drum slots) would suffice. Context on either sequencer and rack would be set. Just like clicking on a sequencer track or clicking on the device selection button on the side of the rack.
- All Automation Arm on the sequencer, and ideally remoteable.
- Single Automation arm on the mixer, mandatory remotable.
- All record arm on the sequencer, ideally remotable
- Single Record on the mixer, mandatory remotable.

[Delora Software]

Reason's lack of coherence between Rack/Device selection, Sequencer track selection, and SSL channel selection is a consequence of Reason's flexible routing system. Multiple devices can be routed to a single SSL channel (through sub-mixers), and devices such as effects may not even have sequencer tracks. Once Combi's are included in the picture the situation becomes even more complex.

Reason treats the SSL like a special device of which there is only one but that can have a variable number of channels. Channels can be mapped to sequencer tracks for automation purposes but are not by default. Even the names of sequencer tracks and SSL channels need not be the same.

PH has tried to hide these differences. When you add an audio track, or an instrument, it creates a sequencer track, an SSL channel, gives them a common name, and hooks everything up. The names on the track and SSL channel will even follow the name of the device's selected patch, until you manually modify one of the names. This though implies a relationship and functionality that is not actually there. It is a hidden "macro command" or short cut. A must have convenience that unfortunately can create a false sense that sequencer tracks, devices, and SSL channels are the same element; they are not.

Further adding to confusion is that there are two different mute and solo systems at work. When you mute or solo a sequencer track it only affects the flow of music and automation event information from the sequencer to devices. It has no affect on SSL audio behavior, unless there is active SSL automation information on the sequencer tracks. Likewise muting and soloing an SSL channel does no affect sequencer tracks.

All of this is different from most other DAWs where often there is a one-to-one relationship between mixer channels and sequencer tracks. At the same time those DAWs create different types of confusion with "special" mixer channel types (e.g. "Aux"). When the time comes for some out of the ordinary routing things can become messy, and in some cases impossible to route. So there are trade-offs.

I agree that PH could improve SSL automation by adding per-channel automation mode. Read, Latch, Write, Trim, etc are all very useful automation modes, and commonly found on DAWs like Logic Pro X. These modes should be available for any automation lane, not just those associated with the SSL. And as a Remote control surface developer I would, of course, want these things Remoteable.

The Reason SLL does a pretty decent job of providing the feel and functionality of an actual mixing desk (console), and part of the price we pay for that and Reason's overall routing flexibility are the challenges that have been discussed above.

The lack of Remoteable sequencer record arm is disappointing, but mostly when attempting to set up simultaneous multitrack recording when in "Manual Record" mode. When in "Automatic Record" the currently active sequencer track is armed automatically. So it is possible to record a series of tracks away from the Reason GUI with the proper control surface.

[gscroggin]

Reason's lack of coherence...

I wish Reasontalk had a post "like" feature, because I would select it for every one of yours Doug Every time I read one of your posts I learn something valuable. Oh and your software is awesome too

[diminished]

I wish Reasontalk had a post "like" feature, because I would select it for every one of yours Doug Every time I read one of your posts I learn something valuable. Oh and your software is awesome too

I wholeheartedly agree

[Delora Software]

Thanks guys for those very kind words!

[alexsandor]

Doug - after reading your post, I felt the exact same thing. Thank you for shedding some much needed light on this oft misunderstood topic! Once I find myself an iPad, your rsTouch Pro will be my very first app purchase!

[Cseger1]

This post should be stickied somewhere. I could feel that the sequencer and mixer tracks were behaving differently, but I really didn't get it until reading this post. Reason acts way more like a multi-track deck and a mixer than other DAWs.

Great explanation!

Reason's lack of coherence between Rack/Device selection, Sequencer track selection, and SSL channel selection is a consequence of Reason's flexible routing system. Multiple devices can be routed to a single SSL channel (through sub-mixers), and devices such as effects may not even have sequencer tracks. Once Combi's are included in the picture the situation becomes even more complex.

Reason treats the SSL like a special device of which there is only one but that can have a variable number of channels. Channels can be mapped to sequencer tracks for automation purposes but are not by default. Even the names of sequencer tracks and SSL channels need not be the same.

PH has tried to hide these differences. When you add an audio track, or an instrument, it creates a sequencer track, an SSL channel, gives them a common name, and hooks everything up. The names on the track and SSL channel will even follow the name of the device's selected patch, until you manually modify one of the names. This though implies a relationship and functionality that is not actually there. It is a hidden "macro command" or short cut. A must have convenience that unfortunately can create a false sense that sequencer tracks, devices, and SSL channels are the same element; they are not.

Further adding to confusion is that there are two different mute and solo systems at work. When you mute or solo a sequencer track it only affects the flow of music and automation event information from the sequencer to devices. It has no affect on SSL audio behavior, unless there is active SSL automation information on the sequencer tracks. Likewise muting and soloing an SSL channel does no affect sequencer tracks.

All of this is different from most other DAWs where often there is a one-to-one relationship between mixer channels and sequencer tracks. At the same time those DAWs create different types of confusion with "special" mixer channel types (e.g. "Aux"). When the time comes for some out of the ordinary routing things can become messy, and in some cases impossible to route. So there are trade-offs.

I agree that PH could improve SSL automation by adding per-channel automation mode. Read, Latch, Write, Trim, etc are all very useful automation modes, and commonly found on DAWs like Logic Pro X. These modes should be available for any automation lane, not just those associated with the SSL. And as a Remote control surface developer I would, of course, want these things Remoteable.

The Reason SLL does a pretty decent job of providing the feel and functionality of an actual mixing desk (console), and part of the price we pay for that and Reason's overall routing flexibility are the challenges that have been discussed above.

The lack of Remoteable sequencer record arm is disappointing, but mostly when attempting to set up simultaneous multitrack recording when in "Manual Record" mode. When in "Automatic Record" the currently active sequencer track is armed automatically. So it is possible to record a series of tracks away from the Reason GUI with the proper control surface.

[friday]

Anybody tested the Asparion D400 controller with Reason?

https://www.asparion.de/de/electronics/d400.html

[O1B]

Looks awesome!

Anybody tested the Asparion D400 controller with Reason?

https://www.asparion.de/de/electronics/d400.html

[Slappy]

Hi,

I stumbled across this thread recently and read it with great interest. I realize that I am late to the party here but...What a great idea amcjen! I look forward to future posts about this project. I will definitely be a buyer when the time comes.

Derek (Slappy)