ReasonTalk.com

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



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.

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



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.

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”).

selig wrote:
Sorry, should have read your reply before replying to Normen!

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…

• 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.

• 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.

• 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.

• 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)]

• 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.

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 ).

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.

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..

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

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).

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

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!

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).

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!