Reason SSL Mixer Hardware Controller

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
Post Reply
User avatar
selig
RE Developer
Posts: 11681
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

04 Nov 2017

amcjen wrote:
04 Nov 2017
Ok, here's a link to a preliminary product spec that's starting to come together. Certainly not complete yet, but it's starting to become a really solid foundation! I'm continuing to get increasingly excited about how this system could work.

https://www.dropbox.com/sh/t7o7w2a7ny5v ... B2P-a?dl=0

- Allison
Quick questions/thoughts:
The chassis is limited to 7" tall - why such a small vertical limit? Can we go taller?
Why not square "units"? Either go with the standard rack width of 1U=1.75, (1.75"x1.75"), or 1.5"x1.5"?

Thinking out loud…the first "problem" with such a small vertical height is that you cannot fit an EQ module into that space if you use the existing proportions of the Reason Mixer: it ends up begin over 8" tall at 1.5" wide, and 10" tall at 1.75" wide. This gives you knobs that are around 0.375" (9.525mm) and 0.5" (12.7mm) respectively. As there are fewer choices for 9.5mm knobs than 12-13mm, I suggest the standard 1U width for each "unit" - or am I missing some conclusion you've already arrived at?

Something like this, which is 14mm, would match the original SSL knobs nicely (provided we can source the matching end cap colors):
Image

Then there's the size of the encoder LED rings, if wanted, which are at least 23mm in diameter (0.9"), which quickly eat up panel space…
Image

BTW, did you see these - possible to make a 16 pad controller module!
Image
(just under 7"x7")
Selig Audio, LLC

User avatar
Psuper
Posts: 524
Joined: 29 May 2016

04 Nov 2017

Wanna know my secret weapon?

Image
Reason needs to DAW.viewtopic.php?f=6&t=7504985

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

04 Nov 2017

selig wrote:
Quick questions/thoughts:
The chassis is limited to 7" tall - why such a small vertical limit? Can we go taller?
Oh totally. We definitely can. I originally planned on a 12 x 8 chassis, which comes in at 21” tall. That seemed kinda big (and requires a 100W power supply to handle the 125mA-per-unit requirement.

But as I was talking through it with some others over a beer, it became clear that it’s just too big for people who just may want to start out with one chassis. So I divided by three to get four.

Also, I was trying to avoid having to make two different chassis heights instead of one (more tooling, more setup, more sku-proliferarion, etc). But I think you’re right. When I measured out EQs (including filters), sends, and inserts, they came in at 6, 5, and 5 units high each, respectively. So 4 high won’t work unless you compress them down.

Let me redo this to make it six instead of four. We’ll need a ~ 7.5A power supply instead of 5.0, but that’s not a big deal.

Three chassis vertically arranged is almost exactly the height of my currently used digital mixer, which is about as deep as I’d feel good using—around 31” deep.
“selig” wrote: Why not square "units"? Either go with the standard rack width of 1U=1.75, (1.75"x1.75"), or 1.5"x1.5"?
I kicked this exact question around a *lot*, because my mind really wanted it symmetrical. However, I was balancing the width of the chassis to give enough room for a typical channelstrip against staying slim enough to be a bit more compact if running a huge setup (say, a 64 channel system with 8 fader chassis and a centerchannel, which would be 9 chassis wide). It’s a two inch per chassis difference between 1.5” wide and 1.75” wide.

Since the API 500 series form factor is originally from the individual channel strips of API consoles, and they are 1.5” wide, it seemed like the smallest usable width for a channel strip—and so many people are familiar with that width with their API lunchboxes—that it seems like a safe bet to make it that width.

And the 1.75” height came from, of course, the height of a typical rack unit. And 500 series modules are 3 units high, or 5.25” tall—also a size that many people are familiar with. Also, places like Front Panel Express have standardized on this size (though I suppose they can make any size if you ask them to).

There are likely three paths forward: keep it the same, make it 1.75” by 1.75”, or make it 1.5” by 1.5”. There are certainly pros and cons to each of them—but regardless I’d say that we have to support the height of an EQ (6 units tall) or this isn’t going to work for its original goal. So I’ll expand it to 6 high.

What are your thoughts around why the width and height should be the same? Any compelling reasons that I’m missing, outside of the general strangeness of it being asymmetrical?

Allison

PS it would indeed be amazing to have a 16 pad controller built right into your centerchannel! That’s why this is going to be fucking awesome if we get it right. People will build their own custom controllers to match exactly how they work!

djslaughter808
Posts: 3
Joined: 04 Nov 2017

04 Nov 2017

I want to work for you!!! based on your post it seems like you and I have the same thinking when it comes to hardware for reason. I've also been saying for the longest there needs to be a controller specifically for reason's SSL virtual mixer. If you can make that I would go in debt to get that for my reason setup. I also have other ideas for reason that maybe we should talk about later on

djslaughter808
Posts: 3
Joined: 04 Nov 2017

04 Nov 2017

Also I would like to see 3D renders of this Hardware mixer

djslaughter808
Posts: 3
Joined: 04 Nov 2017

04 Nov 2017

also I highly recommend you do a GoFundMe for this

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

06 Nov 2017

Thank you for the replies! Renders and eventual crowdfunding will happen in due time. Still have some important design and prototyping work to do first.

As far as ideas go, this is the place for it! The goal is to do all the boring work upfront (physical dimensions, power supplies, communication protocols, etc) so that once it’s designed, prototyped, and tested, *then* a whole bunch of fun things can be designed for the system.

And the best part is, it should work with pretty much any Midi device, as well as Reason. For instance, I’m super excited to design a remote for my external FX unit Bc it’s super rare now and they go for silly money on eBay—I️ can design and make one for less, and have it sit right in my center channel chassis next to the Reason channelstrip. So integrated.

This is going to be fun. :)

User avatar
selig
RE Developer
Posts: 11681
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

06 Nov 2017

amcjen wrote:
04 Nov 2017
selig wrote:
Quick questions/thoughts:
The chassis is limited to 7" tall - why such a small vertical limit? Can we go taller?
Oh totally. We definitely can. I originally planned on a 12 x 8 chassis, which comes in at 21” tall. That seemed kinda big (and requires a 100W power supply to handle the 125mA-per-unit requirement.

But as I was talking through it with some others over a beer, it became clear that it’s just too big for people who just may want to start out with one chassis. So I divided by three to get four.

Also, I was trying to avoid having to make two different chassis heights instead of one (more tooling, more setup, more sku-proliferarion, etc). But I think you’re right. When I measured out EQs (including filters), sends, and inserts, they came in at 6, 5, and 5 units high each, respectively. So 4 high won’t work unless you compress them down.

Let me redo this to make it six instead of four. We’ll need a ~ 7.5A power supply instead of 5.0, but that’s not a big deal.

Three chassis vertically arranged is almost exactly the height of my currently used digital mixer, which is about as deep as I’d feel good using—around 31” deep.
“selig” wrote: Why not square "units"? Either go with the standard rack width of 1U=1.75, (1.75"x1.75"), or 1.5"x1.5"?
I kicked this exact question around a *lot*, because my mind really wanted it symmetrical. However, I was balancing the width of the chassis to give enough room for a typical channelstrip against staying slim enough to be a bit more compact if running a huge setup (say, a 64 channel system with 8 fader chassis and a centerchannel, which would be 9 chassis wide). It’s a two inch per chassis difference between 1.5” wide and 1.75” wide.

Since the API 500 series form factor is originally from the individual channel strips of API consoles, and they are 1.5” wide, it seemed like the smallest usable width for a channel strip—and so many people are familiar with that width with their API lunchboxes—that it seems like a safe bet to make it that width.

And the 1.75” height came from, of course, the height of a typical rack unit. And 500 series modules are 3 units high, or 5.25” tall—also a size that many people are familiar with. Also, places like Front Panel Express have standardized on this size (though I suppose they can make any size if you ask them to).

There are likely three paths forward: keep it the same, make it 1.75” by 1.75”, or make it 1.5” by 1.5”. There are certainly pros and cons to each of them—but regardless I’d say that we have to support the height of an EQ (6 units tall) or this isn’t going to work for its original goal. So I’ll expand it to 6 high.

What are your thoughts around why the width and height should be the same? Any compelling reasons that I’m missing, outside of the general strangeness of it being asymmetrical?

Allison

PS it would indeed be amazing to have a 16 pad controller built right into your centerchannel! That’s why this is going to be fucking awesome if we get it right. People will build their own custom controllers to match exactly how they work!
Also maybe a numeric key pad would be handy if it can be incorporated into the Remote code - would be nice to be able to enter bar numbers for location etc. (if possible).

OK, two things at work here:
1-Chassis size, which need to be able to handle the biggest module (EQ), and small enough to handle the total power requirements for your power supply.
2-module size, which needs to be able to fit into the chassis but also needs to accommodate your largest imagined control - in this case I would think it would be an LED ring (which I previously mentioned).

I look at knob size, button size, and LED ring size to determine the final size, as well as other console standards. I would not worry about a 64 channel console being too big - anyone wanting a 64 channel console will very likely have the space for such a behemoth! What's more important is ergonomics and the SSL form factor, which is 1.625 inches wide, with 13" wide buckets of 8 modules. So this throws a curve since that dimension is between the ones we've considered to date! I think it will be up to the parts we are able to source, especially encoders and especially LED rings, which need to be small enough to fit (obviously!) and may be the deciding factor in the end!

Also, we need to factor in the faders, which probably need their own form factor. Assuming a 100mm (4") fader, plus Mute/Solo and Pan knobs, you'll need at least 6" if not 7", which is what you originally designed! SO maybe keep that size for faders? Not to mention a master section, which may be something that could fit in the fader section or in the main section.

I'd love to have each bank have an increasing angle, with the faders flat, the first bank around 15°, the second 30° etc. Is a LCD or OLED display going to be possible (vertically mounted at the top of the controller, like the SSL Duality or similar), or is that a pipe dream on my part?
:)
Selig Audio, LLC

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

07 Nov 2017

selig wrote:
06 Nov 2017
Also maybe a numeric key pad would be handy if it can be incorporated into the Remote code - would be nice to be able to enter bar numbers for location etc. (if possible).
My plan was to have the USB device (the control surface) be composite--meaning it can look like multiple USB device types to the computer it's connected to, even though it's a single USB cable. In this situation I'd make it a USB-MIDI device and a USB-HID (human interface device). HIDs look like keyboard or mice to the computer host. This should allow us to mix and match control surface elements (numeric keypad, single buttons for "save", etc)--especially when some will be sending MIDI or Remote messages, and others may simply be sending keyboard key commands.
selig wrote:
06 Nov 2017
OK, two things at work here:
1-Chassis size, which need to be able to handle the biggest module (EQ), and small enough to handle the total power requirements for your power supply.
2-module size, which needs to be able to fit into the chassis but also needs to accommodate your largest imagined control - in this case I would think it would be an LED ring (which I previously mentioned).

I look at knob size, button size, and LED ring size to determine the final size, as well as other console standards. I would not worry about a 64 channel console being too big - anyone wanting a 64 channel console will very likely have the space for such a behemoth! What's more important is ergonomics and the SSL form factor, which is 1.625 inches wide, with 13" wide buckets of 8 modules. So this throws a curve since that dimension is between the ones we've considered to date! I think it will be up to the parts we are able to source, especially encoders and especially LED rings, which need to be small enough to fit (obviously!) and may be the deciding factor in the end!
Totally agree. I mean, if we're going to move away from 500 series widths (which I'm totally okay with), then might as well adopt the SSL width. 13" wide for a bucket of 8 feels a lot better than 14" to me. I have not evaluated LED ring layouts yet, but they should fit alright. Some I found when I did just a bit of searching are coming in at 1" wide max. At this size, you could likely stagger the controls like the dynamics section of the Reason mixer, with LED rings, within 1.625" I'd think.
selig wrote:
06 Nov 2017
Also, we need to factor in the faders, which probably need their own form factor. Assuming a 100mm (4") fader, plus Mute/Solo and Pan knobs, you'll need at least 6" if not 7", which is what you originally designed! SO maybe keep that size for faders? Not to mention a master section, which may be something that could fit in the fader section or in the main section.
Right! I mean, if we need to have two sizes of chassis (a 4u high and a 6u high), we can do it--it's just a much bigger hassle from a manufacturing, inventory, and logistics standpoint. I'd almost rather just settle on 6u and have a nice wrist-rest for the remaining units on the fader chassis.

Also, I was creepin' on the ALPS fader datasheets, and they require 10V for their motors. That kinda sucks, b/c it changes up the power supply issues even more. However, I think it's better to spec a higher voltage power supply and just use LDO regulators on the modules to get 3.3V or whatever--that will then allow for higher voltage requirement items to be supported within the system. You know, like OLEDs and LCDs... :) (See below!)
selig wrote:
06 Nov 2017
I'd love to have each bank have an increasing angle, with the faders flat, the first bank around 15°, the second 30° etc. Is a LCD or OLED display going to be possible (vertically mounted at the top of the controller, like the SSL Duality or similar), or is that a pipe dream on my part?
:)
Yes! I am about to go to bed so too tired to whip up a drawing, but I was thinking we'll just create a few different angles of brackets to attach one chassis to another. I'm ripping this idea directly off of this wonderful example of an expandable, modular setup (except instead of one large bracket, you'd have separate brackets that only join two chassis together). I was thinking 0°, 12°, and, say 78°, so you could get flat faders, an angled EQ/dynamics, and a vertical meter bridge or whatever. Add more 0° brackets between two chassis if you want to extend any section at the same angle.

And yes, if we stick with 6u tall chassis, you can have 10" LCDs across the entire top of your controller. What those screens show (and who's making them), is totally up to the community--but that would certainly be possible with this setup as far as I can tell--especially since we're bumping up the power supply requirements to 12V from 5V. Most of those screens require 9-12V AFAIK.

Another nice thing about the 12V bump is that there are a lot of power supplies out there that provide 12V @ ~7A (some really cheap, some nicer), because it's a common size for laptops and for LED strings. So sourcing them shouldn't be a problem.

Refining refining!
-Allison

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

07 Nov 2017

Damn you Giles! I started measuring IRL with a ruler, and for a lot of meter bridge style uses (the vertical chassis at the top), you'd likely want not only a 4u tall chassis for LCD displays, but probably a 2u tall chassis as well for simpler bar graph meter bridges. Only having a 6u chassis for the vertical section would be huge and unnecessary for lots of setups I'd imagine.

Maybe 2u, 4u, and 6u size chassis are all needed, to make every system fully modular and customizable.

User avatar
Catblack
Posts: 1020
Joined: 15 Apr 2016
Contact:

07 Nov 2017

I love this project. It's all a bit over my head at the moment, but I stand by my comments upthread about getting the Remote side of things working well. I should have some sort of proof of concept by early next year based on having some sort of sysex info returned by Tonic that lets Remote know what is hooked up. (And again the big gotcha generally is that you can't have an Item defined in the .remotemap that isn't defined in the lua codec, which means that having a 'master' .remotemap for the Tonic project is perhaps up in the air.)

I still have plans next year to work on a remote/WebMidi bridge that will allow me to display a screen using an old raspberry pi. Probably with Chrome and using javascript and css, which makes it easy to configure the layout on screen. Similar in function on the back end to Novation's Automap software, in that it will pass the name of the remotable back over to the display. The goal being that the user would use the css to arrange the items they need on the display reflecting their layout. I'll probably put a call out in January for help on this though. (My wife and I should be having a baby tomorrow.)

The short of it is that I think small displays will be totally possible using a very similar Remote codec to what I envision for Tonic. Perhaps even touch screens.
If you ain't hip to the rare Housequake, shut up already.

Damn.

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

07 Nov 2017

New spec is up with changes discussed over the last few days: https://www.dropbox.com/s/c2vsqp7l5kkh0 ... 7.pdf?dl=0


Sent from my iPad using Tapatalk

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

07 Nov 2017

Catblack wrote:I love this project. It's all a bit over my head at the moment, but I stand by my comments upthread about getting the Remote side of things working well. I should have some sort of proof of concept by early next year based on having some sort of sysex info returned by Tonic that lets Remote know what is hooked up. (And again the big gotcha generally is that you can't have an Item defined in the .remotemap that isn't defined in the lua codec, which means that having a 'master' .remotemap for the Tonic project is perhaps up in the air.)
Awesome! Yes, getting the Remote side of this working well will require some thought. It’s unfortunate about the item requiring both .remotemap and lua codec definition, though I suppose it makes sense.
I still have plans next year to work on a remote/WebMidi bridge that will allow me to display a screen using an old raspberry pi. Probably with Chrome and using javascript and css, which makes it easy to configure the layout on screen. Similar in function on the back end to Novation's Automap software, in that it will pass the name of the remotable back over to the display. The goal being that the user would use the css to arrange the items they need on the display reflecting their layout. I'll probably put a call out in January for help on this though. (My wife and I should be having a baby tomorrow.)
I still really like this idea. Having the concept of virtual and physical, closely mapped like this (either a combination of Automap-like and Remote, or something altogether differnet) will make this super powerful. Where most things go south is that there really isn’t a clear bidirectional relationship between a screen interface of a device, and a physical interface. Remote gets close, but doesn’t have the auto-discover you describe.

Two enthusiastic thumbs up in getting this going early next year.

Aaaaand.... CONGRATULATIONS on the new baby! That is just wonderful, so happy for you and your wife!.
The short of it is that I think small displays will be totally possible using a very similar Remote codec to what I envision for Tonic. Perhaps even touch screens.
Don’t tell Giles! He’ll get really excited. ;)

-Allison


Sent from my iPad using Tapatalk

User avatar
selig
RE Developer
Posts: 11681
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

07 Nov 2017

amcjen wrote:
07 Nov 2017
Damn you Giles! I started measuring IRL with a ruler, and for a lot of meter bridge style uses (the vertical chassis at the top), you'd likely want not only a 4u tall chassis for LCD displays, but probably a 2u tall chassis as well for simpler bar graph meter bridges. Only having a 6u chassis for the vertical section would be huge and unnecessary for lots of setups I'd imagine.

Maybe 2u, 4u, and 6u size chassis are all needed, to make every system fully modular and customizable.
Random replies…
Remember the EQ section is 8-9" tall, depending on the width we adopt, so the biggest chassis needs to accommodate that module.
I found LED rings that were 0.9", FWIW.
I was actually going to link to the Moog Mother32 stack you showed - exactly what I was thinking! Also, many vintage consoles had similar design, as well as many of the controllers I saw at AES this year (and posted earlier).
Selig Audio, LLC

User avatar
fieldframe
RE Developer
Posts: 1037
Joined: 19 Apr 2016

07 Nov 2017

selig wrote:
04 Nov 2017

Then there's the size of the encoder LED rings, if wanted, which are at least 23mm in diameter (0.9"), which quickly eat up panel space…
Image
Oh wow, is that an encoder with ring LEDs with RGB illumination?

I had an idea awhile ago that would require such a part but I couldn't seem to find anyone actually selling them. But if they exist...

User avatar
selig
RE Developer
Posts: 11681
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

07 Nov 2017

fieldframe wrote:
selig wrote:
04 Nov 2017

Then there's the size of the encoder LED rings, if wanted, which are at least 23mm in diameter (0.9"), which quickly eat up panel space…
Image
Oh wow, is that an encoder with ring LEDs with RGB illumination?

I had an idea awhile ago that would require such a part but I couldn't seem to find anyone actually selling them. But if they exist...
Yes - seen them in person and they look good. The first two also have shafts that illuminate RGB, if you’re into that sort of thing - they have ‘transparent’ knobs for these that look pretty cool too!
They even have fader with LED illuminated sliders,which I’m guessing could be handy to indicate automation recording/playback modes.
http://www.top-up.com.tw/ezfiles/top-up ... 80x540.gif


Sent from some crappy device using Tapatalk
Selig Audio, LLC

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

20 Nov 2017

Another quick update--got the CAN Bus transceiver boards back from OSHPark, soldered them up, and starting to get some messages across the bus (though it looks like I have a problem somewhere, b/c I am getting error frames back, which is why CAN0 isn't receiving anything)--but looking pretty good otherwise!

Once this issue is ironed out, I can start having several different devices communicate with each other, sharing messages like updating fader positions, LED levels, encoder changes, etc. Each of these devices will be sections of the mixer--such as dynamics, EQ, etc.

Image

-Allison

User avatar
AttenuationHz
Posts: 2048
Joined: 20 Mar 2015
Location: Back of the Rack-1

20 Nov 2017

amcjen wrote:
20 Nov 2017
Another quick update--got the CAN Bus transceiver boards back from OSHPark, soldered them up, and starting to get some messages across the bus (though it looks like I have a problem somewhere, b/c I am getting error frames back, which is why CAN0 isn't receiving anything)--but looking pretty good otherwise!

Once this issue is ironed out, I can start having several different devices communicate with each other, sharing messages like updating fader positions, LED levels, encoder changes, etc. Each of these devices will be sections of the mixer--such as dynamics, EQ, etc.

Image

-Allison
Following this thread from the start and it is really exciting and informing seeing it develop. But the thing is for myself anyway I would not have the space for something so big but it would very cool having one. For what I would do in Reason it's mostly using Faders, Mute's, Solo's, at most 4 Aux returns(but up to 2-3 depending on track size) HP/LPF and Gains, I would use the dynamics section but not often.

Is there any plans for a smaller devices for just Gain, 2/4 Aux, Filters, Faders, Mute/Solo. I could get behind that. For both space and affordability.
I currently use a Panorama P1 and it is great being able to physically touch a fader. Something around that size would be more appealing for me and a lot of others who have space issues.



Just noticed there is images in your last post but they are not showing for me anyway.
It is not too much of an ask for people or things to be the best version of itself!

User avatar
selig
RE Developer
Posts: 11681
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

20 Nov 2017

AttenuationHz wrote:
20 Nov 2017
amcjen wrote:
20 Nov 2017
Another quick update--got the CAN Bus transceiver boards back from OSHPark, soldered them up, and starting to get some messages across the bus (though it looks like I have a problem somewhere, b/c I am getting error frames back, which is why CAN0 isn't receiving anything)--but looking pretty good otherwise!

Once this issue is ironed out, I can start having several different devices communicate with each other, sharing messages like updating fader positions, LED levels, encoder changes, etc. Each of these devices will be sections of the mixer--such as dynamics, EQ, etc.

Image

-Allison
Following this thread from the start and it is really exciting and informing seeing it develop. But the thing is for myself anyway I would not have the space for something so big but it would very cool having one. For what I would do in Reason it's mostly using Faders, Mute's, Solo's, at most 4 Aux returns(but up to 2-3 depending on track size) HP/LPF and Gains, I would use the dynamics section but not often.

Is there any plans for a smaller devices for just Gain, 2/4 Aux, Filters, Faders, Mute/Solo. I could get behind that. For both space and affordability.
I currently use a Panorama P1 and it is great being able to physically touch a fader. Something around that size would be more appealing for me and a lot of others who have space issues.



Just noticed there is images in your last post but they are not showing for me anyway.
The ideas presented are for a modular approach, which is aimed at users such as yourself! You could have a bank of just faders if you wanted - or just one fader if you REALLY wanted just one (but you would have to start with an empty chassis so you would have some empty slots).

I imagine there are very few users who would have multiple complete channel strips. My ideal setup would include 24 faders and one channel strip, along with a center "Master" section and metering (from an LCD type display ideally).
Selig Audio, LLC

illone
Posts: 39
Joined: 23 Jan 2015

20 Nov 2017

Psuper wrote:
04 Nov 2017
Wanna know my secret weapon?

Image
I love this thing.

I created a total LUA keybinding engine for this thing.
Have it totally decked out for Photoshop and a couple of games; and to a lesser extent 3ds Max, and the Propellerhead Rack Extension dev kit.

I wanted to mapped it for Visual studio but VS's keyboard shortcuts have been plenty.

===========================================================

On topic, if this SSL controller comes in sub $3-4-500 and totally replaces the mouse (per the OP's main goal) and comes out somewhat aesthetically pleasing; I'd would likely be a buyer.

--illone

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

20 Nov 2017

Yep, what Selig said. This will be pretty modular, meaning it will be really easy to make it as large or as small as you want. I think the smallest chassis considered right now will be a 2x8, or maybe a 4x8, which ends up being 3.25”x13”, or 6.5”x13”, respectively. And the idea is that you can mix and match as many chassis as you wish. Want just a center channel? Probably a couple of 4x8s would do it. Want a huge SSL-Esque desk? Lots of 6x8s and 4x8s. The best part of this is you don’t have to choose up-front. Just buy what you need and expand.

The downside of this is that there really won’t be a “price” for a system. All depends on how big you want it and what you put in it.

And in case it wasn’t super clear before, the modules that you can put into the frames will hopefully be available by many vendors, not just me, not unlike the 500-Series or modular synth subculture. Through I do plan on implementing and making available all of the Reason SSL mixer components at least.

(I know I’m going to be visiting Selig here in a couple of weeks to try to convince him to move into the hardware realm as well, but sssh, don’t tell him. ;) )

- Allison

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

20 Nov 2017

(And boo, looks like my Dropbox link broke due to deep linking. Will repost when I get back to my computer.)

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

20 Nov 2017

amcjen wrote:
20 Nov 2017
Another quick update--got the CAN Bus transceiver boards back from OSHPark, soldered them up, and starting to get some messages across the bus (though it looks like I have a problem somewhere, b/c I am getting error frames back, which is why CAN0 isn't receiving anything)--but looking pretty good otherwise!

Once this issue is ironed out, I can start having several different devices communicate with each other, sharing messages like updating fader positions, LED levels, encoder changes, etc. Each of these devices will be sections of the mixer--such as dynamics, EQ, etc.

Image

-Allison
Trying the image again--hoping it works this time:
Image

User avatar
AttenuationHz
Posts: 2048
Joined: 20 Mar 2015
Location: Back of the Rack-1

20 Nov 2017

amcjen wrote:
20 Nov 2017
amcjen wrote:
20 Nov 2017
Another quick update--got the CAN Bus transceiver boards back from OSHPark, soldered them up, and starting to get some messages across the bus (though it looks like I have a problem somewhere, b/c I am getting error frames back, which is why CAN0 isn't receiving anything)--but looking pretty good otherwise!

Once this issue is ironed out, I can start having several different devices communicate with each other, sharing messages like updating fader positions, LED levels, encoder changes, etc. Each of these devices will be sections of the mixer--such as dynamics, EQ, etc.

Image

-Allison
Trying the image again--hoping it works this time:
Image
Rodger!
It is not too much of an ask for people or things to be the best version of itself!

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

08 Dec 2017

Another quick update--I was able to get the dual CANBus controllers working, sending message between the two via a loopback setup, and I'm super pleased with the results. Getting around 5,000 messages per second, with zero messages lost after over 200 million messages sent over the course of a day. This is essentially the part of the system that will sit inside each chassis, communicating with both other chassis, and with all of the modules internally within a chassis. (Recall at the moment, chassis can be 2x8, 4x8, or 6x8 sized, with a possibility of 8x8 as well). If you have a bank of 8 faders and 8 meters, you'll want a nice, solid, fast, protocol--this should deliver.

I know a lot of these updates might seem unsexy at the moment, in that they don't show sweet flying faders or lots of blinky lights, but I'm really adamant about having a very solid, very stable, very reliable protocol upon which even the largest physical hardware controllers can be built--Reason or otherwise. If you want a full 64 channel Reason SSL-esque mixer controller with all the bells and whistles, this will support that. You just have to make the physical room for it. :)



I'm just finishing up some brutal travel, (which included a very pleasant lunch in Manhattan with Selig!), and then will be spending my holiday vacation working hard to get some prototype modules ready for testing against actual Remote automation. So hopefully a lot more news coming soon.

(Also, if you ever get a chance to meet Giles in person, don't pass it up--he's a treasure trove of deep audio, recording, and music composition knowledge. I now realize why his stuff sounds so good--he's a mastermind at thinking through audio processing a bit differently than anyone I've ever met.)

-Allie

Post Reply
  • Information
  • Who is online

    Users browsing this forum: Orbit-50 and 7 guests