re: i2c protocol, this should be a good starting point: https://github.com/scanner-darkly/teletype/wiki/II-protocol
but yeah, basically it’s
address byte | command byte | optional parameters
it’s up to the device to interpret what comes after the address byte in whatever way it needs. instead of using one byte for commands you could use two, for instance, if you need more than 256 commands. same with parameters - each command can have as many parameters as it needs.
so i would just use whatever values are not used right now for the new midi commands and then for each define what parameters it needs. and since these commands will be for transit (and other devices that want to support this protocol) there is no need for any special consideration from teletype point of view (although it’s possible it’ll make sense to add support for these commands as teletype ops as well at some point in the future).
with that in mind there is a couple of things that should be considered when defining new commands:
SC commands use the same command values as @bpcmusic’s telex modules. this makes it easier to re-use the same code in teletype (and to some extent, faderbank). so if there is a possibility that more telex commands will be supported by er-301 in the future you should try and use different values for the new midi commands to avoid possible conflicts.
i would also avoid 0xC0-0xFF range if possible as there are some vague plans to possibly use these in the future for global commands (commands that would affect all connected i2c devices) such as global clock / reset.