Reason SSL Mixer Hardware Controller
-
- Posts: 211
- Joined: 14 Apr 2017
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]
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]
-
- Posts: 254
- Joined: 13 Jul 2018
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.
-
- Posts: 509
- Joined: 15 Jan 2015
- Location: Night City
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:
-
- Posts: 211
- Joined: 14 Apr 2017
Oh my gosh. I love this project! And the video is a wonderful idea. Gotta get some video chops now.
-
- Posts: 211
- Joined: 14 Apr 2017
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.
This should make quite a few prototypes.
-
- RE Developer
- Posts: 12111
- Joined: 15 Jan 2015
- Location: The NorthWoods, CT, USA
Totally geeking out right now…
[emoji851][emoji851][emoji851]
Sent from some crappy device using Tapatalk
[emoji851][emoji851][emoji851]
Sent from some crappy device using Tapatalk
Selig Audio, LLC
-
- Competition Winner
- Posts: 966
- Joined: 16 Jan 2015
- Location: Italy
I'm IN HEAVEN!!!!!!
Karim Le Mec : Dj/Producer/Label Owner ( 11.3 + R12.x + IMac 2016 21")
FOLLOW Karim Le Mec
https://www.youtube.com/user/lemecdj
https://karimlemec.weebly.com/
https://soundcloud.com/karimlemec
https://t.me/reasonstudiosworld
FOLLOW Karim Le Mec
https://www.youtube.com/user/lemecdj
https://karimlemec.weebly.com/
https://soundcloud.com/karimlemec
https://t.me/reasonstudiosworld
-
- Posts: 151
- Joined: 29 Jan 2019
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?
I wish success for you. Really, is there anywhere a scheme we could also follow if we would like to do a similar project?
-
- Posts: 509
- Joined: 15 Jan 2015
- Location: Night City
Removed by admin I guess...
You do not have the required permissions to view the files attached to this post.
Last edited by wendylou on 19 Mar 2019, edited 1 time in total.
-
- Posts: 2048
- Joined: 20 Mar 2015
- Location: Back of the Rack-1
It is not too much of an ask for people or things to be the best version of itself!
-
- Posts: 13
- Joined: 11 Mar 2019
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.
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.
-
- Posts: 16
- Joined: 19 Oct 2018
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 wrote: ↑11 Mar 2019awesome 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.
-
- Posts: 13
- Joined: 11 Mar 2019
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??gscroggin wrote: ↑11 Mar 2019Out 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 wrote: ↑11 Mar 2019awesome 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.
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.
-
- Posts: 16
- Joined: 19 Oct 2018
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.pdfcinhcet wrote: ↑12 Mar 2019Now 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??gscroggin wrote: ↑11 Mar 2019
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.
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.
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...?
-
- Competition Winner
- Posts: 1907
- Joined: 17 Jan 2015
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.
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.
-
- Posts: 134
- Joined: 18 Jan 2015
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.
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.
Doug
Douglas Kraul
Delora Software
Developer of rsTouch Pro for Reason, and rsRemote for Reason
Douglas Kraul
Delora Software
Developer of rsTouch Pro for Reason, and rsRemote for Reason
-
- Posts: 16
- Joined: 19 Oct 2018
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
-
- Competition Winner
- Posts: 1880
- Joined: 15 Dec 2018
I wholeheartedly agree
Most recent track: resentment (synthwave) || Others: on my YouTube channel •ᴗ•
-
- Posts: 134
- Joined: 18 Jan 2015
Thanks guys for those very kind words!
Doug
Douglas Kraul
Delora Software
Developer of rsTouch Pro for Reason, and rsRemote for Reason
Douglas Kraul
Delora Software
Developer of rsTouch Pro for Reason, and rsRemote for Reason
-
- Posts: 13
- Joined: 28 Nov 2018
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!
-
- Posts: 5
- Joined: 13 Mar 2019
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!
Great explanation!
Delora Software wrote: ↑13 Mar 2019Reason'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.
-
- Posts: 338
- Joined: 17 Jan 2015
Anybody tested the Asparion D400 controller with Reason?
https://www.asparion.de/de/electronics/d400.html
https://www.asparion.de/de/electronics/d400.html
-
- Posts: 2037
- Joined: 26 Jan 2015
Looks awesome!
friday wrote: ↑03 Apr 2019Anybody tested the Asparion D400 controller with Reason?
https://www.asparion.de/de/electronics/d400.html
-
- Posts: 6
- Joined: 18 Sep 2015
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)
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)
-
- Information
-
Who is online
Users browsing this forum: Rising Night Wave, Trendiction [Bot] and 6 guests