Reason SSL Mixer Hardware Controller

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
Post Reply
User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

19 Oct 2017

Such wow here.

I was thinking about something like this as well and I think this is going the right way. I have only one thing I thought I would mention and thats the "slot style" you seem to be going at. I see a few issues with that.

First of all the slot style makes the whole thing quite deep, the connectors in the back and all of that will make single modules have a depth that will make it hard to have a surface style casing. Second it makes larger modules problematic, it forces you to arrange the knobs in a certain way. Third it makes the modules relatively expensive with a casing and connectors for each.

I was thinking about doing it a little bit more DIY (not just slot modules) and at the same time more flexible for having larger surfaces (e.g. like subtractor) as well. The idea is basically having modules be actual PCBs and a simple front plate, this would also make single modules very cheap.

See my picture below - yes, I am an artist ;)

Image

Top is the desk frame with all power, USB-MIDI and bus connections etc. inside. The middle is a side view of the PCB inside the desk frame. The bottom is the front plate that would go on the desk frame.

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

19 Oct 2017

normen wrote:Such wow here.

I was thinking about something like this as well and I think this is going the right way. I have only one thing I thought I would mention and thats the "slot style" you seem to be going at. I see a few issues with that.

First of all the slot style makes the whole thing quite deep, the connectors in the back and all of that will make single modules have a depth that will make it hard to have a surface style casing. Second it makes larger modules problematic, it forces you to arrange the knobs in a certain way. Third it makes the modules relatively expensive with a casing and connectors for each.

I was thinking about doing it a little bit more DIY (not just slot modules) and at the same time more flexible for having larger surfaces (e.g. like subtractor) as well. The idea is basically having modules be actual PCBs and a simple front plate, this would also make single modules very cheap.

See my picture below - yes, I am an artist ;)

Image

Top is the desk frame with all power, USB-MIDI and bus connections etc. inside. The middle is a side view of the PCB inside the desk frame. The bottom is the front plate that would go on the desk frame.
I’m totally with you. I was sketching some possible module sizes last night and I agree, it needs to be simple and lightweight. I had mentioned MOTM and 500 series, and I wasn’t very clear in that it should only be module height/width, not depth (which, IIRC a 500 series module is ~6” deep—pretty deep!)

How you sketched it is very much how it should be, IMO. [emoji106]

I think I have a way to make the frame so that modules can be 1, 2, 3, or 4 vertical units tall, and 1, 2, 3, or 4 horizontal units wide. I don’t know how tall or wide each unit is yet though—toying with 1.5” wide == 1 horizontal unit and either 1.5” or 1.75” == 1 vertical unit.

The former makes for nice, compact, symmetrical module sizes. The latter’s height matches what you see in most rack mount equipment (1U 19” rack is 1.75”).

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

19 Oct 2017

normen wrote:Such wow here.

I was thinking about something like this as well and I think this is going the right way. I have only one thing I thought I would mention and thats the "slot style" you seem to be going at. I see a few issues with that.

First of all the slot style makes the whole thing quite deep, the connectors in the back and all of that will make single modules have a depth that will make it hard to have a surface style casing. Second it makes larger modules problematic, it forces you to arrange the knobs in a certain way. Third it makes the modules relatively expensive with a casing and connectors for each.

I was thinking about doing it a little bit more DIY (not just slot modules) and at the same time more flexible for having larger surfaces (e.g. like subtractor) as well. The idea is basically having modules be actual PCBs and a simple front plate, this would also make single modules very cheap.

See my picture below - yes, I am an artist ;)

Image

Top is the desk frame with all power, USB-MIDI and bus connections etc. inside. The middle is a side view of the PCB inside the desk frame. The bottom is the front plate that would go on the desk frame.
This is more in line with what I was originally thinking!

To be clear, I was not suggesting adopting an existing standard (such as API 500 or Eurorack), since they are designed for powering audio modules with large PCBs.

What I was envisioning instead was more flexible (not fixed to any panel size), likely using a ribbon connector so as not to restrict the panels in any way.

In some cases you COULD make a 500/eurorack panel work, but in many more it would not make sense.

What I suggest is a common grid for the UI, much like Rack Units for 19” racks. You could, for example, have a unit that is 1U wide by 5U tall. You could conceivably have a 1U by 1U unit (solo/mute?). You could also have a 5U by 5U unit as well or 10x10 etc.

I would think the 500 series would be too narrow - maybe use the 1.75 in. Rack Unit size? When folks take modules from vintage consoles, they usually turn them horizontally and they fit nicely (they typically create new panels, but the format seems to fit nicely).

This approach allows someone to create a full “to scale” SSL controller channel(s), OR something completely unique and user specific (and everything in between).


Sent from some crappy device using Tapatalk
Selig Audio, LLC

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

19 Oct 2017

amcjen wrote: I’m totally with you. I was sketching some possible module sizes last night and I agree, it needs to be simple and lightweight. I had mentioned MOTM and 500 series, and I wasn’t very clear in that it should only be module height/width, not depth (which, IIRC a 500 series module is ~6” deep—pretty deep!)

How you sketched it is very much how it should be, IMO. [emoji106]

I think I have a way to make the frame so that modules can be 1, 2, 3, or 4 vertical units tall, and 1, 2, 3, or 4 horizontal units wide. I don’t know how tall or wide each unit is yet though—toying with 1.5” wide == 1 horizontal unit and either 1.5” or 1.75” == 1 vertical unit.

The former makes for nice, compact, symmetrical module sizes. The latter’s height matches what you see in most rack mount equipment (1U 19” rack is 1.75”).
Sorry, should have read your reply before replying to Normen!


Sent from some crappy device using Tapatalk
Selig Audio, LLC

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

19 Oct 2017

Was just at AES earlier today in NYC and found a vendor (Top-up Industry Corp. http://www.top-up.com.tw/front/bin/home.phtml) for all the controls needed to complete any front panel! Took lots of pictures of hardware controllers for references too. Lots of cool ideas out there - most include a touch screen of some sort these days. Will add photos shortly…
Selig Audio, LLC

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

20 Oct 2017

selig wrote:
Sorry, should have read your reply before replying to Normen!
All good! We’re on the same page :)

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

20 Oct 2017

selig wrote:Was just at AES earlier today in NYC and found a vendor (Top-up Industry Corp. http://www.top-up.com.tw/front/bin/home.phtml) for all the controls needed to complete any front panel! Took lots of pictures of hardware controllers for references too. Lots of cool ideas out there - most include a touch screen of some sort these days. Will add photos shortly…
Oooh! Looks like all the necessary bits for robust control surface elements. Nice find! (And jealous about you being at AES!)

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

21 Oct 2017

Did lots of travel for work again this week, and flying back from Chicago, so had some time to whip up some notes on the platform. It's rough (so pls excuse the typos), and needs some thought/eyeballs from all you fine folks here. But here you go! Let the convo begin!


TONIC SYSTEM SPECS:

Overview
  • Tonic is a platform that specifies the physical dimensions, power, communication, and audio capabilities for modern, efficient hardware control of audio instruments and software.
  • The Tonic platform consists of one or more chassis, each with one or more modules installed into each chassis.
  • Chassis have physical mount points for any sized module, as well as providing for power and communication, (and perhaps later, balanced audio) connectivity.
  • Chassis can be connected together using the same connectivity protocol as modules use within a chassis. There is only one communications protocol for the entire system.
  • Each chassis can provide its own power supply, if desired, in order to stay in spec.
Physical Dimensions
  • 8 columns wide (@ 1.5" each) per chassis (12" wide)
  • 12 rows tall (@ 1.75" each) per chassis (21" high)
  • Modules are dimensioned by width x height. i.e. a 1x4 is 1 column wide by 4 rows tall (4u)—and would measure 1.5" x 7" tall.
  • Module can be as small as 1x1 and large as 8x12.
  • The maximum number of modules a chassis can hold is 96 (8x12)
  • Modules are sized in "units", which is simply their width x height, i.e. a 1x4 module is a "4 unit", a 2x3 module is a "6 unit".
  • Every module will have at least four mount points, using 4-40 countersunk screws.
  • Any configuration of module unit size can be successfully mounted to the chassis.
Power
  • At least one chassis in a Tonic system must provide a +5 volt rail to the system.
  • A chassis must be able to support at least 200mA per module-unit size.
  • For worst case scenario of a chassis loaded with the maximum number of modules (96), each drawing their maximum of 200mA, a chassis must support up to 19.2A @ 5V. (something like this would work)
  • Modules must not draw more than 200mA per unit-size. i.e, a 4 unit cannot draw more than 800mA.
Communication
  • The Tonic System uses the CAN Bus 2.0b spec, which provides an address space of up to 29 bits, or over 536 million unique addresses.
  • The CAN Bus 2.0b implementation of the platform must support 1Mb/sec throughput, to ensure real-time performance on even the largest systems.
  • CAN Bus 2.0b is not an address-based protocol, but is a message-based protocol. This means that any module can send a message, and every other module in the entire system will receive the message. Every module receives every message in the platform.
  • Not every module must act on every message, but can do so if it wishes. This provides for inter-module communication built into the platform, if desired.
  • Modules can (and should) do hardware filtering/masking of messages (also known as "frames"), in order to ignore the majority of messages irrelevant to its function.
  • There are four types of frames in the CAN Bus 2.0b: data frames, remote frames, error frames, and overload frames.
  • Data frames provide data from a module, to the bus.
  • Remote frames act as a request for a data frame from another module.
  • Error frames are generated by modules that detect a protocol error.
  • Overload frames are generated by modules that require more time to process the data than the inbound message rate.
  • The control message format for the frame payload is TBD.
  • Given the 1Mb/sec throughput requirement, an 8-chassis Tonic system would, in the worst case, have a total of 768 modules (96*8), and the platform should theoretically be able to support sending 170 bytes per module per second [(2^20 bits/sec) / (8 bits/byte) / (96*8 modules)]
External Device Connectivity
  • A Tonic system can run standalone, but will often connect to external devices, such as computers or MIDI-based instruments.
  • For external device connectivity, a specialized module must handle the conversion between the Tonic communication bus and the external protocol, such as the Propellerhead’s Remote or general MIDI protocol, including specialized MIDI protocols such as Mackie HUI.
About to land, will try to draw up some pics to show the mounting holes idea soon!
Ciao,
-Allison
Last edited by amcjen on 21 Oct 2017, edited 3 times in total.

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

21 Oct 2017

Oh yeah, forgot this:


User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Oct 2017

I‘m not 100% sold on the audio and CAN thing.

For the audio... to be able to route any audio in our out of Reason this thing would have to be the audio interface in Reason. You can‘t have two audio interfaces in Reason and you also don‘t have any other way to get audio in. So effectively having a 500 Rack connected to your audio interface would be much more convenient and still allow for especially embedded devices in Reason (by giving them USB-MIDI connectors, such devices already exist). Leaving out this feature would also lower the average expected power consumption immensely, thus reducing cost. Not to mention shielding, power and ground buses and all of that. If you have audio in there you have to have a separate power line for that, best a +/- one etc. etc. - throwing in audio will make this MUCH harder to pull off in general.

For the CAN bus its got to do with the former - if theres no audio and we only consider USB-MIDI as our baseline (just like Reason does for control surfaces) then i2c has way enough throughput, is much cheaper and basically already built into even the smallest ATTiny..

Again, just my thoughts - only throwing this out here as food for thought. Getting more and more excited at the prospect of this actually working out :)

Edit: And btw if you need help with the Reason Remote coding part later I'd be willing to help for that, I'm registered as a Remote developer (not that it would be hard to register ;)).

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

21 Oct 2017

normen wrote:I‘m not 100% sold on the audio and CAN thing.

For the audio... to be able to route any audio in our out of Reason this thing would have to be the audio interface in Reason. You can‘t have two audio interfaces in Reason and you also don‘t have any other way to get audio in. So effectively having a 500 Rack connected to your audio interface would be much more convenient and still allow for especially embedded devices in Reason (by giving them USB-MIDI connectors, such devices already exist). Leaving out this feature would also lower the average expected power consumption immensely, thus reducing cost. Not to mention shielding, power and ground buses and all of that. If you have audio in there you have to have a separate power line for that, best a +/- one etc. etc. - throwing in audio will make this MUCH harder to pull off in general.

For the CAN bus its got to do with the former - if theres no audio and we only consider USB-MIDI as our baseline (just like Reason does for control surfaces) then i2c has way enough throughput, is much cheaper and basically already built into even the smallest ATTiny..

Again, just my thoughts - only throwing this out here as food for thought. Getting more and more excited at the prospect of this actually working out [emoji3]

Edit: And btw if you need help with the Reason Remote coding part later I'd be willing to help for that, I'm registered as a Remote developer (not that it would be hard to register ;)).
Good stuff. I’m not sold on the audio either. But, when defining protocols it’s good to either plan for it or decide not to do it at all. I wouldn’t want to get into the interface game. So I hear you—audio is uncertain and could be feature creep.

However, I’m not sure about I2C. It’s true that the tiniest Atmel chips do have it built in, but the problem IMO is that it’s right on the border of not having enough speed (400k is the fastest speed IIRC for those tiny AT chips). More importantly though, it’s address space is only 127 devices IIRC, and it’s an address protocol, which requires every device to not only address where its message is going, but to keep track of addressing of all other devices. I want to make sure this can support up to a full 64 channels—and I suspect I2C will start to fall over.

And agree, if you remove the audio, then your payload is much simpler. However, the choice of the phy/mac layers of the bus (CAN vs. I2C) would not affect the midi/control payload in the higher OSI layers.

(And to ensure it will be super duper easy to make these modules, the expectation is that you’d just use this $1.50 transceiver with the available Arduino library. Low overhead and extremely fast.

Glad to see some really experienced Remote developers here!

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

21 Oct 2017

amcjen wrote:
21 Oct 2017
However, I’m not sure about I2C. It’s true that the tiniest Atmel chips do have it built in, but the problem IMO is that it’s right on the border of not having enough speed (400k is the fastest speed IIRC for those tiny AT chips). More importantly though, it’s address space is only 127 devices IIRC, and it’s an address protocol, which requires every device to not only address where its message is going, but to keep track of addressing of all other devices. I want to make sure this can support up to a full 64 channels—and I suspect I2C will start to fall over.

And agree, if you remove the audio, then your payload is much simpler. However, the choice of the phy/mac layers of the bus (CAN vs. I2C) would not affect the midi/control payload in the higher OSI layers.
Alright, I see. Sounds like CAN is the safer route then.

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

26 Oct 2017

Hiya! Spent some time this week getting all of the guts of the framework ironed out—from power requirements to communcation protocol minimum speeds to spec’ing out appropriate cabling, connectors, and physical fasteners.

Meanwhile, the fundamentals are coming together nicely. Whipped up a small circuit board on Oshpark to get the CANbus transceivers communicating between three modules. Should be here in a week or so, and then it’ll be time for another video.

Hope everyone is enjoying Reason v10.0!

- Allison
IMG_0697.JPG
IMG_0697.JPG (383.36 KiB) Viewed 3490 times

User avatar
Djstarski
Posts: 364
Joined: 20 Jan 2015

26 Oct 2017

This is the most interesting thread i have seen in a long time . watching a idea grow from scratch . Its like watch a tv show lol . Great stuff

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

26 Oct 2017

Wow that looks awesome..

I was thinking for the chassis it makes sense to also aim for something you could even do with a laser cutter, right? These things can be surprisingly stable, be it plastic or wood. Obviously there should also be a "professional" metal version but maybe there can be different versions with the same dimensions. That way people can laser cut OR cut, bend & weld sheet metal - or buy it from somebody who makes them nice and shiny..

Feeling a bit useless just throwing this in though as I am not really experienced with that stuff apart from using/building it - my area of expertise (audio) has probably just been kicked out with my own help ;)

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

26 Oct 2017

Here are some shots of the current crop of hardware controllers for digital audio, from the 2017 AES convention earlier this month. The trend is to have almost as much vertical as horizontal workspace, which I've always liked over the years.

That would be my one major suggestion for the drawings you recently posted (above).
Attachments
IMG_8998.jpeg
IMG_8998.jpeg (107.69 KiB) Viewed 3446 times
IMG_8997.jpeg
IMG_8997.jpeg (115.63 KiB) Viewed 3446 times
IMG_8996.jpeg
IMG_8996.jpeg (139.02 KiB) Viewed 3446 times
IMG_8995.jpeg
IMG_8995.jpeg (121.65 KiB) Viewed 3446 times
IMG_8994.jpeg
IMG_8994.jpeg (108.77 KiB) Viewed 3446 times
IMG_8992.jpeg
IMG_8992.jpeg (97.59 KiB) Viewed 3446 times
IMG_9009.jpeg
IMG_9009.jpeg (127.48 KiB) Viewed 3446 times
IMG_9003.jpeg
IMG_9003.jpeg (144.66 KiB) Viewed 3446 times
IMG_9002.jpeg
IMG_9002.jpeg (121.5 KiB) Viewed 3446 times
IMG_9001.jpeg
IMG_9001.jpeg (109.52 KiB) Viewed 3446 times
IMG_8999.jpeg
IMG_8999.jpeg (112.09 KiB) Viewed 3446 times
Selig Audio, LLC

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

26 Oct 2017

normen wrote:Wow that looks awesome..

I was thinking for the chassis it makes sense to also aim for something you could even do with a laser cutter, right? These things can be surprisingly stable, be it plastic or wood. Obviously there should also be a "professional" metal version but maybe there can be different versions with the same dimensions. That way people can laser cut OR cut, bend & weld sheet metal - or buy it from somebody who makes them nice and shiny..
Oh totally. Laser cutting at our local prototyping/maker space is also my plan for trying out the first prototype—probably acrylic. It’s cheap and strong and let’s you try out lots of cuts simultaneously.

Of course, if this thing is going to be truly modular, than everyone else building modules will also need to be able to prototype quickly and cheaply!

The only thing that probably needs to be metal is the inside upper layer, as it has all the threads for the standoffs.
Feeling a bit useless just throwing this in though as I am not really experienced with that stuff apart from using/building it - my area of expertise (audio) has probably just been kicked out with my own help ;)
Building/using it may be the most important part! Getting the layout and fundamentals right so that the thing feels useful will be the most critical work imo.

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

26 Oct 2017

selig wrote:Here are some shots of the current crop of hardware controllers for digital audio, from the 2017 AES convention earlier this month. The trend is to have almost as much vertical as horizontal workspace, which I've always liked over the years.

That would be my one major suggestion for the drawings you recently posted (above).
So interesting, Selig. So many control surfaces with so much screen real estate! Now I know why you are bullish on lots of displays in the controller. Definitely seems to be the upcoming wave. (Also, it’s harder to read a screen on a flat surface.)

I used the 12 degree slant from the SSL design, but then tossed in (on the side view only) a 2U meter bridge style add-on just to see how it looked. However, maybe it makes sense to make a separate, taller (another 12U?), more steeply angled enclosure that would look more like the pics you took? It means two chassis instead of one, but gives the flexibility of making a surface that you can choose to go with for future, screen-oriented setups, or not go with for more traditional large format setups.

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

26 Oct 2017

normen wrote:…Feeling a bit useless just throwing this in though as I am not really experienced with that stuff apart from using/building it - my area of expertise (audio) has probably just been kicked out with my own help ;)
On the contrary, I would think your input here would be quite valuable, as someone who probably spends more time “hands on” with this type of controller than most of us!
:)


Sent from some crappy device using Tapatalk
Selig Audio, LLC

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

26 Oct 2017

selig wrote:
normen wrote:…Feeling a bit useless just throwing this in though as I am not really experienced with that stuff apart from using/building it - my area of expertise (audio) has probably just been kicked out with my own help ;)
On the contrary, I would think your input here would be quite valuable, as someone who probably spends more time “hands on” with this type of controller than most of us!
:)
1,000%!

User avatar
mcatalao
Competition Winner
Posts: 1823
Joined: 17 Jan 2015

26 Oct 2017

selig wrote:
26 Oct 2017
Here are some shots of the current crop of hardware controllers for digital audio, from the 2017 AES convention earlier this month. The trend is to have almost as much vertical as horizontal workspace, which I've always liked over the years.

That would be my one major suggestion for the drawings you recently posted (above).
Oh man these are SO SO beautifull!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

There. Just broke my exclamation point key!

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

26 Oct 2017

mcatalao wrote:
selig wrote:
26 Oct 2017
Here are some shots of the current crop of hardware controllers for digital audio, from the 2017 AES convention earlier this month. The trend is to have almost as much vertical as horizontal workspace, which I've always liked over the years.

That would be my one major suggestion for the drawings you recently posted (above).
Oh man these are SO SO beautifull!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

There. Just broke my exclamation point key!
If you look closely you can probably see lots of drool on these beauties! ;)


Sent from some crappy device using Tapatalk
Selig Audio, LLC

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

27 Oct 2017

Kind of in a wait mode right now—adapter boards should be here around Nov 6th.

BTW, anybody going to the Robotspeak synth meet in SF this weekend? If so, say hi!



Image

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

04 Nov 2017

Excellent, looks like the boards for the canbus transceivers are done and will be on their way soon. I also have a lot of notes I’ve started coalescing into a PDF that I’ll post shortly. It’s far from complete, but it’s starting to shape up into a proper product requirements document (PRD).

Image

User avatar
amcjen
Posts: 211
Joined: 14 Apr 2017

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

Post Reply
  • Information
  • Who is online

    Users browsing this forum: deeplink and 5 guests