i don’t know the details of how i2c works, and i was wondering if it is possible (for example) to have a 16n sending (via i2c) CV values to an ER-301 (say CV 0-15) and at the same type having the teletype sending other trig and CV (via i2c) to the same ER-301 (say CV 16-100) ?
aka having two “i2c master devices” adressing different “variables” on a single “slave” device ?
I have been using an external 8 fader box w/ an FH-1 in my modular and like not taking up extra HP w/ the faders. It makes it more playable than trying to move tiny faders that are half covered by cables. But that’s just my opinion.
Looking forward to the 16n!
So: the Teensy is flashable without physical access to the reset button. I’ve always managed to flash my 16n without having to reach in and hit that button, for sure.
Also, the whole thing is designed such that the Teensy is hard-soldered to the lower board. I don’t think there’s enough height to plug it into female headers. So it’s always going to be in there, you’re not going to be taking it in and out. Unless, of course, everybody hates that idea.
I had not intended to break out any GPIO pins; I guess I am not using ‘hackable’ in the same extent to which you are. It would be straightforward to offer breakout pads for some of the digital pins - 2-12, as a maximum; the remaining pinouts of the Teensy are pretty heavily used right now:
The plans are the final ‘enclosure’ would only be top and bottom with standoffs; the sides will always be open.
So, I mean, I’m open to suggestions around what’s appropriate re: breakout pins but it feels like there’s only so much I can do. I am trying to keep this project from turning into a lot of work, rather than just a moderate amount. But I am open to suggestions for ‘optional’ pinouts (which I would not even populate with a header, given the open edges; I leave that to the end user).
and sorry, again - not trying to complain or ask for more things, honestly wondered if i’d missed something, and good to know you’ve ever found a need for the reset line.
all i’m trying to do is think through the minimal requirements needed to achieve/allow the maximal number of possible software features without forking the hardware.
in particular, i think its plausible to want to programatically change USB device modes. the user-oriented goal being to offer a way to change the MIDI configuration (or whatever) without installing teensyduino - instead, connecting the teensy as a serial or mass-storage device.