I’m looking to make case for a Norns sheild that will let me play with that Norns in a more stand-alone way. I’m taking some inspiration from the qy-70. Can anyone recommend some nice little buttons for use as a small thumb piano sized keyboard? Velocity and pressure sensitivity would be nice to haves but idk if that’s possible.
I think the easiest way to grab a korg nano key or similiar tiny midi keyboard.
KMI nexus has “pressure” or a ROLI is an mpe device
Does Teensy 4.0 have a built in DAC like 3.6? Very new to this and having a hard time deciphering the information on the website?
No, it doesn’t.
They suggest using either an audio shield (for prototyping), or a similar I2S DAC separately for genuine stereo and higher-quality output.
The reason for this, more specifically, is the microcontroller chip itself that a Teensy 4.0 is running doesn’t have a DAC in it. It’s not that they cut anything from the hardware, it’s that the chip never had one to begin with.
Yes, this makes many of the DIY audio projects that have just used the 14-bit DAC on a 3.2 no longer immediately compatible with a bare 4.0.
Thank you very much!
I’ve been prototyping some USB selectable switches/power splitters so I can run my tt keyboard and grids into one unit, and select what modules they go. So 2 usb in, and up to 4 usb out. Kinda like a mega switch.
I was able to get things running pretty easily with a bulky analog solution. I have a DP4T rotary switch that sends the D+ and D- signals out to their selected usb out, and an 2PDT toggle to select between the grid or keyboard usb in and the power being supplied externally via USB.
But the aesthetic definitely doesn’t fit in with the rest of my equipment and a slimmer, digital alternative would be a fun project for me, and likely look better (to my eye). I started to tinker around with some leftover Arduino Nano’s and hobbled together enough to read the analog input from a 10k pot, but there is a ton of jitter. Nothing a little extra code couldn’t help smooth out. But now I’m wondering whats the best way to proceed with this?? I’m definitely out of my element here, but this is what I’m considering moving forward and a few questions I have about design choices.
Goal: two channel selectable input, 4 channel selectable output for usb D- and D+ lines.
- Should I be using a potentiometer, or is an encoder better suited for controlling an Arduino/Teensy?
- My plan was to use a 4052 dual 4-channel multiplexer to route the D- and D+ signals. The logic table being controlled by either a potentiometer or an encoder.
- After tinkering a little tonight with the Arduino, I was able to get the analog pin values fairly smoothed out, but do worry about the possibility of unwanted changes driving the logic table output. The analog pin would read values mapped between 0 and 3, and I could sometimes find the spots where a jump from one value to another would happen unintentionally.
All advice welcome!
I’m really keen to have a go with Teensy, where did you all start? I’m interested in driving a display, but struggling with the basics of knowing what hardware to use. I’d love to drive a couple of these: https://www.mouser.co.uk/ProductDetail/Newhaven-Display/NHD-312-25664UCW2?qs=sGAEpiMZZMshRHSPqbouvOvHakcQfxTK8NYNn%2FEobNn3B1TqCw3COQ%3D%3D
Anyone know of any good tutorials for utilising a separate DAC with the Teensy? I’ve been working off the O_c schematics and firmware to try and get something extremely basic together but it’s perhaps just out of my reach right now.
Let’s think about UI first.
Whilst there are ways to smooth data reads from analog, there will likely always be points “in between” two values, and it doesn’t sound like jittering between two sets of USB inputs is a good thing to be doing. So whilst you could use a library like
ResponsiveAnalogRead to smooth out that input (I like it a lot, beats implementing it by hand all the time), you don’t really address the real problem.
An encoder might make more sense, because it’s a digital input: usually emitting Gray code, you can decode it to basically get “left one click/right one click” type data. But: encoders can be mechanically funky, they’re always harder to work with than you think, and they can still have bounce.
Have you considered something like a pair of up/down toggle buttons? Can be small, means you absolutely, positively, won’t swap inputs unless you want to. You just need one digital pin per input, debounce them, and then maybe use some LEDs as indicators. If you think you’re running out of pins, you’re really not - a LED driver chip or GPIO expander will help here. You might be able to get away with one button for ‘cycle’.
In term of ‘suited’ to controller a microcontroller - there’s not really an answer. You need analog inputs for a pot (which most MCUs do), wheras an encoder is digital. I think the question really is: are you asking it to do an analog thing? And I don’t think you are, so I’m not sure the pot is a good idea. Really, you’re doing digital switching, so some kind of digital input - be it a button or encoder - is probably the right answer. I’d lean towards buttons, frankly.
Regarding the rest of the pile: something like a 4052 is a smart idea. However, it’s a fairly old (CMOS) part, and you might want to test it behaves itself with USB data if you haven’t already. It looks like it should work from what I can make out on the datasheet, but I’m not an expert there, and I don’t know if it’ll interfere with the USB data in any way).
Does that help?
(I’d also note there’s a way of doing this pretty much without an MCU, involving a handful of CMOS parts (counters, mainly) and doing analog switch debouncing).
Yes, thanks @infovore, this was super helpful!
I’ve considered toggle buttons for exactly what you are describing. But I like to make things hard on myself, for the sake of design. At least, design that’s pleasing to me
But just to make sure we’re both talking about the same thing, I am only considering an encoder for the 4 possible outputs. I wasn’t sure if that’s what you were getting at when you mentioned “won’t swap inputs” in reference to the toggle buttons.
Either way, both intuitively and mechanically, I like the idea of choosing output location by rotary selection. And as I’ve had some time to think and tinker with it, I do feel like it’s really doable with an encoder (by ensuring the encoder turns “x” amount in one direction before we start doing stuff). I’ve been practicing some basic forms of this with the vast pile of potentiometers I have sitting in my basement, and have made some headway.
I do plan on changing my design from a toggle switch to two push buttons for input selection. This seems like an easy task for the Arduino, and something basic that will provide more learning/problem solving opportunities.
As for the 4052, I’ve got my fingers crossed there’ll be no issues with the USB data lines. I do plan on getting an order in soon (also for the rest of my Fates build I’ve been putting off) and will find out, but I’m starting to wonder if I actually need one, as you’ve mentioned earlier. This project would require 4 input pins for the two USB sources, and 8 output pins for the 4 USB outs. Some pins for the encoder and the buttons. All that could be handled with a GPIO expander?
Makes sense. And yes, with an encoder, you could, say, require a “significant” number of steps to swap the input. See what feels best to you. There are Completely Fine™ encoder libraries out there, and I would recommend just using one of them.
ah, no, sorry, you’ll still need the 4052-or-similar: a GPIO expander just gives your microcontroller more pins. You still need the switches to run the USB data through. So: your 4052 will take two inputs and mux them each to four outputs. You’ll need four pins from the MCU to control the 4052, then two for the encoder, one for each LED you want to use (because how else will you know which input/output is selected?), plus one for each button. I think you should still be fine with pincount on a Teensy 3.x, though!