i2c bypass debug mode?

[flel]

Would it be possible to have a i2c bypass debug mode where there NerdSeq is bypassed and bus A and B are directly linked? I have leaders (crow + teletype) on bus A and followers (just friends, distings) on bus B. For debugging/testing purposes, it would be great to be able to control the followers (JF+Distings) directly from Crow + TT and completely bypassing the NerdSeq without having to completely rearrange my cases (especially i2c wiring in the back). Would it be possible to add an option that can be toggled in the NerdSeq that would effectively make the NerdSeq invisible for i2c and connected the two busses together? Is this already possible and I am somehow missing it?

[XORadmin]

2 leaders on one bus = collision.

However, if both got the same address then you can bypass the signal. You set for example B to out merge and it will output the data that comes in from I2CA to I2CB.

Important is the address since a follower can always only listen to 1 address (well theoretically also broadcast etc, but it has to answer which can also cause bus collisions). The NerdSEQ I2C is fixed to answer only on one address.

[flel]

Ok so there is some weird behavior trying to forward commands from Teletype to ER-301 via NerdSeq. I have it setup as follows:

Leader: Teletype
Followers:
Crow 0x60 (wired to Teletype + NerdSeq)
Just Friends 0x70 (wired to Teletype + 16n)
16n 0x34 (wired to JF)
NerdSeq 0x31 (NS>Teletype on bus A, wired to Crow; Out merge on bus B, wired to ER-32)
ER-301 0x32 (wired to NerdSeq)

If I send SC.CV and SC.TR from NerdSeq to ER-301 (Multi-IO track) this works exactly as intended.

However, SC.CV and SC.TR commands from Teletype are not properly merged to bus B (which has the ER-301) when in "Out Merge" mode.

If I send SC.CV commands on the Teletype there is definitely signal merged into NS bus B, as both i2c A and B lights are blinking red. Indeed, if I switch bus B mode to "out", the red i2c bus B light on the multi-IO does not turn on (but A stays on). However, there seem to be an issue that only an initial CV pulse is actually sent to the ER-301, and any subsequent pulses are not.

Furthermore, for some reason, sending SC.TR commands (and anything other than SC.CV) does not trigger the Multi-IO bus B front panel light to turn on in "Out Merge" mode.

Could there be a bug/issue with how the merging is done?

Is it possible to have crow/teletype wired directly to both ER-301 and NerdSeq? And NerdSeq independently to the ER-301 as well?

[XORadmin]

Ok so there is some weird behavior trying to forward commands from Teletype to ER-301 via NerdSeq. I have it setup as follows:

Leader: Teletype
Followers:
Crow 0x60 (wired to Teletype + NerdSeq)
Just Friends 0x70 (wired to Teletype + 16n)
16n 0x34 (wired to JF)
NerdSeq 0x31 (NS>Teletype on bus A, wired to Crow; Out merge on bus B, wired to ER-32)
ER-301 0x32 (wired to NerdSeq)

If I send SC.CV and SC.TR from NerdSeq to ER-301 (Multi-IO track) this works exactly as intended.

However, SC.CV and SC.TR commands from Teletype are not properly merged to bus B (which has the ER-301) when in "Out Merge" mode.

If I send SC.CV commands on the Teletype there is definitely signal merged into NS bus B, as both i2c A and B lights are blinking red. Indeed, if I switch bus B mode to "out", the red i2c bus B light on the multi-IO does not turn on (but A stays on). However, there seem to be an issue that only an initial CV pulse is actually sent to the ER-301, and any subsequent pulses are not.

Furthermore, for some reason, sending SC.TR commands (and anything other than SC.CV) does not trigger the Multi-IO bus B front panel light to turn on in "Out Merge" mode.

Could there be a bug/issue with how the merging is done?

Is it possible to have crow/teletype wired directly to both ER-301 and NerdSeq? And NerdSeq independently to the ER-301 as well?

I see the issue and for now I am only passing SC.CV with the merge command (most probably having in mind back then that one would have a faderbox as master which should be used in the nerdseq but also completely passed further). The command also is merged with the fixed 0x31 address which would be used for a first ER-301. 

Wiring the teletype/crow to both NerdSEQ and ER-301 while also acting as a leader to the ER-301 (double leader system) can work but it goes wrong once the signals collide = Teletype/Crow and NerdSEQ trying to send something to the ER301 at he same time.

From the manual:

"NerdSEQ I2C (Follower) ← Teletype (Leader Mode)
There is no Teletype integration at the moment but this is planned after the upcoming Teletype Firmware release (V5.0). But it can be used already with the Teletype in a minimal way. The Teletype Commands SC.CV can be used already to change parameters in the NerdSEQ. The NerdSEQ port would then be set to be a follower, Address 0x31 (or 32, 33) and as a 16n input."

 
So there is no benefit currently using the teletype mode. One basic idea was to make the NerdSEQ varibles available in the Teletype (it could poll them) but since there was never any deeper discussion rather than 'we should do it at some point' this is left open until then. 

I could implement the merge of all commands coming from the I2C port (in fact I got this commented out/disabled in my code), but keep in mind here that you would need to take care of the addresses (by definition...thats I2C, a follower acknowledges if it sees it's own address). A follower port can receive it's data only on one port (eg 0x31) and if you would for example receive 0x32 it would be ignored and so also not passed to a ER301 which is set to 0x32. Only 0x31 would be passed to 0x31. 
Even though they are theoretical workarounds for it (just listen and acknowledge to every address or to more than one address or just listen but no acknowledge etc..) it would not work out well. It would introduce much more 'why doesn't it work' situations than they are already.

[flel]

I see the issue and for now I am only passing SC.CV with the merge command (most probably having in mind back then that one would have a faderbox as master which should be used in the nerdseq but also completely passed further). The command also is merged with the fixed 0x31 address which would be used for a first ER-301. 

..
 
So there is no benefit currently using the teletype mode. One basic idea was to make the NerdSEQ varibles available in the Teletype (it could poll them) but since there was never any deeper discussion rather than 'we should do it at some point' this is left open until then. 

I could implement the merge of all commands coming from the I2C port (in fact I got this commented out/disabled in my code), but keep in mind here that you would need to take care of the addresses (by definition...thats I2C, a follower acknowledges if it sees it's own address). A follower port can receive it's data only on one port (eg 0x31) and if you would for example receive 0x32 it would be ignored and so also not passed to a ER301 which is set to 0x32. Only 0x31 would be passed to 0x31. 
Even though they are theoretical workarounds for it (just listen and acknowledge to every address or to more than one address or just listen but no acknowledge etc..) it would not work out well. It would introduce much more 'why doesn't it work' situations than they are already.

So the way it works with Teletype > ER-301 is that you have to use ports 101-200 when the ER-301 is set to listen to 0x32 instead of 0x31. If the NS is set to 0x31, would it be possible to forward those later ports? Or maybe forwarding all data would be the most "true" implementation of "Out Merge", leaving it up to each module to decide what to do with the data?

See also think link on the ER-301 spec for mapping ports and destinations: https://docs.orthogonaldevices.com/er-30...setup.html

Eg. right now my TT messages directed at the ER-301 did not get properly merged. I believe (not near modular right not to re-confirm) that sending SC.CV on port 101 did not get merged by NS, whereas SC.CV messages on port 1 did get merged (but for some reason only the first pulse was properly merged?).

Wiring the teletype/crow to both NerdSEQ and ER-301 while also acting as a leader to the ER-301 (double leader system) can work but it goes wrong once the signals collide = Teletype/Crow and NerdSEQ trying to send something to the ER301 at he same time.

Do you know if collisions occur if the NS and TT are sending messages on separate ports? E.g. I want to use NS to send triggers and CV to trigger and modulate pitch on drum patterns, but I want to use the TT to modulate the mixer for various channels, various effects, etc. So while it's entirely possible (and likely) that two messages will be sent at the same time (especially because TT and NS will be using the same clock) it is impossible for them to be affecting the same port.

[XORadmin]

You should be aware of the technical part of this.
If you set the ER301 to ports 100-200 then it listens only to address 0x32 and not to 0x31 anymore. That is defined by the hardware. The portnumber doesn't really matter, but the follower address does. If a leader sends to address 0x32 then the follower with address 0x32 sends an acknowledge back and then the communication starts for this packet. An acknowledge is always needed, so sending out any data just as midi doesn't work. If there is no acknowledge then the packet will not be send.

So if the NerdSEQ listens to 0x31 then it will acknowledge any data going to 0x31, but it will not acknowledge the data going to 0x32 (and so not receive it either, the leader might handle also a timeout if that happens).
Most microcontrollers and CPU which are able to receive I2C data can always only be set to only one follower address (just like different perpheral chips which I2C is initially designed for...it's not designed to control synth engines). They are low level settings available on most which could disable acknowledge, multi-leader functionality etc, but these are not implemented in any of the synth I2C engines. That is for example the reason any 16n won't work (in leader mode) if it didn't receive any acknowledge 10 seconds after startup and so disables it's complete I2C functionality.

As for the I2C in the NerdSEQ, it is quite flexible, but working outside of the used standard will make it more complex. Starting from setting it up, up to debugging why it doesn't work.
That brings me back to the topic:
Data sent to 0x31 if the NerdSEQ is 0x31 in follower mode will be received and a SC/CV packet will be forwarded (merged) to the other port. SC.TR is not included in this as mentioned earlier. That is a part I can change. If it receives data to 0x32 then it will be ignored as it is for another follower. (This happens on a 'hardware level')

Multiple Leaders can cause collisions, doesn't matter to which ports things are being send. This can cause data and synchronisation loss.

[flel]

Okay, got it. So having both NS and TT/Crow act as a leader to ER-301 will not work.

That then leaves me two solutions:
1. I could write a polling script in Lua that's run on crow that polls the NS (now set as follower on both busses) and have that data sent to ER-301 with TT/Crow as the sole leader
2. Or, assuming a software patch on the NS, I could have both ER-301 and NS (on bus A) use 0x31 in follower mode and have TT or Crow send packets that are "out merge" forwarded to ER-301 on bus B (with NS set as leader).

Did I get that right? What would you think would the best option? Curious when you think you'd be able to make this patch?

P.s. I was noticing a weird bug with "out merge" that only the first of a clocked SC.CV signal from TT got forwarded/merged and subsequent were not- any idea why? I can provide a video if that helps?

P.p.s. the whole reason for wanting this is the limit on mapping rows. I could use the mapping screen of course to actively forward every port but I am close to maxing out my 100 ports (already more than mapping can handle) and I also want to use mapping rows for some other fun things.

P.p.p.s. what was your original intended use case for "merge out" if it only merges packages which were acknowledged to be received on the other port? essentially this limits "merge out" in that any other followers need to be set to the same address as NS for the merged packages to be informative?