did you consider using a handful of shift register such as 74HC165 ?
2, 3: I2C has timing accuracy limitations, as it goes through the Linux kernel.
1, 5: the Gpio
class can be pretty time-accurate at a clock corresponding to the block period: with a block size of 16 you can reliably read/write at 44100/16 = 2756 Hz .
Ward Both IC's are hard to find in the current chipocalypse so that's a downside. It seems the TCA8418 only stores 10 keyup or down events which means I would need to read it quite often to prevent overflowing which is also a downside.
you are surely going to be able to read it more than once every 100ms, so you wouldn't overflow, but if you arte trying to do anything time-sensitive via I2C (including tap-tempo), you may run into trouble.
Ward 4 could be nice but I only have 1 Bela digital I/O available. Is adding 7 or 8 digital I/O to the PRU code possible?
It wouldn't be impossible, but it would require quite some work: there currently is a 32 bit word per frame that is used to communicate between ARM and PRU. The lower 16 bits determine pin direction, the higher 16 bits indicate input or output value. Expanding the number of channels means either keeping 32 bit for 32 channels and hard-coding which bits are inputs and which are outputs or expanding the size of the word. On the PRU side, you will have to add a few mappings to map a bit to a GPIO pin and currently we are only accessing two GPIO banks (GPIO1 and GPIO). If you were to add more pins that are on a different GPIO bank, then you'd need even more changes to the code and I am wondering whether you'd end up having timing issues (i.e.: does the PRU code have enough spare time to perform another GPIO's writes and reads? Probably yes but ...).
You mention you only have one channel available ( I assume that's 1 Bela Digital channel available). I am wondering what you are using the other 15 for. If it's something that doesn't need 44100 Hz sampling, then you could move what's currently there to using the Gpio
class (with the timing characteristics mentioned above) and reserve the Bela Digital channels for shift registers/muxers etc that require higher bandwidth,