Reason SSL Mixer Hardware Controller

[amcjen]

Yep, that’s right. 1.625” is the length/width per unit.

The sizes of each module are close-ish to the actual size within the Reason mixer. In real life, I’ve considered making the aux module shorter, and staggering the 8 aux sends so it takes up less vertical space (which isn’t as accurate as the Reason mixer, but is more accurate to how a real SSL console).

So, def do the SketchUp layouts. Would love a to see!

[jjtguitar]

Yep, that’s right. 1.625” is the length/width per unit.

The sizes of each module are close-ish to the actual size within the Reason mixer. In real life, I’ve considered making the aux module shorter, and staggering the 8 aux sends so it takes up less vertical space (which isn’t as accurate as the Reason mixer, but is more accurate to how a real SSL console).

So, def do the SketchUp layouts. Would love a to see!

I have completed the first draft of the SketchUp layouts. It has all the modules from the Tonic Specifications v0.7 document, apart from the Kurzweil RSP8. If you can tell me the size of the screen on that unit, I will mock something up.

I took the liberty to add a few modules that didnt' exist in the v0.7 doc. I added a portrait Master Compressor, because that's how it usually is on an SSL! Although I haven't been able to make it "fit" into any of my mockups thus far! I also added a Master FX Returns module, and a Transport module. I'm working on a Master fader/control room module, but I haven't finished working out what I would want that to look like, and what size it should be.

Everything is measured accurately. The main buttons are 0.5" square, the transport buttons are .75" square. I can’t remember the details of some of the other buttons and the knobs. But that is the beauty of SketchUp, just open the project and measure stuff! I recreated everything close to the v0.7 document and/or the actual Reason main mixer.

I even found the Propellerheads brand manual and discovered the official Propellerhead font. For those who are curious, page 11 of the brand manual states:

"The chosen font for the Propellerhead brand as well as all Propellerhead products, is Berthold Akzidenz Grotesk – a realist sans-serif typeface originally released by the H. Berthold AG type foundry in 1896. It is seen as the first widely spread sans-serif (typeface without decorative strokes in the letters). It is in our opinion perfect for manifesting the no-nonsense approach of the entire Propellerhead identity."

So there you go! I have used the font for all numbers and words, although you can probably tell I only found the font info towards the end of modelling the Channel modules (which I did first). Up till then I had been using the diagrams from the v0.7 document to mockup the modules, but once I found the font (pretty much from the start of working on the Master modules) I decided to try and recreate much closer to the mixer as seen in Reason.

Here are the Channel Modules


Here are the Master Modules


Here are the External Modules


I mocked up a few different layouts:

16 channel


16 channel centre console


16 channel with full EQ.


The following Google Drive folder has the "Project Tonic Mockups v1" SketchUp file, which anyone can download and play with.
https://drive.google.com/open?id=1_jOtq ... 0z4rmNfgu6

A basic knowledge of how to use SketchUp Make is all that is required to have a play. How to move the camera/view around, how to move objects and how to copy and paste is pretty much all you would need to create your own layouts using the included assets. You can see the different scenes across the top of the window, clicking on these will take you to that scene.

I would reccomend if you want to have a play, copy modules from their respective areas (Channel/Master/External) and then paste them in a new space. That way you always have the original assets in the 'library'. Adding a scene and then right-click/update will set the new scene where the camera currently is.

If I make any updates to the SketchUp file, I will upload them to this folder - so the latest version will always be there. I'll also add my "Project Tonic Unit measurements" Excel file, which has relevant sizing info about each module (width and height in units, width and height in imperial and metric, and the total number of units a module is).

Jonno

[selig]

Yep, that’s right. 1.625” is the length/width per unit.

The sizes of each module are close-ish to the actual size within the Reason mixer. In real life, I’ve considered making the aux module shorter, and staggering the 8 aux sends so it takes up less vertical space (which isn’t as accurate as the Reason mixer, but is more accurate to how a real SSL console).

So, def do the SketchUp layouts. Would love a to see!

On the Sends module, would love to see “pre” buttons in addition to on/off. If possible to find, and taking a cue from the original SSL, using push-button rotary knobs to turn sends on/off would be ideal (and then use a simple LED to indicate on/off status).

An alternative would be to use smaller buttons for On/Off and Pre, to save space.

I think that whenever possible, ALL functions in the software should be represented in the hardware in some form or fashion.


Sent from some crappy device using Tapatalk

[jimmyklane]

Hi there-

I've been kicking around an idea for designing a hardware controller for Reason's SSL mixer or some time now. The reason behind the drive is better outlined in a previous post.

To recap, I really love using Reason and have been using it since the early pre-Record days, and I really love mixing with my hands and ears--not so much with my eyes. To try to match this incongruence, I purchased a Tascam DM3200 several years ago. It has reasonable pre's, and flying faders, and in general was okay, but its own menu-diving and layout wasn't intuitive. I had to keep switching back to logical mode to push the right buttons to pull up compression, or EQ, or whatever. It was great that Reason saw 32 inputs and 32 outputs with it acting as an interface, and I still use it for that (though it appears it's officially discontinued).

What I really wanted was one knob per function for the SSL mixer. The main goal is to never have to open up the Mixer window in Reason again. If I can mix a full album without opening the Mixer window, I will have considered this a success.

For my day job I run a company that designs hardware products for industrial use, and have done my own share of hardware designs (including schematic, PCB board layout, prototype assembly, firmware, and RF (including BLE, WiFi, and LPWAN technologies). So I have the scars earned in releasing hardware into the world! This is no small effort, but it sounds fun, and can be made as small or large as desired, so I've decided to delve in and prototype this idea.

I have the block diagram done, the components chosen, and the ICs identified to manage LEDs, OLEDs, and the flying faders. Also the master section to handle USB Midi input/output, and the power supply. I've also become a Rewire developer with Propellerheads, so have the documentation necessary to begin the first prototypes.

Here is the feature list I plan on building:

Per channel:
- Every knob, button, LED, and display on the SSL mixer would be represented in physical hardware. This includes LED-backed buttons such as Input-invert, or comp-on.
- Every button is actually a button, including LED backlighting when enabled. (TBD whether or not the buttons will be capacitive touch or mechanical)
- Every physical knob controls its counterpart in the SSL mixer. Knobs expected to be potentiometers with stops, rather than rotary encoders (except for the Pan knob).
- Every LED mirrors SSL LEDs, including comp/gate levels and fader level bar graphs
- Channel insert names, and the four insert knob and four input button labels will be small OLED displays, which will show the actual named labels for that channel.
- Every pan knob is a rotary encoder with red/green led ring around it.
- Every fader is an ALPS flying fader.
- Every channel level is an actual 2x32 LED bargraph display
- Below every fader is another OLED that displays channel name/color/output submix information closely representing the existing channel information below the fader of each channel.
- Seq/Rack buttons per channel, to quickly jump to that section on-screen when necessary.

Master section:
- A real, physical, mixbus compressor meter, driven by Rewire
- OLED displays for master FX send labels, master insert labels, insert preset names, and FX return names.
- Shift channels left/right one at a time, or 8 at a time, MackieHUI style.

Maybes:
- Leave a blank area in master section to set a Panorama P1 on and connect it in to act as the transport and instrument/RE controller. (TBD, worth it to make a punched-out blank panel and disassemble a P1 and install it into the control surface?) If not, include basic transport bar, song position, click enable/undo/redo/etc.
- Make each section modular, so that it can be removed/replaced as Props continues to update sections in the mixer, like they did with delay comp recently.

Explicitly not included:
- Reimplementing what Panorama does so well, which is having a general purpose RE/instrument control surface that maps pretty well to existing and future REs. This project is specifically for the SSL mixer, nothing else.

Unknowns:
- As of the writing of this post, Rewire doesn't support channel color as part of the information sent from computer to control surface. Support ticket already opened with Prop's dev team.
- How many simultaneous channels Rewire can support before lag becomes noticeable. With USB 2.0, is it possible to theoretically make a 64 channel control surface with responsive level LEDs, compressor levels, etc if cost were no object?
- Are potentiometers acceptable vs rotary encoders on each knob (hypothesis: yes, because you're using your ears--not your eyes--to mix. Something sounds weird? Twist the offending knob. Sounds better? Great. Sounds worse? Hit the "undo" button. Don't pay as much attention to the line on the knob. In fact, source knobs with no lines on them at all to set the point home.)


Sooo, I've decided to make this SSL Mixer control surface for myself--the number of channels being mainly driven by my available budget (but at the moment, thinking 16 channels and a master section), and floating the idea out there to get feedback from the Reason community. Is this something any of you would be interested in as well? I'm not sure I'd want to make this a purchasable product (though I suppose it's possible if it really resonated with people and the cost/price/market size were appropriate). Might be open to just publishing the schematics/gerbers and BOM parts list, or perhaps as a kit (though there are a ton of SMT parts, and it's not very friendly to kitting, though a steady hand should be able to hand-assemble it if I keep part sizes at 0603 or higher).

- Allison

You’re making the controller side of an SSL AWS924 is what it sounds like. I love the idea, but since you’re going to be a “boutique manufacturer” I’m not sure I’d be willing to pay the price it would take for you to break even after R&D, prototyping, and production. I already own a console however, and use a mostly hardware workflow (including external synths, processing, effects, and mixing) with Reason providing the MIDI sequencing, the “tape” recorder, and sometimes hosting a rack of Instruments (such as Maschine) along with a rack of effects (love that I can make IRs of my gear and use them in RV7000mkII now!)....

Even with all of that said....I’m strongly interested in seeing what you come up with. Offer varying frame sizes in banks of 8....I may be willing to save up for a 16-Channel sidecar-controller just to work with the audio tracks when they come back into Reason and before they go out to the desk.

[selig]

You’re making the controller side of an SSL AWS924 is what it sounds like. I love the idea, but since you’re going to be a “boutique manufacturer” I’m not sure I’d be willing to pay the price it would take for you to break even after R&D, prototyping, and production. I already own a console however, and use a mostly hardware workflow (including external synths, processing, effects, and mixing) with Reason providing the MIDI sequencing, the “tape” recorder, and sometimes hosting a rack of Instruments (such as Maschine) along with a rack of effects (love that I can make IRs of my gear and use them in RV7000mkII now!)....

Even with all of that said....I’m strongly interested in seeing what you come up with. Offer varying frame sizes in banks of 8....I may be willing to save up for a 16-Channel sidecar-controller just to work with the audio tracks when they come back into Reason and before they go out to the desk.

It’s a controller for a K series, not an AWS series, since it’s a controller for Reason. Further, it’s not going to be able to have channel strips for every channel, so it’s not like the AWS, the Duality, or any previous SSL. It’s more like a Sony DMX-100 than anything, with a center section for control of each channel strip.

Curious what price you’re expecting based on what you’ve read here?



Sent from some crappy device using Tapatalk

[jimmyklane]

You’re making the controller side of an SSL AWS924 is what it sounds like. I love the idea, but since you’re going to be a “boutique manufacturer” I’m not sure I’d be willing to pay the price it would take for you to break even after R&D, prototyping, and production. I already own a console however, and use a mostly hardware workflow (including external synths, processing, effects, and mixing) with Reason providing the MIDI sequencing, the “tape” recorder, and sometimes hosting a rack of Instruments (such as Maschine) along with a rack of effects (love that I can make IRs of my gear and use them in RV7000mkII now!)....

Even with all of that said....I’m strongly interested in seeing what you come up with. Offer varying frame sizes in banks of 8....I may be willing to save up for a 16-Channel sidecar-controller just to work with the audio tracks when they come back into Reason and before they go out to the desk.

It’s a controller for a K series, not an AWS series, since it’s a controller for Reason. Further, it’s not going to be able to have channel strips for every channel, so it’s not like the AWS, the Duality, or any previous SSL. It’s more like a Sony DMX-100 than anything, with a center section for control of each channel strip.

Curious what price you’re expecting based on what you’ve read here?

When I said "the controller side of an AWS" I meant a DAW controller laid out like an SSL.... I am aware that Reason is not emulating the newer SSL consoles....I've probably mentioned that I've mixed on them for years (as have you, I think?).

to answer your question:

$1,999 For a full frame of 32 channels? Maybe more.... It's a TON of work, given that Reason doesn't accept NRPN of SysEx it's got to be Remote compatible and despite having all that architecture available I can't see the actual production being cheap...you can't just have 100 units made in China I don't believe. The physical hardware (decent pots, encoders, faders, all of them with associated high-resolution A/D conversion and the proper digital interfacing with Reason) is going to bring significant cost.




Sent from some crappy device using Tapatalk

[amcjen]

So there you go! I have used the font for all numbers and words, although you can probably tell I only found the font info towards the end of modelling the Channel modules (which I did first). Up till then I had been using the diagrams from the v0.7 document to mockup the modules, but once I found the font (pretty much from the start of working on the Master modules) I decided to try and recreate much closer to the mixer as seen in Reason.

Here are the Channel Modules


Here are the Master Modules


Here are the External Modules

Jonno, this is awesome! Thank you for laying all that out, it looks great.

Regarding some of the more recent developments on this project--I am trying to get the modules smaller (and thus more inexpensive), but sometimes that means that the modules may not look exactly like the Reason one. For instance, I think it makes sense to try to make the aux bus module look more like the latest SSL desks (just staggering the knobs instead of making them lined up vertically). I've been going back and forth on whether or not to keep it perfectly authentic to Reason, or make it usable (and affordable!) in the real atoms and molecules world.

And for a quick update, I was hoping to have some Fusion360 mocks of the fader module, but I just got the module PCB laid out. So need to go through a component library run-through, ensure all 3D packages are correct, then will hopefully show the mechanicals.

In the meantime I'll download your Skechup file and do a quicker mockup. So exciting to see this come together!

[amcjen]

On the Sends module, would love to see “pre” buttons in addition to on/off. If possible to find, and taking a cue from the original SSL, using push-button rotary knobs to turn sends on/off would be ideal (and then use a simple LED to indicate on/off status).

That's the plan on many of the rotary encoders. On the Aux module, there will be 8 rotary encoders that are also push-button capable. The idea is to have similar indicators to Reason (e.g. the big square button with the aux bus number on it, and the smaller "pre" one underneath), but they will simply be LED indicators, no buttons.

My current plan is to push the aux knob to enable/disable that aux, and to press and hold for ~3 seconds to enable Pre. The indicators will light based on status.

There is also a push-encoder for the pan/bal knob on the fader module. The plan for this one is to either a) press and hold while turning to adjust width, or b) press once to switch to width and press again to switch back to pan/bal. I fear the press once will be confusing if you accidentally hit it, but we'll learn a lot together during usability tests. (And thank gods these are all software changes at that point!)

I think that whenever possible, ALL functions in the software should be represented in the hardware in some form or fashion.

Totally agree--that's the whole impetus behind this project--no mice or screens when mixing.

[selig]

On the Sends module, would love to see “pre” buttons in addition to on/off. If possible to find, and taking a cue from the original SSL, using push-button rotary knobs to turn sends on/off would be ideal (and then use a simple LED to indicate on/off status).

That's the plan on many of the rotary encoders. On the Aux module, there will be 8 rotary encoders that are also push-button capable. The idea is to have similar indicators to Reason (e.g. the big square button with the aux bus number on it, and the smaller "pre" one underneath), but they will simply be LED indicators, no buttons.

My current plan is to push the aux knob to enable/disable that aux, and to press and hold for ~3 seconds to enable Pre. The indicators will light based on status.

There is also a push-encoder for the pan/bal knob on the fader module. The plan for this one is to either a) press and hold while turning to adjust width, or b) press once to switch to width and press again to switch back to pan/bal. I fear the press once will be confusing if you accidentally hit it, but we'll learn a lot together during usability tests. (And thank gods these are all software changes at that point!)

I think that whenever possible, ALL functions in the software should be represented in the hardware in some form or fashion.

Totally agree--that's the whole impetus behind this project--no mice or screens when mixing.

Allison,

That's an even better approach than what I suggested - carry on, you've got this!

[amcjen]

You’re making the controller side of an SSL AWS924 is what it sounds like. I love the idea, but since you’re going to be a “boutique manufacturer” I’m not sure I’d be willing to pay the price it would take for you to break even after R&D, prototyping, and production. I already own a console however, and use a mostly hardware workflow (including external synths, processing, effects, and mixing) with Reason providing the MIDI sequencing, the “tape” recorder, and sometimes hosting a rack of Instruments (such as Maschine) along with a rack of effects (love that I can make IRs of my gear and use them in RV7000mkII now!)....

Looks like you and Selig cleared it up, but yeah, basically I'm taking inspiration from many SSL products. Duality, AWS, Nucleus, etc. Some are newer than the 9000 and have better knobs/layouts/etc. I purchased a nice grabbag of replacement knobs, jog/shuttle wheels, and buttons from SSL so I could see what feels best (they have a surprisingly large variety of sizes!)

Regarding the price--I hear you. Here's the thing about this project. It's modular, and it's custom. This means that it simply won't have affordability as a requirement--just like the Eurorack modular synth world also doesn't have affordability as a requirement. Going modular means increasing the flexibility significantly, but for each module you then need to repeat a lot of silicon components you could have otherwise just used one of--if that makes sense? In addressing the potential cost issue, it's important to me that people can at least get started with what they can afford. I don't plan on making anything larger than an 6x8 frame, so that's as big as you can make at once. Of course, you can hook these frames together to make it as big is the Tonic protocol will support. But I believe (base on earlier estimates, that a 64 channel (8x 8-frames) should be doable on paper. Of course, the real world may prove otherwise. One way to find out.

Even with all of that said....I’m strongly interested in seeing what you come up with. Offer varying frame sizes in banks of 8....I may be willing to save up for a 16-Channel sidecar-controller just to work with the audio tracks when they come back into Reason and before they go out to the desk.

Definitely! This is the plan--set up the surface exactly how you like to work. If we can't get super affordable, we can at least be custom and fully modular!

$1,999 For a full frame of 32 channels? Maybe more....

This is good to know. That's bringing in each channel at ~$62 each--not counting the center section, frame, power supply, etc. I simply don't know how much it will be yet (because I'm still finalizing components and that has a large impact.)

I'm very intent on using quality products. I have both Bournes and Alps rotary encoders that I'm evaluating at the moment. The Bournes are nice, but they have a tiny bit of wobble, and that bugs me. The Alps are much nicer, but seriously, like 7x more expensive. When there will be 30-40 encoders, we'll have to make some big choices on what's the best for the money.

Same goes for the motorized faders. I tend to be picky, I want it to *feel* quality, I'm currently prototyping with the Alps faders. They're very nice, but come in around $22 each in small ebay quantity. This is a third of the entire channel cost goal of $62.

Not trying to be difficult here, just sharing some color behind the goals of this project. I don't have the money or space to purchase an actual Neve or SSL console, and also I'm of the belief that Reason should be able to output as good of mixes as any other ITB DAW, but its mix control surface is lacking.

It's a TON of work, given that Reason doesn't accept NRPN of SysEx it's got to be Remote compatible and despite having all that architecture available I can't see the actual production being cheap...you can't just have 100 units made in China I don't believe. The physical hardware (decent pots, encoders, faders, all of them with associated high-resolution A/D conversion and the proper digital interfacing with Reason) is going to bring significant cost.

You're fucking telling me it's a lot of work!

I looked back and this project is almost a year old now. While I do have a day job, I spend about 15-20 hours a week on this most weeks (I fly a lot for my work so I work on board layouts and mechanicals while on planes. Even now, I'm somewhere over mid-Texas I think. In fact, when this thing is shipped, I may just silkscreen "Designed in the Sky over the USA"--it's the most accurate.)

I mention this because it's not lost on me that this is not a fun side project that may or may not get done. I absolutely intend to finish it--it just takes a significant amount of work to get the system designed and built. The good news is that I'm very confident in the most important part--the digital comms to share that amount on control information in real-time (order of microseconds). And most of those components are very inexpensive (because almost every automobile uses the same base protocol for airbags, engine ECU, infotainment, etc.) So I can leverage economies of scale here.

And regarding making on the order of hundreds of a thing--I have a friend that I've worked with on prior projects that has my Asian manufacturing connections to scale with this project.

I will make every effort to offer this surface in the following priority: 1) flexibility of configuration, 2) quality components, and 3) affordability. B/c that's how I want this to exist. BUT, since it's a modular, open system--I bet others could come out with more affordable modules.

I appreciate your feedback!
-Allison

[jimmyklane]

You’re making the controller side of an SSL AWS924 is what it sounds like. I love the idea, but since you’re going to be a “boutique manufacturer” I’m not sure I’d be willing to pay the price it would take for you to break even after R&D, prototyping, and production. I already own a console however, and use a mostly hardware workflow (including external synths, processing, effects, and mixing) with Reason providing the MIDI sequencing, the “tape” recorder, and sometimes hosting a rack of Instruments (such as Maschine) along with a rack of effects (love that I can make IRs of my gear and use them in RV7000mkII now!)....

Looks like you and Selig cleared it up, but yeah, basically I'm taking inspiration from many SSL products. Duality, AWS, Nucleus, etc. Some are newer than the 9000 and have better knobs/layouts/etc. I purchased a nice grabbag of replacement knobs, jog/shuttle wheels, and buttons from SSL so I could see what feels best (they have a surprisingly large variety of sizes!)

Regarding the price--I hear you. Here's the thing about this project. It's modular, and it's custom. This means that it simply won't have affordability as a requirement--just like the Eurorack modular synth world also doesn't have affordability as a requirement. Going modular means increasing the flexibility significantly, but for each module you then need to repeat a lot of silicon components you could have otherwise just used one of--if that makes sense? In addressing the potential cost issue, it's important to me that people can at least get started with what they can afford. I don't plan on making anything larger than an 6x8 frame, so that's as big as you can make at once. Of course, you can hook these frames together to make it as big is the Tonic protocol will support. But I believe (base on earlier estimates, that a 64 channel (8x 8-frames) should be doable on paper. Of course, the real world may prove otherwise. One way to find out.

Even with all of that said....I’m strongly interested in seeing what you come up with. Offer varying frame sizes in banks of 8....I may be willing to save up for a 16-Channel sidecar-controller just to work with the audio tracks when they come back into Reason and before they go out to the desk.

Definitely! This is the plan--set up the surface exactly how you like to work. If we can't get super affordable, we can at least be custom and fully modular!

$1,999 For a full frame of 32 channels? Maybe more....

This is good to know. That's bringing in each channel at ~$62 each--not counting the center section, frame, power supply, etc. I simply don't know how much it will be yet (because I'm still finalizing components and that has a large impact.)

I'm very intent on using quality products. I have both Bournes and Alps rotary encoders that I'm evaluating at the moment. The Bournes are nice, but they have a tiny bit of wobble, and that bugs me. The Alps are much nicer, but seriously, like 7x more expensive. When there will be 30-40 encoders, we'll have to make some big choices on what's the best for the money.

Same goes for the motorized faders. I tend to be picky, I want it to *feel* quality, I'm currently prototyping with the Alps faders. They're very nice, but come in around $22 each in small ebay quantity. This is a third of the entire channel cost goal of $62.

Not trying to be difficult here, just sharing some color behind the goals of this project. I don't have the money or space to purchase an actual Neve or SSL console, and also I'm of the belief that Reason should be able to output as good of mixes as any other ITB DAW, but its mix control surface is lacking.

It's a TON of work, given that Reason doesn't accept NRPN of SysEx it's got to be Remote compatible and despite having all that architecture available I can't see the actual production being cheap...you can't just have 100 units made in China I don't believe. The physical hardware (decent pots, encoders, faders, all of them with associated high-resolution A/D conversion and the proper digital interfacing with Reason) is going to bring significant cost.

You're fucking telling me it's a lot of work!

I looked back and this project is almost a year old now. While I do have a day job, I spend about 15-20 hours a week on this most weeks (I fly a lot for my work so I work on board layouts and mechanicals while on planes. Even now, I'm somewhere over mid-Texas I think. In fact, when this thing is shipped, I may just silkscreen "Designed in the Sky over the USA"--it's the most accurate.)

I mention this because it's not lost on me that this is not a fun side project that may or may not get done. I absolutely intend to finish it--it just takes a significant amount of work to get the system designed and built. The good news is that I'm very confident in the most important part--the digital comms to share that amount on control information in real-time (order of microseconds). And most of those components are very inexpensive (because almost every automobile uses the same base protocol for airbags, engine ECU, infotainment, etc.) So I can leverage economies of scale here.

And regarding making on the order of hundreds of a thing--I have a friend that I've worked with on prior projects that has my Asian manufacturing connections to scale with this project.

I will make every effort to offer this surface in the following priority: 1) flexibility of configuration, 2) quality components, and 3) affordability. B/c that's how I want this to exist. BUT, since it's a modular, open system--I bet others could come out with more affordable modules.

I appreciate your feedback!
-Allison

Interesting.

I’d be happy to offer input. Here are my initial thoughts:

You’ll incur some latency in the A/D of each fader/knob/encoder, as well as in the multiplexer and supporting hardware, but only 400 microseconds or so, in addition, if you can use an off-the-shelf FPGA to route all that digital information to the control software via the center section, the good news is that the center section and the first (say) 8 channel strips would become the start of a system. there is no getting around the need for that all-important center section, since it’s the core of any SSL. If you want a moving coil meter, you’ll find that a really solid one can be pricey, and of course you’ll need a D/A, buffer, and current driver that is driven by the feedback you get from Reason. In real-time. How to compensate for system latency? Does Reason write to the audio buffer and run a separate thread for Remote, and a separate thread for graphic feedback? If so, which do you harness to grab that GR from the buss-compressor? I am now highly interested....considering that I’ve made and repaired a lot of analog hardware, but have very limited knowledge of how to code something like this project I’d love to keep up on this. Awesome idea, and I hope it sees the light. I’d probably be willing to dump my console (which is really a glorified digital patchbay at this point in my career) if I could have something to replace it.

Here’s a query: how the hell am I going to get a new Argosy desk for a custom project like this?!!? I’m so used to the one I’ve got now I’d have to get another to slot this into!

[amcjen]

You’ll incur some latency in the A/D of each fader/knob/encoder, as well as in the multiplexer and supporting hardware, but only 400 microseconds or so, in addition, if you can use an off-the-shelf FPGA to route all that digital information to the control software via the center section, the good news is that the center section and the first (say) 8 channel strips would become the start of a system. there is no getting around the need for that all-important center section, since it’s the core of any SSL.

Ooh, getting into the guts now... I like it!

So yes, there is always latency when doing ADC conversions--but each module has its own "brain" (at least that's what I call it b/c "controller board" is too long-winded). Anyhow, this brain is based off of an arm Cortex M0+ running at 48MHz. Doesn't sound fast I know, but the ADC of the particular chip I've chosen can sample at a rate of 350,000 readings per second. Now if I'm doing my math right that's a sample every 1 / 350,000 seconds, or 2.8 microseconds, and since this chip supports DMA and hardware averaging, we can get these readings pretty damned fast (still under 3ms while averaging 1,024 readings for hardware averaging).

Regarding an FPGA--while very powerful indeed, I don't believe at this time we'll need to use one. The reason being is that we're offloading the heavy communications requirements to the CANBus transceivers directly. CAN supports up to 1Mb/sec transfer rate, and it does so with a full broadcast--meaning every single module in your Tonic setup will get every single message sent to it via Remote. This may seem like overkill, but it eliminates latency b/c every module receives the messages at once. Good CANBus transceivers (including the one I've chosen) will let you set hardware filters for the bus, so it ignores any messages it sees that aren't addressed for it. Once it does get one that is addressed appropriately, it will interrupt the Cortex, which can then set LEDs, change fader position, etc.

Likewise, if a module triggers an interrupt due to a person twisting a rotary encoder or fader--they're all hardware-interrupt based, so it will get a higher priority interrupt and will form a CANBus message to be sent onto the bus, destined to the Remote host in the form of a MIDI message (encapsulated of course). If there were an identical request to send a control change message from a module and to light an LED on a module, the control change message gets priority. But in real world usage, I don't think any human could notice this priority edge case even if it happened.

The center section is technically optional--there's no reason why you couldn't run a simple bank of 8 fader modules that are tied Mackie HUI-style to the first bank of 8 faders in Reason. Now, just because you *can* doesn't really mean you *should*--I wouldn't want to mix without a center section myself!

If you want a moving coil meter, you’ll find that a really solid one can be pricey, and of course you’ll need a D/A, buffer, and current driver that is driven by the feedback you get from Reason.

Yep, the ole' master comp meter. Indeed this would drive up the price--but I mean--would you want an SSL-esque control surface without a bouncing meter? I would not. Luckily there is a rich SSL comp clone ecosystem out there that we can leverage. Someone already made a VU driver board for one.

I agree with you that in extremely heavy mixes where Remote is sending out megabits/sec of messages, there could be a real possibility of latency on the master comp meter--but I don't believe it will be any worse latency than what you get with Reason's graphics when it gets super overloaded. You can still hear, but the UI gets sluggish. I unf. can't do anything about that (until Props gets in gear and starts seriously evaluating something like Apple's MetalKit to revamp their UI libs to offload to all this GPU power we all have in our computers but aren't using at all).

In real-time. How to compensate for system latency? Does Reason write to the audio buffer and run a separate thread for Remote, and a separate thread for graphic feedback? If so, which do you harness to grab that GR from the buss-compressor?

Without breaking any developer license agreements I made with Propellerheads to get the Remote Dev documentation, I think it's safe to say that the Remote processor (in the form of a Lua interpreter) runs separately and will only send deltas of any changed Reason state, including the master bus compressor changes.

I am now highly interested....considering that I’ve made and repaired a lot of analog hardware, but have very limited knowledge of how to code something like this project I’d love to keep up on this. Awesome idea, and I hope it sees the light. I’d probably be willing to dump my console (which is really a glorified digital patchbay at this point in my career) if I could have something to replace it.

So this is how I know you're onto this crazy idea--you're willing to dump your console! I just sold my digital desk, which was also just acting like a fancy patchbay. I need to make room for this new surface.

Here’s a query: how the hell am I going to get a new Argosy desk for a custom project like this?!!? I’m so used to the one I’ve got now I’d have to get another to slot this into!

I'll leave it up to the wonderful members on this forum to put together some desk plans that fit the Tonic modules perfectly! I'll stick to the electronics--but I certainly would love to see something like that desk Selig mentioned a while ago (I forget its name, but it's awesome) modded/customized for a Tonic surface.

Allison

[amcjen]

Ooh, and this will make Selig happy. I found a tiny 0603 bi-color LED to use for all the encoder LED rings.

https://datasheet.octopart.com/HSMF-C16 ... 619282.pdf

It's tricky because we need bi-color (think the green vs. red LED indicators around the pan knob, for instance), and I needed them smallllllllll, because there are 24 LEDs around the pan knob. And we don't have a lot of space. But this one--if it has the brighness and diffusion I'm hoping for, just may be the ticket.

I'm considering spinning out a quick PCB with just the rotary encoder with LEDs to get an idea of interfacing and layout (and to solve what appears to be becoming the biggest issue of all--Bourns or Alps rotary encoders?)

(and to get an idea of how small an 0603 [imperial] is, here's a good reference: https://www.electronicproducts.com/uplo ... 0201_2.jpg)

[wendylou]

Be sure to make a time-lapse movie of the assembly, something like Wintergatan's Marble Machine!

[amcjen]

A quick update--I had to step back a bit and rethink how I was going about the fader module. Long story short, I broke it out into several sub-boards and now it all fits so nice and pretty--I'm super happy with how it turned out. This also means I can test sub-boards individually which will mean faster (and easier) testing and updates! I so want to show pictures, but I'm still in board layout land. Soon soon. I also redesigned the Brain module to a tiny 1" x 1" square. This makes it fit much better on even the smallest Tonic module (1x1, which is 1.625" x 1.625")--I'm really pleased with the progress-though there isn't much to see yet.

Also, I recently evaluated a new higher resolution 1.5" LCD display that will be at the top of each fader module (basically the colored-background-with-track-name), and this display looks REALLY NICE. Like, Maschine Pro nice. I'm super happy with it and am completely sold on it. Bad news is the driver I'm using for it only supports 64k colors, and when I started coding up the Reason track colors into it, I found they didn't look very close--as it was interpolating the actual color into the closest 64k slot. Booo.

I'll need to modify the driver to support 18 bit color so we can get 260k colors--hopefully that will be closer. If not, I'll do my best to get them close to our favorites, like Kelly Green, Slate Blue, and Asparagus.

After this--I'll send the sub-boards off to get PCBs made, buy some parts, and start soldering up to test.

Oh, and I settled on the ALPS rotary encoder--it's so much nicer--feels super quality, and I found a cheaper supplier for them. Made the choice easy!

(and Wendylou, I certainly will make more videos once I have some things to show!)

- Allison

[geremix]

[emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316][emoji1316]


G E R E M I X
Music producer from Uruguay [emoji1257]
Using Reason since v1
www.byGeremix.com

[dioxide]

I am still very excited about this project

[normen]

As you seem to be all over the Reason Remote part of it already - if you have a basic implementation just start a github project and I'll have a look how I can help. I didn't get much feedback in the thread where I invited to brainstorm about how to handle this on the Remote side in general..

[amcjen]

As you seem to be all over the Reason Remote part of it already - if you have a basic implementation just start a github project and I'll have a look how I can help. I didn't get much feedback in the thread where I invited to brainstorm about how to handle this on the Remote side in general..

Yep, absolutely. Thinking about the simplest thing that would let people hack on the Remote portion of it--a blinking LED maybe? I'll kick it around and put together a shopping list for those who want to work along at home.

Also, did I miss a thread you posted regarding this project? Hoping not, but it's very possible.

[amcjen]

I am still very excited about this project

[normen]

Also, did I miss a thread you posted regarding this project? Hoping not, but it's very possible.

It wasn't specifically about this project but I tied it in later: viewtopic.php?f=4&t=7506161

[electrofux]

Ther will be high res encoders with led rings all over the place?

[amcjen]

Ther will be high res encoders with led rings all over the place?

Every rotary control will be an endless rotary encoder with 24 bi-color LEDs in a ring.

Most will also be a push button switch—for instance, to turn on/off an aux send.

[fieldframe]

Also, I recently evaluated a new higher resolution 1.5" LCD display that will be at the top of each fader module (basically the colored-background-with-track-name), and this display looks REALLY NICE. Like, Maschine Pro nice. I'm super happy with it and am completely sold on it. Bad news is the driver I'm using for it only supports 64k colors, and when I started coding up the Reason track colors into it, I found they didn't look very close--as it was interpolating the actual color into the closest 64k slot. Booo.

I'll need to modify the driver to support 18 bit color so we can get 260k colors--hopefully that will be closer. If not, I'll do my best to get them close to our favorites, like Kelly Green, Slate Blue, and Asparagus.

Remote supports track color now? If so, that's great!

What is the stack like for getting text to these? Are you rendering on the host and sending raster over the bus, or are you running an embedded renderer to drive each screen?

Most importantly, do you have full control over fonts and can you do anti-aliasing?

[electrofux]

Ther will be high res encoders with led rings all over the place?

Every rotary control will be an endless rotary encoder with 24 bi-color LEDs in a ring.

Most will also be a push button switch—for instance, to turn on/off an aux send.

Do you have readily installable rings. Last time i looked for them i could only find some expensive ones.

And yeah, what is the remote item for the track color?