#273

I was having intermittent midi problems when I was using a non-stereo patch cable to connect to the TXb.

#274

Everything about this sounds wrong. Don’t use a mono cable in i2c jacks. This will/could short things.

4 Likes
#275

Hmmm, one wonders if people making 16n’s for others should include a stereo patch cable with the build and figure it in the price.

#276

Its quite clear trs midi and i2c jacks need stereo plugs , and are not to be hotswapped,

My post is referring to changing the code. in enabling the i2c master flag. When i do this, faderbank stops broadcasting usb midi. The extent to which it still does work, ie i2c working i have not checked yet , but just setting master kills usb midi

4 Likes
#277

can’t remember specifics - read further up the thread. I think the newer version will fix this?

#278

Dont see any posts mentioning this

#279

try 1.32 perhaps? (which is the current release)
https://github.com/16n-faderbank/16n/releases/download/v1.32/16n_firmware_v132_MASTER.hex

#280

Do you know where i can find the uncompiled code?. Want to test the master flag behaviour

#281

:roll_eyes: please try a little harder. It’s in the first post of this thread. All the source is on Github

2 Likes
#282

I know where the source on github is, and it says current version is 1.31. The actual code (.ino) in the firmware folder has no mention of version number in its header, I obviously assume its 1.31 , without diving into dev branches its not obvious where 1.32 can be found

Anyway, installed latest code , usb midi breaks when uploading code with master flag set

#283

Found 1.32, same problem

#284

Ok - something is a bit off, but I can’t quite track it down yet.

(using 1.32) I can replicated a situation where having i2c plugged-in seems to crash usbmidi. If I unplug and replug the 16n usbmidi will work again (not sure about i2c at this point as my testing situation is limited).

#285

Ok… More Testing (@bpcmusic and @infovore would you take a look at this?)
(same behavior with 1.32 or the simplify_midi_interrupts branch)

in Follower mode
– devices powered off
– power on follower (16n) first, then power on leader = ok
– disconnecting power on leader kills usbmidi on 16n
– at this point i2c still ACKs on 16n, but usbmidi is down.

When I unplug the other device (Just another teensy in this case) I see this dump from midi monitor:

|19:35:00.136|From 16n|Control|1|34|123|
|---|---|---|---|---|---|
|19:35:00.139|From 16n|Control|1|41|123|
|19:35:00.146|From 16n|Control|1|32|123|
|19:35:00.149|From 16n|Control|1|40|123|
|19:35:00.149|From 16n|Control|1|43|123|
|19:35:00.150|From 16n|Control|1|44|123|
|19:35:00.151|From 16n|Control|1|38|123|
|19:35:00.154|From 16n|Control|1|36|123|
|19:35:00.156|From 16n|Control|1|42|123|
|19:35:00.158|From 16n|Control|1|33|123|
|19:35:00.162|From 16n|Control|1|37|123|
|19:35:00.165|From 16n|Control|1|47|123|
|19:35:00.167|From 16n|Control|1|46|123|
|19:35:00.182|From 16n|Control|1|35|123|
|19:35:00.187|From 16n|Control|1|39|123|

EDIT - added 2.2K resistors on 16n DNP pads and still seeing usbmidi crash.

EDIT #2: I put the 16n into USB Type SERIAL+MIDI (to check DEBUG) and with it set this way, it’s not crashing usbmidi (with or without DEBUG enabled).

#287

Ok, more testing needed: simplify midi interrupts isn’t solving that.

I am hyper busy for the next few weeks but will see what I can do. Alternatively, the code is all there if anyone else wants to get stuck in. (@okyeron, this has all been massively helpful, thank you very much for your debugging and assistance so far)

2 Likes
#288

FWIW - the midi dump I posted above may or may not be an indicator of anything. At the time most of the faders were all the way up - so usbmidi is apparently sending those (non-zero) values when i2c gets dropped/killed on the connected device.

I also had another thought - in my testing both devices are plugged into the same USB hub. Perhaps there is some wacky usb/midi cross-talk happening when I unplug one device.

None of that really explains why changing the setup to SERIAL+MIDI makes the problem go away (which is a least a fix for the time being).

#289

I have some further interrupt related ideas: might knock all of the “nointerrupt” code out of the I2c blocks, now that interrupts are just setting a variable.

Teaching all day today and tomorrow, a long way from any faders, but I might spike the code tonight.

1 Like
#290

In looking at it, it feels like the “interrupt/nointerrupt” calls in the main loop are a good. The “interrupt/nointerrupt” calls in the i2c handler method are not needed as the i2c handler itself runs in an interrupt.

@infovore - I’ll do a tweak and test on this later today and see if it helps.

@okyeron - I always compile in MIDI+Serial mode (helps with debugging); any reason you know of why we wouldn’t want to?

Finally - hot plugging i2c can be problematic and is not recommended (including turning off remote devices). There are things happening deep in libraries and deep in the processor itself that I’ve found can get super-borked. :exploding_head:

#291

To be clear I’m not touching the i2c cable - I am unplugging the usb cable which provides power to the device (from the usb-A host end). This happens in both leader and follower modes.

I can test with a powered busboard in the middle later.

If SERIAL+MIDI is recommended then that should be added to the docs.

EDIT: but please test in just MIDI mode and see if you’re getting the problem.

#292

Ok. So I tested this with one of my 16n. This is a prior version (before the multiplexer was added to simplify the Teensy integration). I built the latest firmware (the branch with the reduced MIDI interrupts) and set it to MIDI only mode. Plugging the USB connection (power and MIDI) from my mac worked flawlessly. I was pounding it with i2c on the Teletype at the same time (reading all 16 faders every 10ms).

I’m wondering if it is something with the multiplexer. Alas, I haven’t yet built one with the mux.

I’ll make a build of the firmware with @infovore’s insight from above (reduced interrupt blocking in the i2c call) and send it to you via PM. If you are willing, I’d love it if you could try this build out.

2 Likes
#293

Really want to stress this. Yes, we’ve broken out I2C on a stereo jack because it’s a bit friendlier than dupont headers or ribbon cable, but it’s not a protocol designed for hot-plugging in any way.