Faderbank Run: See top post for status

[shellfritsch]

finally had a moment to patch up the analog outs and record something. no i2c or midi in this one.

Control Details:

Red= 4 channel scale quantizer via Teletype + TXi
Blue= ER-301 delays and backwards tape deck
White= Just Friends (synth mode)
Orange = 3 Sisters and spring reverb send

Just Friends / Just Type is the only voice.
Meadowphysics pings Teletype. Manual gate for transposition.

[scanner_darkly]

wait a second… so in theory, you could use faderbank as a MIDI output for teletype, right?

[bpcmusic]

yup. yes, one could. it is a rather large teletype to midi converter, but it could.

[joshhh]

backwards tape deck

do you mean a tape deck unit within ER-301, or analog? It sounds great either way!

[scanner_darkly]

ha, yes
but as an expansion this could be really useful. sequence MIDI from teletype (say, using a grid scene), use faders for CCs.

[jlmitch5]

I’m just now realizing that y’all are doing i2c over TRS with the 16n/TXb. Just wanted to mention I think that’s great idea!

I’m thinking it should be pretty straight forward to solder up something to interface between one of the jacks on the back of my Intellijel 7u case to the 3 pin connector like came with the TXi/TXo.

[unity2k]

@Kel weren’t you just asking over on O|D if this was possible? Scroll up six entries.

[infovore]

this makes me think, perhaps it’d be useful to add TT ops to configure the MIDI output. can be super simple, like assigning CC to a fader, or more complex where you could, for instance, configure it to work as LFO with faders controlling rate etc (i’m thinking of endorphines shuttle control here but with the ability to configure it with TT).

maybe even the ability to store such configurations as presets and then have a separate op that selects a preset.

Can I just put a ‘hold on a sec’ request in here? I know @bpcmusic has responded in the affirmative but I want to understand a few things.

So: firstly, I’d like to understand the use case; I don’t own a teletype so can’t see why I’d want to swap MIDI routings from it.

Secondly: one of the goals, for me, of the 16n is that it’s reasonably simple and reasonably hackable. Currently, if you want to change the CC assignments from 32-48, you open up the code in Teensyduino (ie the Arduino software), change some numbers that are near the top of the code, and re-flash it over USB. If you can install software and have a USB port, you can do this.

However; moving midi config into EEPROM, making it accessible over I2C, might make it harder to do this ‘simple’ code alteration. The I2C code has already necessarily made the firmware much more complex than the straightforward MIDI-only versions.

And whilst MIDI and dumb CV are not the new hotness, they are very widespread and common use cases. There are a lot of MIDI objects in the world. There are not many Teletypes, and of the Teletypes in the world, fewer Teletypes belonging to people who’d want to swap MIDI patches on a 16n via them.

16n spits out MIDI, voltage, and I2C. I’d like to treat each of those outputs formats fairly, and commensurately with the audience for them (with a slight skew towards I2C because it is genuinely handy). I just don’t want to make the object too fiddly to adjust, alter, or modify, for the sake of some niche features.

Thirdly: worth noting that the assignments for USB-MIDI and TRS-MIDI are separate (and don’t have to be the same); something not caught in your example.

Fourthly: sorry for being grumpyguts. I’m not linking to the image of The Homer again.

[rdfm]

I don’t have too much to refute your argument, but as a teletype user, the chance of getting to use this as a tele configurable/ tele 2 midi translator is so exciting. It would make integrating not euro stuff into euro centric jams soooo much easier. Just my 2c though. Still an exciting project nonetheless

[scanner_darkly]

all very valid concerns, and something i should’ve addressed in my post. any additional functionality should be done in a way that does not take away from the simplicity and straight forward operation as intended originally.

in use that would mean that it could simply always use the same default CC mapping when turned on, and then you could change it with TT commands if needed, meaning the additional functionality wouldn’t change how it normally operates.

now, for firmware it’s a bit more complicated. if we want to keep the firmware as simple as possible so that it’s easier for folks to modify it then this could be a separate firmware version (it’s still going to be simple, so there is no much overhead in maintaining separate versions in this case).

use case: one case would be where i have 2 different teletype scenes for 2 different tracks. these 2 scenes are used with 2 different midi devices, say octatrack and blofeld. it would be much easier to switch between these scenes if i did not have to reflash the faderbank firmware just to change MIDI CCs.

just being able to quickly and dynamically change MIDI assignments i think would be very useful.

worth noting that the assignments for USB-MIDI and TRS-MIDI

ah haven’t thought of that, but that makes adding TT MIDI control even more useful.

Just my 2c though

you mean i2c?

[zebra]

just seconding the “hold on a sec” w/r/t firmware.

FFS, it’s a teensy. it’s very easy to roll your own stuff for it. last time i used a teensy for something, i rolled a little command/config language in ragel, for routings and settings, and this took about an hour. another hour to make the config persistent in eeprom.

so these requests are not hard, but they are pretty niche. base firmware should be standard stuff and go from there for niche requirements.

(FWIW, i do think that having persistent configs for like, CC assignments, and a little language to write them w/o the arduino IDE, is worth the minimal effort. i can’t share proprietary work but when the thing gets closer, i’ll see if i can get some OSS bits out there. that use case doesn’t involve TT. more like, plugin USB cable, open terminal/screen, type set cc [1 2 3 4]; save;)

my first task with the 16n will be making it talk monome-serial format. my second priority will be HID. my third will be i2c. i don’t expect anyone else to want these things and that’s totally fine.

• another grumpyguts

[scanner_darkly]

the thing with teletype use case is, it’s already connected. all you have to do is type a simple command. which also means it can be changed by scripts themselves, dynamically, if needed. have 2 pages of CCs and switch between them with monome walk, for instance.

endorphines shuttle control allows you to change assignments from a browser (and from ipad too, i think). it’s super simple, but i still find it fiddly enough right now (as i don’t have it connected to desktop) that i just store various configurations as presets and switch between them instead.

but yeah, totally valid concerns, let’s keep it simple.

[zebra]

its occuring to me that there is a whole topic of “what all can you do with a teensy and faders on it”, which is certainly fun to think about, but such considerations in this thread (“interest check”) are a little confusing and maybe stressful for the principal parties.

like, i would do certain things with that (persistent config without teensyduino is kinda important) but that’s not a promise to include such features in any kinda “official” firmware.

so i dunno, maybe a second/third thread would keep things feeling nicer? eh.

---

ok, a real question that i think is on topic:

maybe i don’t see the most current eagle files. but on those i do see, there are no breakouts for any GPIO at all even the reset button.

it seems like for something to be “hackable” that’s kinda a necessity. like to have a pin to put in “config” mode or any other kind of “special” mode (you don’t have any buttons to use for a key combo.) don’t you need the reset pin at least to flash firmware with teensyduino? is the idea to take it out of the enclosure to do that? or that any fully enclosed mounting will involve DIY breakouts?

[shellfritsch]

do you mean a tape deck unit within ER-301

in the 301. continuously recording to a buffer that is being played in reverse, with varispeed control. so fun!

[scanner_darkly]

but that’s not a promise to include such features in any kinda “official” firmware.

so i dunno, maybe a second/third thread would keep things feeling nicer? eh.

fair point, i edited my post.

[bpcmusic]

First, a clarification. I maintain a list of feature requests for things I’m working on. When I said:

Consider it now on the list.

what I meant was:

“I have registered your request and will add it to my running list of feature requests. While this doesn’t guarantee that any particular feature will be done by me (or anyone else), it does ensure that it will not be forgotten and perhaps considered at some point in the near future. Now, if you really need this enhancement, the good news is that it is open source and MIT licensed so there is nothing stopping you from forking the repo and hacking away.”

Hard to be verbose when you are sneaking onto lines in the middle of a meeting. (I’m sure I’m the only one who has ever done that.)

Since I’m did the most recent productionization of the firmware (major refactor of the original code, i2c support, Teletype integration, and general commenting - though @infovore did the initial read.me file), I think it might be helpful for the overall conversation to level set everyone on the firmware’s current state. (I also agree with @zebra. Perhaps we could move the “fun possibilities” discussion to another thread?)

16n Firmware Current State

MIDI:

• MIDI Output over USB and Serial
• MIDI Channel set in firmware; defaults to 1
• MIDI Controller Numbers set in firmware; defaults to 32-48
• MIDI Controller Numbers can be Different for USB and Serial; defaults to identical

Firmware Compiled with the “MASTER” Define Commented Out Supports Teletype:

• Teletype Firmware Beta 2.3 speaks to the 16n using the operator FADER n (alias FB n) to read the position of fader n; range 0-16383
• Framework in Place for Additional Operators; none currently supported
• Teletype 2.3 BETA required

Firmware Compiled with the “MASTER” Define Enabled Runs the 16n in Master Mode (which does not respond to the Teletype):

• 16n Will Broadcast i2c Commands to Ansible, the TXo, and ER-301 Simultaneously
• 16n Sends 16 CV Values to up to Four TELEXo Expanders (TXo); the 16n’s faders are mapped across the 4 TXo’s CV outputs (4 ea.)
• 16n Sends 16 CV Values to up to Four Ansible Modules in Teletype Mode; the 16n’s faders are mapped across the 4 Ansible’s CV outputs (4 ea.)
• 16n Sends 16 CV Values to an ER-301 Running at Address 0xB0; the 16n’s faders are sent to the first 16 CV inputs (out of the ER-301’s 100 virtual inputs)

Compiling and Hacking

The 16n firmware is edited in the Arduino IDE and sent to the Teensy over USB via the Teensy Loader. It was kept fairly simple and is thoroughly commented to enable simple modification and hacking. We will also provide pre-compiled builds of the latest main branch to make it as trivial as possible to drop the official firmware onto the device.

---

Hopefully this is helpful in understanding the firmware’s current state.

[jlmitch5]

Firmware Compiled with the “MASTER” Define Enabled Runs the 16n in Master Mode (which does not respond to the Teletype):

I feel like this has been talked about in a few different places on lines, but I’m a little lost. If you compile the firmware this way, can you still have Teletype take control of the other modules? In other words “multi-master”

For example, it’d be useful to have 16n default to sending cv out of TXo, but make the TXo outs do other things with a teletype command that targets them. That being said, this isn’t the most important use case, as the 16n has CV outs for the faders built in.

[bpcmusic]

“multi-master”

I’ve had things running on the bus at the same time, but at this juncture the Teletype will hang at some point if it is also doing i2c things. It lasts longer if you aren’t addressing the same devices, but I can still get it to lock up in that situation. Haven’t done any investigation beyond that.

[ermina]

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 ?

edit: nevermind, i saw the same question answered on O|D forum. (the answer being, it would sort of work but might lock up).

[CryptocrustB]

Holy cripes. Just registered to register my interest in the faderbank and txb module. Exactly what I’m looking for to pair with ER301. Would prefer built, could deal with a kit.