Reason SSL Mixer Hardware Controller

This forum is for discussing Propellerhead's music software. Questions, answers, ideas, and opinions... all apply.
User avatar
normen
Posts: 3430
Joined: 16 Jan 2015

Post 08 Dec 2017

amcjen wrote:
08 Dec 2017
I know a lot of these updates might seem unsexy at the moment
The exact opposite, the meticulous planning gets me even more excited that this could actually work out. Great ideas and 2D/3D renders of fantastic remote controls and audio gadgets are plentiful but seldom come to fruition.

User avatar
Delora Software
Posts: 107
Joined: 18 Jan 2015

Post 08 Dec 2017

amcjen wrote:
08 Dec 2017
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.
What is the available payload for each message, and does 5K messages/sec represents the total available system message bandwidth?
Doug

Douglas Kraul
Delora Software
http://www.delora.com
Developer of rsTouch Pro for Reason and rsRemote for Reason

For the latest news on rsTouch and rsRemote follow us https://twitter.com/DeloraSoftware

User avatar
PSoames
Posts: 273
Joined: 15 Jan 2015
Location: Somerset, UK

Post 08 Dec 2017

normen wrote:
08 Dec 2017
amcjen wrote:
08 Dec 2017
I know a lot of these updates might seem unsexy at the moment
The exact opposite, the meticulous planning gets me even more excited that this could actually work out. Great ideas and 2D/3D renders of fantastic remote controls and audio gadgets are plentiful but seldom come to fruition.
Thoroughly agree. I'm watching engineering drama. An intense story with none of the boring human stuff - just design and technology unfolding before me.

The episode about the power supply, was brilliant. More of this please. ;)

User avatar
selig
Moderator
Posts: 7577
Joined: 15 Jan 2015

Post 08 Dec 2017

normen wrote:
08 Dec 2017
amcjen wrote:
08 Dec 2017
I know a lot of these updates might seem unsexy at the moment
The exact opposite, the meticulous planning gets me even more excited that this could actually work out. Great ideas and 2D/3D renders of fantastic remote controls and audio gadgets are plentiful but seldom come to fruition.
^^THIS^^
Without such a strong foundation and rock-solid fundamentals, none of the rest really matter IMO. This attention to detail and understanding of what matters is what has sold me on Allison's approach and qualifications for taking on this task!

Looking at it (loosely) from the Perato Principle (80/20 Rule) angle, the first 20% of the work will be responsible for 80% of the eventual success.
Selig Audio, LLC

User avatar
hollyn
Posts: 28
Joined: 15 Jan 2015
Location: Portland, OR

Post 09 Dec 2017

PSoames wrote:
08 Dec 2017
[quote=normen post_id=368958 time=<a href="tel:1512728425">1512728425</a> user_id=5291]
[quote=amcjen post_id=368948 time=<a href="tel:1512720819">1512720819</a> user_id=10266]I know a lot of these updates might seem unsexy at the moment
The exact opposite, the meticulous planning gets me even more excited that this could actually work out.[/quote]

Ditto ^this^ and that goes for what Giles said!

And I’m even impressed by Dougas’ question even though I don’t know what exactly it means. 😊

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 09 Dec 2017

Delora Software wrote:
08 Dec 2017
What is the available payload for each message, and does 5K messages/sec represents the total available system message bandwidth?
The payload can be up to 8 bytes (64 bits), which isn't a lot--but if you think of each message being specific for one particular element within a device, nothing really requires more than pitch bend at 14 bits (-8,192 - 8,191), so giving us 2 bytes (16 bits) of payload value space still gives us 6 bytes left for addressing specific elements within a module. Probably don't need more than one byte for that (unless you think you'll have more than 256 elements/leds/LED rings/etc to control per module).

Image

And yeah, 5k messages/sec represents the total available system message bandwidth. CANBus is a message-based protocol (compared to IP-based protocols, which are address-based, and thus require routers, etc). The good thing about message-based protocols is that anything can join the network without any configuration. The bad thing is that everything on the network gets every single message.

I'm doing a bit of a hybrid thing with this setup, where each chassis will have a "local" CANBus network, and a "global" CANBus network that all the chassis are a part of. Just like inside your house you likely have a local area network on your own wifi, just for you and your family/friends. Outside of your house is the big wide Internet. Your home router decides what messages go where. (My analogy kinda falls apart b/c different protocols as mentioned above, but the same network topology applies!)

But even with this hybrid setup, 5k messages/sec. will be available. I couldn't try faster than 5k b/c I have a 5-message-per-event-loop structure set up, and was adding a 1ms delay in my event loop. Let me set a microsecond delay and we'll see just how fast this mofo will run! Maybe it'll go much higher than 5k.

Hope that clarifies! -A

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 09 Dec 2017

amcjen wrote:
09 Dec 2017
But even with this hybrid setup, 5k messages/sec. will be available. I couldn't try faster than 5k b/c I have a 5-message-per-event-loop structure set up, and was adding a 1ms delay in my event loop. Let me set a microsecond delay and we'll see just how fast this mofo will run! Maybe it'll go much higher than 5k.
Holy crap, okay--switching from 1ms delay to just above 500µs delay (600µs, or 0.6ms to be exact), and it starts to fall over and can't read messages as fast as it's sending them. This means the hardware is just about capable of 10,000 messages/sec. Not shabby!

It's impt to keep in mind if there's a lot of heavy processing happening outside of the devices generating and receiving the messages, then some messages could be lost--but the fact that the transceivers and chassis HW can support this amount of throughput makes me really pleased this will be a sufficient backbone for lots and lots of flying faders connected to Reason computers all over the world. ❤️

(Then again, I suppose us Reason users are used to CPU load affecting our workflow and how it can cause missed messages... To soon? ;) )

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 09 Dec 2017

PSoames wrote:
08 Dec 2017
The episode about the power supply, was brilliant. More of this please. ;)
Haha! Duly noted. I will have more nerdy things emerge soon. One week left before my two week holiday starts!

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 10 Dec 2017

I found a little more time than I expected tonight and wired up the first module--behold, the fader!

Image

It looks like a mess because breadboarding is pretty hard to keep super neat and tidy, and for some reason my image hosting server rotated it sideways instead of correctly being vertical, but whatever. But it includes the following:
  • a small 128x128 OLED display for showing the track name or other info about the channel
  • LED-enabled mute and solo buttons
  • a pan/balance rotary encoder (with push-button capability. Spin it to adjust pan/balance, push the encoder down while twisting to adjust width)
  • 32 segment level/peak meter (mono for now, just to test)
  • motorized, touch-sensitive fader
It also has some ancillary hardware necessary to do what it needs to do--namely an H-bridge motor controller, so the fader can easily be powered at different speeds and directions by the microcontroller, and can enable both a soft and hard brake, the CANBus transceiver of course, so it can communicate with the chassis router (as described previously in the earlier post), and lastly, this really slick IC I came across that can handle 50Hz updates of up to 128 LEDs and reading of up to 39 buttons, while using minimal pins from the microcontroller. This chip will control all LEDs on this module--mute, solo, the 32 (eventually 64) level/peak LEDs, and the eventual LED ring for the pan/balance knob. If the price isn't outrageous, I'll probably just use this same chip for pretty much all modules that have more than, say, 6 LEDs, because it's so fast and simple.

Things the fader module doesn't have yet:
  • stereo metering
  • LED ring for the pan/balance encoder
  • a dedicated "track select" button
I know better than to fire up a newly built breadboard after midnight, so going to hit the sack and give this another review tomorrow before starting to power things up. Will post again once I make some further progress!

- Allison


PS - I was packing up some old boxes earlier tonight as we're moving, and came across these. Thought you'd all enjoy seeing them (especially the Reason 3 disk with support for Windows XP, omg!)
Image

User avatar
selig
Moderator
Posts: 7577
Joined: 15 Jan 2015

Post 10 Dec 2017

That's almost exactly enough parts to make one of these:
Screen Shot 2017-12-10 at 7.27.15 AM.png
You do not have the required permissions to view the files attached to this post.
Selig Audio, LLC

User avatar
normen
Posts: 3430
Joined: 16 Jan 2015

Post 10 Dec 2017

Image

Edit: To make this post more useful, heres a supplier from Germany for metal front plates with holes, cuts, inscriptions etc. They even have their own little design application where you can design, edit and directly buy the plates. They're not too expensive, the app and all the options are very flexible and it's good quality, I already bought a few of them.

User avatar
Delora Software
Posts: 107
Joined: 18 Jan 2015

Post 10 Dec 2017

amcjen wrote:
09 Dec 2017
Delora Software wrote:
08 Dec 2017
What is the available payload for each message, and does 5K messages/sec represents the total available system message bandwidth?
The payload can be up to 8 bytes (64 bits), which isn't a lot--but if you think of each message being specific for one particular element within a device, nothing really requires more than pitch bend at 14 bits (-8,192 - 8,191), so giving us 2 bytes (16 bits) of payload value space still gives us 6 bytes left for addressing specific elements within a module. Probably don't need more than one byte for that (unless you think you'll have more than 256 elements/leds/LED rings/etc to control per module).

And yeah, 5k messages/sec represents the total available system message bandwidth. CANBus is a message-based protocol (compared to IP-based protocols, which are address-based, and thus require routers, etc). The good thing about message-based protocols is that anything can join the network without any configuration. The bad thing is that everything on the network gets every single message.

I'm doing a bit of a hybrid thing with this setup, where each chassis will have a "local" CANBus network, and a "global" CANBus network that all the chassis are a part of. Just like inside your house you likely have a local area network on your own wifi, just for you and your family/friends. Outside of your house is the big wide Internet. Your home router decides what messages go where. (My analogy kinda falls apart b/c different protocols as mentioned above, but the same network topology applies!)

But even with this hybrid setup, 5k messages/sec. will be available. I couldn't try faster than 5k b/c I have a 5-message-per-event-loop structure set up, and was adding a 1ms delay in my event loop. Let me set a microsecond delay and we'll see just how fast this mofo will run! Maybe it'll go much higher than 5k.

Hope that clarifies! -A
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.

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.

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.

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.

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.

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

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.

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.

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.

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

Douglas Kraul
Delora Software
http://www.delora.com
Developer of rsTouch Pro for Reason and rsRemote for Reason

For the latest news on rsTouch and rsRemote follow us https://twitter.com/DeloraSoftware

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 11 Dec 2017

selig wrote:
10 Dec 2017
That's almost exactly enough parts to make one of these:
That's the plan!

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 11 Dec 2017

normen wrote:
10 Dec 2017
Image

Edit: To make this post more useful, heres a supplier from Germany for metal front plates with holes, cuts, inscriptions etc. They even have their own little design application where you can design, edit and directly buy the plates. They're not too expensive, the app and all the options are very flexible and it's good quality, I already bought a few of them.
Excellent to know! I wasn't aware of them. I was looking into http://www.frontpanelexpress.com/ and then saw that Shaeffer-AG is the European counterpart to Front Panel Express. Very nice!

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 11 Dec 2017

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!

<snip>
Doug! That is an incredibly impressive response--and has a ton of useful information. I would like to respond more thoroughly and really need to go to bed, but came here to post a quick video update before crashing--will respond more fully shortly! So much good stuff in your reply. -A

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 11 Dec 2017

Spent a little time tonight finally bringing up the fader module--it was a little finicky, but got about half of it working internally. Here's what's working now:
  • Fader calibration
  • Touch-sensing of the fader
  • Real-time updating of the fader output when manually being changed by a human hand
  • Auto cutoff of fader motor if touch is sensed
  • Pan/balance encoder sending data
  • Mute/Solo buttons working
What still needs to be done:
  • OLED screen outputting more than just white
  • pushbutton for pan/balance encoder (to switch between pan and width)
  • LEDs for Mute/Solo, when they're enabled
  • 32 LED bargraph working
  • CANBus interface back to the chassis router


(Ha, just noticed that my timeout for fader calibration to zero is a little too short, and so the fader didn't go all the way to the bottom, nor did it get near "0" when getting its minimum value. That's why calibration's so important on motorized faders! Will adjust tomorrow.)

More soon!
-Allie

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 25 Jan 2018

Hiya!

I’ve been pretty quiet on the forum but am due for another update. I’ve gone down the rabbit hole of finding the ideal rotary encoder (knob, but one that never stops spinning, and usu has LEDs around it to indicate position). There are a lot of shitty ones and I want it to feel solid and quality. I also wanted ones that can be a push button as well as an option, and I didn’t want any clicking like some encoders have. I think I found the one, but took a few weeks and a lot of online ordering to find it! It's wonderful--feels totally smooth and no clicks--very quality. Bourns is the brand--they're solid. (Evaluated ALPS as well and they're niiiiiice too, but they're like 10x the price, and _trying_ to keep cost a bit under control.)

Then came the search for the right knob cap. I wanted it to resemble the Reason mixer, so figured why not just go to the source? Turns out you can buy replacement knobs from SSL directly so I have a whole host of those now too.

The good news is I have a fader module designed, with the proper pan encoder/knob cap, along with an OLED display for the track name, mute/solo/select-auto buttons, a motorized fader and a 36 segment led meter all working. Very exciting!

Also just finished up the design of the "brain" of every module. It’s a tiny 0.7”x1.4” computer that will be used for every module—has common code and interface plugs to connect everything up. Also lets pretty much anybody make their own module without going down the same rabbit hole. It will be Arduino-compatible, (if you're familiar with that), so if you can copy/paste code, you'll be able to make your own simple modules. But it has all the important protocol stuff (including the high-speed CANBus), so you literally just plug it in and start going. Just ordered the first run of these from the PCB fab house--should be here in two weeks.

Now time to do a final review of the fader module schematic, and I’ll get it sent off to PCB fab and two weeks later will solder everything up and at that point the first Tonic module will be ready for Remote messages.

This is the slow boring part, but it's starting to take form, and it's really exciting. :)

-A.

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 28 Jan 2018

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

User avatar
dioxide
Posts: 978
Joined: 15 Jul 2015

Post 28 Jan 2018

I'm still following this and I'm very interested, but haven't anything to contribute as almost all of this is waaay over my head. Anyway, I spotted this on Synthtopia the other day. It's a modular audio mixer (not MIDI) but thought there might be something of interest on their website. It's all open so perhaps there is something of value to learn from this project?
https://finegear.net/#technicalSpecifications

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 28 Jan 2018

dioxide wrote:I'm still following this and I'm very interested, but haven't anything to contribute as almost all of this is waaay over my head. Anyway, I spotted this on Synthtopia the other day. It's a modular audio mixer (not MIDI) but thought there might be something of interest on their website. It's all open so perhaps there is something of value to learn from this project?
https://finegear.net/#technicalSpecifications
Wow, that is pretty awesome! I’m a big fan of the Colour series of modules. (And in a previous life I interviewed with Peterson over there for his DIYRE podcast on open source hardware, but that was years ago. He’s done an amazing job building up that community IMO.)

So, it could be pretty stellar at some point to experiment with Tonic and Finegear to provide it with full capabilities. Though it would be a project built upon another project, which can get tricky if one or both are often changing.

Regardless, lots to take away from their approach. For one, their approach to being creative-commons open is the right move IMO and plans are to do something very similar (though unsure if I’d choose CC over other licenses such as the OHL one). Goal always being is to support the most amount of new and compatible products as possible, and fundamentally the end user from obsolescence. It’s what started me down this path and I intend on seeing it through. :)

Also interested to learn more on how they connect their blocks—always an impt design decision.

Thanks for sharing Dioxide! I might try out a couple of their blocks once their shop comes back online.

-Allison

mcatalao
Posts: 843
Joined: 17 Jan 2015

Post 18 Feb 2018

Guys i've been talking to Giles about this and he thinks some of my experience with my multiple BCF2000 and BCR2000 setup can help.
These difficulties can give you insight on the way Reason works with multiple controllers.

For example, Reason works with controllers with batches of 8 channels (at least it is like this for BCF2000). When you add a second bcf it works like the same BCF and the channels get glued. I'm only saying this because it is important if you want to create a modular system as Giles has passed to me and the behaviour of this system might be a little odd with the way reason remote files work. I end up solving this issue with preset

So imho and for the sake of modularity and usage, you should think about what is the maximum number of stuff you want to control and have a remote file for the whole bunch (if you're doing a mixer make it with 8 channel batches but createa remote file with 64).

Another interesting thing is how you can change from a multi channel mode to a single channel mode between multi devices. For example depending of the hardware devices you might want the fader section to control the mixer but the rotators of the rightmost section to control the channel strip of a a channel or if you want to go to a device these have to contol the device. Behringer has a nice way to do it for the new mixers, as you can toggle from multi mode in to single channel mode within that device (and if you search in the Remote Files, it has a section with 64 channels of single mode controlling). This is fine as long as you're using 1 controller and need to work only with 64 channels, but with a fader controller and an additional controller for the channel strip (or with that example of the mixer with the channel strip on the side) It really works best with multiple remote files.

My idea is if you want to streamline your workflow, you need to take your hands from the mouse (and even the keyboard if possible!). Reason helps a lot as the remote files make Reason one of the most amazing softwares to work with controllers (and they really step it up when they added VST's and gave them the ability to be controlled by remote files), but there are base things that don't help much.

Another idea i had and Giles thought would be interesting is to have some sort of macro senders. Imagine you can put your midi controllers doing stuff that is not available by midi or stuff that is not even remoteable, but you can put the controller doing it. I thin it could be doable, if the controller had a midi driver and a human interface driver (like a mouse) at the same time.

Anyway... Count me in if you need to discuss this things further!

mcatalao
Posts: 843
Joined: 17 Jan 2015

Post 18 Feb 2018

amcjen wrote:
28 Jan 2018
dioxide wrote:I'm still following this and I'm very interested, but haven't anything to contribute as almost all of this is waaay over my head. Anyway, I spotted this on Synthtopia the other day. It's a modular audio mixer (not MIDI) but thought there might be something of interest on their website. It's all open so perhaps there is something of value to learn from this project?
https://finegear.net/#technicalSpecifications
Wow, that is pretty awesome! I’m a big fan of the Colour series of modules. (And in a previous life I interviewed with Peterson over there for his DIYRE podcast on open source hardware, but that was years ago. He’s done an amazing job building up that community IMO.)

So, it could be pretty stellar at some point to experiment with Tonic and Finegear to provide it with full capabilities. Though it would be a project built upon another project, which can get tricky if one or both are often changing.

Regardless, lots to take away from their approach. For one, their approach to being creative-commons open is the right move IMO and plans are to do something very similar (though unsure if I’d choose CC over other licenses such as the OHL one). Goal always being is to support the most amount of new and compatible products as possible, and fundamentally the end user from obsolescence. It’s what started me down this path and I intend on seeing it through. :)

Also interested to learn more on how they connect their blocks—always an impt design decision.

Thanks for sharing Dioxide! I might try out a couple of their blocks once their shop comes back online.

-Allison
Just saw FineGear. Nice aproach but imho stay away from non infinite knobs! They are a pain in the rear for daw control!

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 19 Mar 2018

Hi everyone-

So I've been a lot more quiet than I had hoped, but wanted to give you all an update--first personal, then project-based.

Personal: I've been working hard on a project--it's a global competition called XPrize, and this particular project was focused on women's safety (https://safety.xprize.org/). It's a competition to design, develop, and build a wearable device for trying to globally combat violence against women. I had applied back last year to do this project, and with our design docs and preliminary prototypes, ended up getting accepted to the semi-finals (woo!) The problem was, it was taking ALL of my free time. The finals are being held in Mumbai, India in the middle of April, but when push came to shove, I just couldn't finish it all in the timeline needed, so I decided to bow out of the competition last week. Boooo. But the device is awesome, and I wear a prototype on my wrist all the time now. It would still need a ton of work to get it production-ready, and so I'm going to move that project to the back burner now that we're not in the competition anymore.

The reason I bring all that up is that the wearable project was taking 120% of my time because it had such tight timelines. So during the last few months I sadly placed all my Tonic mixer prototype goodies in a box for later. But now I can pull it back out and get back to it! I left off on the fader module--I have the motorized fader working, the mute/solo buttons, the rotary encoder for the pan/balance knob, and the LCD for the channel strip. I have a bunch of rotary encoders purchased (along with SSL knobs) that I need to finalize on--then I'll make a prototype PCB for this fader module and give it a go on a prototype panel. Time to revive this project.

I hope all of you are well-
Allison

User avatar
geremix
Posts: 27
Joined: 30 Apr 2016

Post 19 Mar 2018

Yeeeessssss!!!
It’s great to hear from you!!

And congratulations for de women’s safety project!


Enviado desde mi iPhone utilizando Tapatalk

User avatar
amcjen
Posts: 180
Joined: 14 Apr 2017

Post 19 Mar 2018

geremix wrote:Yeeeessssss!!!
It’s great to hear from you!!

And congratulations for de women’s safety project!


Enviado desde mi iPhone utilizando Tapatalk
Awesome, thank you! Good to be back!

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot], eusti, Kategra and 2 guests