Got it: CV-Outs are not under the control of the Teensy
Got it: CV-Outs are not under the control of the Teensy
ah, yep - that’s right. The outs are ‘raw’, not processed, so you can’t adjust their behaviour in code.
Depends on your definition of ‘mount’. It wouldn’t be pretty. You will probably need to add pulldown resistors as well as the switches, and then your switch is pushing the channel high, and otherwise, it’s pulled down to 0. That would require flying leads and so forth, you’re not just going to snap them into the board. You might also consider adjusting the firmware to replace those channels with note on/off messages rather than 0/127 CC messages, which map to buttons better.
Or: you could take the source files and modify them to make the thing you want. It’s actually a reasonably straightforward modification. But there is a way to bodge it, though it’s ugly and might need a slightly larger enclosure.
Looking at the schematics, I feel that not breaking out some of the unused pins from the Teensy is a bit of a missed opportunity.
A sidecar with an SPI/I2C output expander and some buttons/LEDs/tiny eBay OLEDs would be interesting.
It’s probably easy to bodge the wires on, mind.
…or to modify the PCB design yourself before having them produced
we considered this breakout pins - there was some discussion about what ‘hackable’ means if the pinouts are fixed. We also talked a lot about expanders - the CV functionality at one point was considered an expander - but to paraphrase an old tail about regular expressions, the moment you start bringing up expanders, now you have two problems.
In general, with regards to feature creep, I refer to my post from December 2017. Blimey. This took me a while.
@dewb - that i2c part (IC) is cool. Thanks for sharing!
@rklem - the distance you can run all depends on what your i2c bus looks like (how many instruments are connected and how are they wired). I’ve personally kept my 16n connection to 1.5 feet (0.4572 meters) to be on the safe side. But, I have a lot of instruments connected on my various busses. I would recommend using USB or serial MIDI for long runs at this point.
Wondering how to assign faders to the ER301 via i2c. Is it possible to say have the 16n set as 9-24? I’m running polyES with the ER301 and that’s using ports 1-8.
Also how difficult would it be to move the i2c jack to the side?
I bought some Jarrah laserply to get some panels lasercut. But before sending it away to get lasercut i decided to cut one on my homemade CNC mill to verify sizing. Came up pretty nice despite the unavoidable splintering. This has a bit of guitar fretboard oil applied. Excited for the finished product neatly cut
@cosmicsoundexplorer rather than move the I2C jack to the side it would be quite easy to invert the fader values in firmware and use the unit upside down. Not convinient for the CV outs but might be neater if youre primarily using I2C
There’s not enough room on the top-side of the board - currently, where all components are mounted - without doubling the margin of the board on that side around the faders. However, you might be able to mount it on the underside as it’s a slimline part. I was trying to keep everything to the topside for simplicity’s sake.
So, to do that, you’d need to move the part in EAGLE, and reroute the traces. The latter isn’t too hard - there’s only two, and a quick eyeball says there’s definitely enough room to do it.
dang you all are fast i know there was talk of people building a unit for other members is anyone still up to do that?
There’s a couple threads linked in the top post:
I think @MichiganSynthWorks is building units for people (info in the “world” thread).
I’m using the same configuration and am wondering about this too.
Thank you! This helps a lot.
Brandon, Just wrapping my head around the 16n. Do I understand correctly that if I already have a Teletype with backpack that the TelexB won’t work in my setup? If not, what’s the best way to integrate the 16n into my setup? (Teletype/backpack–>ER301, Telexi,TelexO, Ansible x 2)
IANB but: The keys are short cable runs (to reduce capacitance) and only having one set of pull-ups active on the SDA & SCL lines (multiple would draw too much current). The TT backpack already has pull-ups. Just don’t power the TXb and it will still function as a cable-to-jack adapter for use with the 16n.
Looks like there are unpopulated pull-ups on the 16n itself in case anyone wants to use it in master mode without something like the TXb.
[don’t want to derail this thread too much but since we’re talking about it]
so for the i2c bus to function properly it should have only one power source and one set of pull-up resistors. so what happens with the following 2 scenarios?
teletype with a backpack - do both tt and the backpack provide power in this case? it works but i’m curious why this isn’t considered problematic
if you use a powered i2c board (like the backpack or TXb) but don’t power it, and you use it simply as a multiple to connect to teletype, i assume the fact that it also has pull-ups doesn’t matter since they’re not connected to anything?
re: polyearthsea - will reply in the polyes thread to not derail (quick answer is that i’ll make it work for such scenario)
The issue of multiple pull-ups is that parallel resistors have a lower total resistance. Lower resistance means more idle current draw (maybe overwhelming the MCU I/O current source per pin ratings) and bigger voltage divider (maybe raising your “low” voltage above the needed threshold). I haven’t run the numbers, hence the “maybe”.
The reason for the backpack wasn’t simply to add pull-ups, it was to add more pull-ups to bring the effective resistance down. TT’s were apparently not suitable until the most recent hardware Rev.
Unpowered backpacks or TXb would be fine for simple distribution. You shouldn’t use either one powered up with the new TT hardware.
I’m having problems compiling the code. 1.8.8/1.45 on win10 64bit.
_16n_faderbank_firmware:27: error: expected constructor, destructor, or type conversion before ‘;’ token
Might I also recommend a compiled binary somewhere and the actual library files in the repo for future proofing. There is INVARIABLY some incompatibility issue because of platform, libraries, whatever for someone (usually me for some reason).
Library files in repository: no, that’s a can of worms around licensing and I won’t do that.
I am running 1.8.5/1.40, which is clearly not latest, so am going to upgrade to see if I can reproduce your issues. I’ve also opened an issue on Github.