Select Bus

From circuitbending to homebrew stompboxes & synths, keep the DIY spirit alive!

Moderators: lisa, luketeaford, Kent, Joe.

User avatar
Sandrine
Super Deluxe Wiggler
Posts: 2238
Joined: Tue Jun 09, 2015 10:28 pm
Location: BC Canada
Contact:

Re: Select Bus

Post by Sandrine » Mon Jun 22, 2020 10:08 am

Wew this topic took off in a bizarre direction!
Putting all that in for "background" comm between modules is a bit like putting a 747 jet engine on a scooter. Costly, only will use 0.1% of it's potential & hard to find gas.
My point was kind of leading to perhaps an "accord" of sorts to upgrade the range of messages in select bus. For module to module there's really no limit as any MIDI message can be used and, as the Accord Melisma module" is already proving, state/action based master/slave selection is easy enough.
It's the fact that other modules (slaves mostly) need to be brought up to date so they won't bung up when other messages are received, even dumping it onto a modules MIDI bus seems like it should be an optional behavior

I think the midi clock and even MTS have great potential in this setting and, hey, no additional patching!

User avatar
Graham Hinton
Super Deluxe Wiggler
Posts: 3235
Joined: Fri Jul 02, 2010 6:28 pm
Location: England
Contact:

Re: Select Bus

Post by Graham Hinton » Mon Jun 22, 2020 10:32 am

Sandrine wrote:
Mon Jun 22, 2020 10:08 am
My point was kind of leading to perhaps an "accord" of sorts to upgrade the range of messages in select bus.
Isn't that just MIDI?
The thing wrong with Select Bus is that it uses a controller in a non-standard way to modify Program Changes to Program Stores and that might conflict with other usage. That's a bodge that should be deprecated. All we need is a Sysex message for that and I can define one if you like.

User avatar
Sandrine
Super Deluxe Wiggler
Posts: 2238
Joined: Tue Jun 09, 2015 10:28 pm
Location: BC Canada
Contact:

Re: Select Bus

Post by Sandrine » Tue Jun 23, 2020 10:55 am

Graham Hinton wrote:
Mon Jun 22, 2020 10:32 am
Sandrine wrote:
Mon Jun 22, 2020 10:08 am
My point was kind of leading to perhaps an "accord" of sorts to upgrade the range of messages in select bus.
Isn't that just MIDI?
The thing wrong with Select Bus is that it uses a controller in a non-standard way to modify Program Changes to Program Stores and that might conflict with other usage. That's a bodge that should be deprecated. All we need is a Sysex message for that and I can define one if you like.
Yes CC16-->127/64 acts as a preface for PC message, but this must be consecutive so there's little chance accidental changes. The SysEx would be the better way to go, and much more flexible for "outside" functions specific to certain modules. i.e. clock division changes and timing parameters or, like in the Melisma module, a root note control

Sure, what do you think would comprise a good SB SysEx?
Implementing it in a way that other modules aren't confused by it may be a trick. Those not adopting the new standard (not open source) would be out of the loop

I see MN Tempi has adopted one for mesh on/off/ default load/revert that are specific to their modules but haven't listed/used the CC16 prefix for whatever reason

User avatar
Graham Hinton
Super Deluxe Wiggler
Posts: 3235
Joined: Fri Jul 02, 2010 6:28 pm
Location: England
Contact:

Re: Select Bus

Post by Graham Hinton » Tue Jun 23, 2020 11:54 am

Sandrine wrote:
Tue Jun 23, 2020 10:55 am
Sure, what do you think would comprise a good SB SysEx?
Implementing it in a way that other modules aren't confused by it may be a trick. Those not adopting the new standard (not open source) would be out of the loop
I have a SysEx ID (old style single byte) so I can define whatever is needed and it won't conflict with anything.

How about?: <F0, 2D, 7cccc, 01, F7> = arm next Program Change on channel cccc as a Store.

Or forget about the Program Change and do it directly:
<F0, 2D, 7cccc, 01, 0pppppp, F7> = store current status in Program # ppppppp if cccc = channel #.

Other messages may be added by changing the fourth byte.

There is also the ID 7D for non commercial use, but who knows what that might conflict with?

At this point we should also define a MIDI connector header to avoid the 3.5mm plug problem.
Molex KK 0.1" 3-way.
Pin 1: Screen
Pin 2: Hot (i.e. the pullup)
Pin 3: Cold (i.e. active pull down)
(Same pin numbers as an XLR, so easy to remember.)

User avatar
EATyourGUITAR
has no life
Posts: 4812
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Select Bus

Post by EATyourGUITAR » Tue Jun 23, 2020 1:17 pm

My point was about why not being locked into a topology is a benefit. Passive hubs are possible at the media and link layer with Ethernet. The typical implementation of Ethernet makes the links self healing and generally they all play nice together. Way way back when I started my career in networking, there were devices from dissimilar vendors that would accidentally denial of service each other because of one time out being shorter than the other. Buggy code that could not be discovered unless it was a mixed vendor install. Any larger building has enough networking equipment to create these kinds of beta testers. Here we are over 20 years later. We can leverage these driver implementations that have already been proven in the real world. We don't need to invent protocols at all. Think about I2C also. But the problem is that if we do I2C then there is way more potential of one vendor to accidentally denial of service the other. We would be setting out a new standard also for all the electrical specifications. 5v 3.3v max current max over voltage output impedance HI-Z modes. Then we need a way to enumerate duplicate devices without collisions. With can bus this is not a problem. Building it on top of standard protocols that are already complete seems to like it would have less unwanted side affects and more durable in a mixed vendor system. It can be integrated over IP just like VOIP is integrated with TCP traffic and muxed. That way it can connect studio A with studio B. Every microcontroller already has Ethernet. I don't see why people shit on this idea so much. Mixed vendor systems are very difficult if the mix of vendors are creating the standard they need to implement. Everything needs to be defined through an API. That is how the world works. If CAN is the API then there is only a small amount of work setting up the new standard. arm chips have Ethernet + CAN. Sure you could use UART with dedicated starfish. It really doesn't matter if you have unlimited GPIO sending slow text message. I don't think that scales well though. Having in and out token ring with 2 wires, it could happen. The simpler you make it, the more time it will take to implement, test, document, standardize. The only problem with the midi example is the number of pins required and the network topology. star is ok if you can use a passive hub like Ethernet.
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

User avatar
Sandrine
Super Deluxe Wiggler
Posts: 2238
Joined: Tue Jun 09, 2015 10:28 pm
Location: BC Canada
Contact:

Re: Select Bus

Post by Sandrine » Thu Jun 25, 2020 8:10 am

Graham Hinton wrote:
Tue Jun 23, 2020 11:54 am
Sandrine wrote:
Tue Jun 23, 2020 10:55 am
Sure, what do you think would comprise a good SB SysEx?
Implementing it in a way that other modules aren't confused by it may be a trick. Those not adopting the new standard (not open source) would be out of the loop
I have a SysEx ID (old style single byte) so I can define whatever is needed and it won't conflict with anything.

How about?: <F0, 2D, 7cccc, 01, F7> = arm next Program Change on channel cccc as a Store.

Or forget about the Program Change and do it directly:
<F0, 2D, 7cccc, 01, 0pppppp, F7> = store current status in Program # ppppppp if cccc = channel #.

Other messages may be added by changing the fourth byte.

There is also the ID 7D for non commercial use, but who knows what that might conflict with?

At this point we should also define a MIDI connector header to avoid the 3.5mm plug problem.
Molex KK 0.1" 3-way.
Pin 1: Screen
Pin 2: Hot (i.e. the pullup)
Pin 3: Cold (i.e. active pull down)
(Same pin numbers as an XLR, so easy to remember.)
That's cool you have an old style ID!
Yes once as a SysEx might as well do it all in that
The channel # is always the same so not sure why there needs to be a condition there..unless you mean internally

IMO the header should be bi-directional for a breakout which needs 4 pins, unless there were two of those

User avatar
Sandrine
Super Deluxe Wiggler
Posts: 2238
Joined: Tue Jun 09, 2015 10:28 pm
Location: BC Canada
Contact:

Re: Select Bus

Post by Sandrine » Thu Jun 25, 2020 8:48 am

EATyourGUITAR wrote:
Tue Jun 23, 2020 1:17 pm
My point was about why not being locked into a topology is a benefit. Passive hubs are possible at the media and link layer with Ethernet. The typical implementation of Ethernet makes the links self healing and generally they all play nice together. Way way back when I started my career in networking, there were devices from dissimilar vendors that would accidentally denial of service each other because of one time out being shorter than the other. Buggy code that could not be discovered unless it was a mixed vendor install. Any larger building has enough networking equipment to create these kinds of beta testers. Here we are over 20 years later. We can leverage these driver implementations that have already been proven in the real world. We don't need to invent protocols at all. Think about I2C also. But the problem is that if we do I2C then there is way more potential of one vendor to accidentally denial of service the other. We would be setting out a new standard also for all the electrical specifications. 5v 3.3v max current max over voltage output impedance HI-Z modes. Then we need a way to enumerate duplicate devices without collisions. With can bus this is not a problem. Building it on top of standard protocols that are already complete seems to like it would have less unwanted side affects and more durable in a mixed vendor system. It can be integrated over IP just like VOIP is integrated with TCP traffic and muxed. That way it can connect studio A with studio B. Every microcontroller already has Ethernet. I don't see why people shit on this idea so much. Mixed vendor systems are very difficult if the mix of vendors are creating the standard they need to implement. Everything needs to be defined through an API. That is how the world works. If CAN is the API then there is only a small amount of work setting up the new standard. arm chips have Ethernet + CAN. Sure you could use UART with dedicated starfish. It really doesn't matter if you have unlimited GPIO sending slow text message. I don't think that scales well though. Having in and out token ring with 2 wires, it could happen. The simpler you make it, the more time it will take to implement, test, document, standardize. The only problem with the midi example is the number of pins required and the network topology. star is ok if you can use a passive hub like Ethernet.
The problem is the Select Bus is implemented to make use of (mostly) unused PSU ribbon lines so everything that uses 16 pins can access it...and most PSU buses have the 16 pins
I just wish there had been usage of the end pins as a RTS or DTR-like handshake to prevent collisions between multiple masters. I was left with timing and priority/takeover that forces a slave mode when a master is detected, then it's up to the user to send master messages
I think the main reason the ethernet idea is not adoptable is that most low power uP's don't have it as a peripheral option thus the load would be significant which can complicate timing of other functions. I do see the advantages of it though for sure. It would be amazing!

User avatar
EATyourGUITAR
has no life
Posts: 4812
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Select Bus

Post by EATyourGUITAR » Thu Jun 25, 2020 9:02 am

whoa! I thought this thread was about making a new standard like mungo. if you want to use the cv gate bus with an unknown number of modules in a mesh network with multiple masters then I really don't know what off the shelf protocol would work. you might need to build it from the ground up.
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

User avatar
Graham Hinton
Super Deluxe Wiggler
Posts: 3235
Joined: Fri Jul 02, 2010 6:28 pm
Location: England
Contact:

Re: Select Bus

Post by Graham Hinton » Thu Jun 25, 2020 10:22 am

Sandrine wrote:
Thu Jun 25, 2020 8:10 am
That's cool you have an old style ID!
I was in at the beginning :)
Yes once as a SysEx might as well do it all in that
The channel # is always the same so not sure why there needs to be a condition there..unless you mean internally
If we are going to use proper MIDI it would be an advantage to use channels because the Program Change message does. You can always assume Omni mode and ignore it. The msb = 7 is the important part.
IMO the header should be bi-directional for a breakout which needs 4 pins, unless there were two of those
That would be 5 pins. It is better to have a header per discrete connector and it probably needs to be a full MIDI port with a Thru. You can also patch point to point with a single cable between headers to roll your own distribution . I already have modules that do that and more coming.
...and most PSU buses have the 16 pins
Only in Eurorack, what about mixed formats? A distributed recall system would be better if it is universal.

EATyourGUITAR wrote:if you want to use the cv gate bus with an unknown number of modules in a mesh network with multiple masters then I really don't know what off the shelf protocol would work.
Just forget the CV/Gate bus, it's a prehensile tail.

KSS
Super Deluxe Wiggler
Posts: 2449
Joined: Mon Jan 25, 2016 7:28 am

Re: Select Bus

Post by KSS » Thu Jun 25, 2020 4:55 pm

Graham Hinton wrote:
Thu Jun 25, 2020 10:22 am
Just forget the CV/Gate bus, it's a prehensile tail.
Surely you meant vestigial?

As for the CV/gate bus,I have found it easy to grasp and useful for its originally intended task. Its major failing is not its own, but rather the modules which did not implement some way of disabling it at will. Seen in the 2500's 10 pin SEQ bus, or the KBD SW in an E-mu modular.
--------------------
It is better to have a header per discrete connector and it probably needs to be a full MIDI port with a Thru. You can also patch point to point with a single cable between headers to roll your own distribution . I already have modules that do that and more coming.
Do you already have a HDR / connector and pinout chosen?

User avatar
Graham Hinton
Super Deluxe Wiggler
Posts: 3235
Joined: Fri Jul 02, 2010 6:28 pm
Location: England
Contact:

Re: Select Bus

Post by Graham Hinton » Fri Jun 26, 2020 7:44 am

KSS wrote:
Thu Jun 25, 2020 4:55 pm
Surely you meant vestigial?
Yes I did! Sorry, too late and wrong word association stuck in my head.
As for the CV/gate bus,I have found it easy to grasp and useful for its originally intended task. Its major failing is not its own, but rather the modules which did not implement some way of disabling it at will.
It's main failing is that you can't see what is going on and it's not system wide. Or it might be system wide if someone has taken the trouble of connecting all their busboards together and then you don't know what the loading or electrical characteristics are.
Do you already have a HDR / connector and pinout chosen?
Yes, that's what I gave above. I don't like MIDI cables sticking out from module front panels so I always allow for separate panels which may be at the side or preferably on a rear panel. This also gives the option of internal direct patching.

This is all you need:
midi_io.JPG
You do not have the required permissions to view the files attached to this post.

KSS
Super Deluxe Wiggler
Posts: 2449
Joined: Mon Jan 25, 2016 7:28 am

Re: Select Bus

Post by KSS » Fri Jun 26, 2020 9:48 am

Thank you Graham.

User avatar
Sandrine
Super Deluxe Wiggler
Posts: 2238
Joined: Tue Jun 09, 2015 10:28 pm
Location: BC Canada
Contact:

Re: Select Bus

Post by Sandrine » Sun Jun 28, 2020 7:31 am

EATyourGUITAR wrote:
Thu Jun 25, 2020 9:02 am
whoa! I thought this thread was about making a new standard like mungo. if you want to use the cv gate bus with an unknown number of modules in a mesh network with multiple masters then I really don't know what off the shelf protocol would work. you might need to build it from the ground up.
No, it's about using the existing physical interface in a way that all modules that already have it will/can operate on the bus as intended. Basically new or more MIDI commands.
As it is, most modules I have seen respond in odd ways when other messages that stray from the original 2 types of select bus messages seem to have difficulties dealing with "other" messages, or just dump it onto a MIDI output.
I think the select bus MIDI should be on it's own completely and responsive to the legacy messages + ignore other future messages.
Isolating the channel(s) would be a good start, dealing with /ignoring SysEx, running status etc. another. Dealing with more intense bursts of data too, like an ID'ed SysEx full of information for brand x modules on the bus, without causing hiccups with the rest.

Bi-directionality must be endemic of a master so it can switch to being a slave if another master is heard first.

User avatar
EATyourGUITAR
has no life
Posts: 4812
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Select Bus

Post by EATyourGUITAR » Sun Jun 28, 2020 7:37 am

not just master, slave. you should think about master, slave, HI-Z. this is a common feature with SPI slaves. I'm sure you could implement something like that on less pins. more like i2c.
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

User avatar
Sandrine
Super Deluxe Wiggler
Posts: 2238
Joined: Tue Jun 09, 2015 10:28 pm
Location: BC Canada
Contact:

Re: Select Bus

Post by Sandrine » Tue Jun 30, 2020 10:13 am

EATyourGUITAR wrote:
Sun Jun 28, 2020 7:37 am
not just master, slave. you should think about master, slave, HI-Z. this is a common feature with SPI slaves. I'm sure you could implement something like that on less pins. more like i2c.
Well it's not hi-Z really, but to logic level it is, multiple 47K pull ups (or less) and >1meg pull downs on receive only's
This has a limit though if there are many masters because of the resistance adding up but who's going to have that many masters on the same bus/rack?
I like the take-over domain though as it allows multi-master scenario, and at user request so it's unlikely that there will be a collision (by accident)

Interestingly I have had 2 masters sending their data at once in perfect sync with only the value different. This acted as an AND for the data selecting a different preset haha. Each master didn't "know" the other was there because the Rx is muted for a few mS during Tx to save uP cycles. A slight change to the code to allow active monitoring of the Tx revealed to the master that the data was not correct. The handler at that point (I didn't do) would be to select a random time, check the status of the UART pin, then re-send, re-check.
I think this is the way to go :yay:

-edit-
BTW, I hate i2c because of it's slowness, but have used multiple perif's with the same address by using an analog switch to select the clock lines. Just have to be careful with the pull-up values is all

User avatar
EATyourGUITAR
has no life
Posts: 4812
Joined: Tue Aug 31, 2010 12:24 am
Location: Providence, RI, USA

Re: Select Bus

Post by EATyourGUITAR » Tue Jun 30, 2020 11:20 am

This is exactly how it is done in media access control. Random wait times. You may have collisions when first powered on but the probability of collisions decrease exponentially with seconds of being powered on. So yes this has been done before 30 years ago. They simply could not think of a better way for shared copper media.
WWW.EATYOURGUITAR.COM <---- MY DIY STUFF

Post Reply

Return to “Music Tech DIY”