Hi Douglas--I realized I never replied to this very thorough response! My sincerest apologies--my replies below.
Delora Software wrote: ↑10 Dec 2017
Thanks for the detailed explanation, and for taking the time to see how fast you could push things. This is a very cool project!
I did some back of the napkin bandwidth calculation and 5K-10K messages/sec should handle the Reason-to-surface data requirements for large SSL control surfaces, provided there is a shared channel strip instead of each channel having a full channel strip. I do though wonder if the shared nature of the bus will introduce unacceptably high latency for user control surface "moves". Also should someone desire a control surface with more per-channel controls, like the ~35 available on the SSL, then the shared bus bandwidth is likely overstressed.
If the bus is saturated, even briefly, due to a large amount of changes sent by Reason, then this creates an uncertain time before a given fader can get access to the bus to send its data. In the case of say ten simultaneous fader moves the problem is amplified because not only is the bus experiencing high usage, but also each of the faders is potentially competing to use the bus. Furthermore since changing a continuous control, like a fader, can itself introduce a lot of messages in a short period of time, the combined fader further stress the bus.
Yes, this could be a problem if there is bus contention. I have read (though haven't tried) that the board I plan to use for the USB connection to the computer running reason can indeed run at USB High-Speed (which is up to 480Mb/sec).
Real-world experience by others has been shown at least 22MB/sec (176Mb/sec). That should be pretty significant throughput "muscle" for the entire control surface installation. The problems will start cropping up if you start to exceed the 1Mb/sec-per-chassis limitation of the CANBus.
Also, if the High-Speed USB port of the controller board somehow still doesn't support enough throughput (perhaps because of inefficiencies of the Remote driver itself on the PC), each chassis controller board does indeed have its own USB port, so you could probably just plug in multiple chassis and make sure they're not daisy-chained together. This would provide for more throughput of whatever the USB system would support per-port on the computer.
Delora Software wrote: ↑10 Dec 2017
I guess that you could improve things by giving nodes that send data to Reason higher priority (I believe CANBus has some type of priority scheme). Then at least the user-initiated messages will get to Reason in a timely manner. Note though that a 1 msec fader update rate, and 10 simultaneous fader moves, will require the full 10K messages/sec bandwidth, leaving nothing for messages from Reason.
Indeed. However, the 10k messages/sec is
per chassis, not per installation. So it's probably unlikely you'd have more than 8 faders per chassis (unless you made small ones, or oriented them sideways or something). Also, not sure 1ms/fader update rate is necessary, that's pretty fast. Could probably get away with 25ms or 50ms rate with no discernible difference in fader movement (as I believe there would be physical motor limitations to moving that fast). So unless you're going to move all 8 faders simultaneously while having all 8 faders get update messages from Remote and stick with a 1ms/sec update, then this shouldn't be a problem--esp. at at 25ms-50ms update rate. But this is an excellent test to add to the test plan.
(As a big aside, the fader module prototype has the ability to control speed, direction, and hard and soft braking of the fader's motor. This means that with some more clever code, we can read the first derivative of the fader Remote messages coming in and do ease-in/ease-out ramping on fader positions, which, in my opinion, make for a much more pleasant and professional feel to flying faders, vs the jolt-to-position-immediately that some more affordable control surfaces do--not to mention it can be pretty hard on the fader motor mechanics to do that a lot.)
Delora Software wrote: ↑10 Dec 2017
It would be interesting to see how much performance is possible when you have a number of nodes each trying to send at the same time.
This is definitely in the test plan! I plan on testing 9 chassis (8 fader banks/meters and 1 robust center channel) using one USB High Speed connection controller board, with each chassis on a single CANBus network, and inside each chassis running its own CANBus network.
If it falls over, will try multiple USB connections to the computer, and if that falls over, will consider an alternative controller board (perhaps a RaspPi 3 or something of similar muscle in the ARM A-series class device).
Delora Software wrote: ↑10 Dec 2017
Physical ("DIN MIDI") has a lower message rate but it offers true full-duplex operation. Even if Reason is saturating the incoming "cable" the outbound "cable" bandwidth is fully available. Each cable provides ~1K messages/sec, and with proper encoding this can be, under some conditions, increased to ~1.5K/sec due to running status. (3K/sec is possible but only for a small subset of messages that are not generally useful for full range control values). MIDI's full duplex operation might actually afford better latency performance even with its much lower bandwidth.
Interesting! You make a very good point. Full-duplex is a definite benefit to bus contention, especially when you have a large asymmetry between incoming and outgoing message throughput. Conveniently, the controller board candidate has firmware support for acting as its own USB-MIDI host, supporting up to 16 devices connected to it, including 6 MIDI in and MIDI out hardware serial UARTs. That'd give you twelve DIN MIDI ports (6 in, 6 out) if this route made sense. It would be nice to have it native MIDI instead of MIDI buried in CANBus.
Delora Software wrote: ↑10 Dec 2017
The two-tier "Global, Local" dual CANBus scheme is pretty clever, and will likely work good enough for many control surfaces. But it does suffer from the potential that the global bus becomes the limiting factor. It also affords no scaling benefits. Connecting more chassis does not improve overall bandwidth and likely decreases peak throughput.
True, but I believe (and must test) that if you run out of bandwidth, just disconnect the chassis daisychain from the master USB controller chassis and plug that one into USB instead. (Of course, would have to add another Remote device to Reason, like you do with Mackie HUI Controller and Extender(s)).
Delora Software wrote: ↑10 Dec 2017
Perhaps it, and the implied overall central controller (the MCU sitting between the various chassis and Reason), is unnecessary. Instead think of each chassis as a stand-alone control surface, and that the Remote codec running under Reason serves as the central control node. Each chassis would have as its master controller a USB-capable MCU. It would implement class-compliant MIDI, which in turn, would eventually connect to the Reason computer (there is probably a USB hub in the picture, which both conceptually and physically is part of the control surface).
You're reading my mind.
The good news in this approach is that it solves the throughput problem. But... the size of that USB hub is gonna be huuuuuuuge.
Delora Software wrote: ↑10 Dec 2017
Reason "sees" multiple MIDI ports that are assigned automatically to the control surface codec. The codec is then responsible for directing Reason's outbound messages to the appropriate chassis. Inbound messages from each chassis are collected by Reason and dispatched to the codec with the source port info intact (if needed).
One benefit of this type of approach is that for larger, more complex, control surface multiple MIDI ports are probably necessary anyway to provided needed peak bandwidth. Scaling becomes limited by USB bandwidth, and host computer processing. But those were going to be the case anyway.
One slight modification to this proposal would be to let the "chassis controller" MCU have the option for either a second CANBus, or the USB endpoint interface. That way you could configure a global CANBus scheme if that was most appropriate. Furthermore such a controller could be used as either a chassis controller or the central controller in the global-local CANBus architecture.
Indeed this gives a ton of flexibility.
Delora Software wrote: ↑10 Dec 2017
A few other random thoughts:
1. "Classic" Reason devices, like the SSL, typically use 7-bit parameter values, the exception being mixer levels and the master level. However newer devices, especially Rack Extensions, now default to 22-bit control ranges; the RE designer has to override this to use a smaller range. Many do not. (Europa and Grain liberally use these 22-bit ranges). So the 16-bit message payload is fine but the impact on the MIDI pipe is pronounced (limited number of possible 14-bit encodings per MIDI interface). This is another reason why multiple MIDI interfaces to/from Reason will be necessary for some controllers.
This is really good to know.
Delora Software wrote: ↑10 Dec 2017
2. Text, such as for "scribble strip" LCDs, will break the "values fit in 16-bit messages" model. If a fixed message payload is used then there will need to be a multi-message, variable length, scheme to handle text. On the MIDI side of things this will almost certainly be handled via SYSEX messages.
Yes, a similar fragmentation handler will be required at the CANBus app layer to disassemble/reassemble these longer messages.
Funny enough, people working on CANBus on Toyota Prius's have the
same issue.
Delora Software wrote: ↑10 Dec 2017
3. One possible area that might require some early prototyping is meter visual performance. There may be the potential for strobing/flickering effects if the updates to multiple meters are not synchronized, analogous to frame-synchronous updates in video. The need to mitigate this probably increases if a relatively low meter update rate is used. I'm concerned that a low effective frame rate, coupled with "simultaneous" changes across many channel meters, will produce a kind of ripple/wave like visual effect. Increasing each meters update rate only helps so much.
I don't know if I fully follow. Do you mean strobing b/c the controller board is dropping packets, or b/c the controller board can't update the LED displays fast enough?
If the latter, I plan on using a separate LED controller for all LEDs on modules that I design (obviously can't speak for others who design their own--they can use whatever they want). But the controllers I've spec'ed will handle up to 128 channels and synchronize all updates on a ~10ms period. It's nice b/c I can interface to them from the module "brain" (the controller board that is per-module). So hopefully this sort of flicker due to an MCU hitting its processing limit won't be too much of a problem.
If the former, then I don't know if you'd see strobing so much as you'd see meters that go from one LED lit to three LEDs lit, missing the second b/c that message wasn't received/processed. Could be a problem if you never get another update (like on a pan change), then your controller would be out of sync with Reason until the next update. This is something I'd want to avoid happening.
(Also, this last point you bring up reminds me of the
work the UC Berkeley folks are doing on trying to solve for lost packets for note-off messages over networks. We'd have the same issue, and could utilize their proposals pretty successfully if we chose to encode the packets similarly to them. And there's Apple's
RTP-MIDI that could solve this too.)
Doug, thank you immensely for the deep dive into some of the nuances of the approach here. I sincerely appreciate the time it took for you to respond, and the level of expertise you have in MIDI, USB, etc. It delights me that there are so many sharp people on this forum lending their perspective to the endeavor. It is already showing in the solid foundation being built.
All the best-
Allison