11-27-2025, 02:36 PM
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.
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.
PLEASE use the search function if something have been asked or discussed before.
Every (unnessesary) forum support means less time to develop! But of course, i am here to help!
Every (unnessesary) forum support means less time to develop! But of course, i am here to help!