gruv -- An open source Teensy powered groovebox

# gruv -- An open source Teensy powered groovebox Update 2021/5/13: This project is paused and is estimated to start again on February 2022 Update 2022/2/2: After watching tons of OP-1 videos, I'm back on the project. ## What is Gruv Gruv is a project that I have wanted to make quite a while ago, inspired by the Teenage Engineering OP-1. The OP-1 is well engineered and powerful, but it comes with a $1299 price tag, which I can not justify spending as I don't do music at all. But I didn't *just* want to have an OP-1, I just want to come up with an interesting project, a project that can improve my skills, and have fun while learning. After watching OP-1 videos on the Internet, I have come up with an idea, make an OP-1 myself. This project requires basic electronics, PCB designing, SMD soldering, programming and digital audio processing. The OP-1 is so attractive there is quite some existing projects trying to make one. Open sourced ones include the "OTTO" (Pi based), and "[Portable Synth](http://prajtm.scripts.mit.edu/projects/portfolio/portable-synth-concept-design/)" (Teensy based) by Prajwal Tumkur Mahesh. I like Prajwal's project a lot, and I am learning a lot from him. I wish to have more discussions with him. (He seems to stopped its development) ## Project files This project is open source, whether you want to make something similar or just want to see the source code, here is it. https://github.com/jrymk/gruv **gruv-os:** the software development. gruv-os is the software gruv will be running on. ## Project log --- ### Planning - Goals *written on February 13th, 2021* First off, I expect the cost for this project is around $100, at most $150, and no proprietary parts apart from a PCB. Other parts should be able to fabricated yourself with a 3D printer or a laser cutter. Also, I don't live in the United States, I live in Taiwan, so I can order cheap parts from China and just costs 2 US dollars to ship to me in a week. The price and parts availabity may be different than yours. All prices in this log will be converted into USD by default. My expectations are really high, and I don't want the final product to be like an prototype. Moreover, I want my design to be as refined as possible, so I don't need to make too many prototypes, as each prototype will cost around a hundred dollars and I can't afford that. In terms of the actual product, here are the requirements: #### UNDER THE HOOD The brain will be a Teensy 4.1. The codec will be the SGTL5000 found in the Teensy audio board. Although only 16-bit, it is more than enough as I can't engineer a good enough power supply that can have noise level low enough to utilize even the 16th bit. I don't know a lot about this stuff, but this seems to be the case, and the reason why Paul Stoffregen doesn't add 24-bit support to the audio library. #### KEYS The keys need to have velocity sensitivity, and even better with aftertouch. The OP-1 does not have either. For velocity sensing, I might use magnets and hall effect sensor to measure the distance the keys are pressed down. But I still need to find a better way to do this... > ##### UPDATE *(February 14th, 2021)* > ![](https://i.imgur.com/bjoCqLy.png) > Unfortunately, since the key switches and buttons are both 15mm large, there is absolutely no space left for a magnet, or a hall effect sensor on the pcb. If I want to maintain the super compact key layout on the OP-1, this idea might need to go. > > ![](https://i.imgur.com/GJcdNQX.png) > Above is one way to integrate the hall effect velocity sensing system into the switch itself. SMD hall effect sensor(orange) and THT(green) ones can be used. The magnet will be glued on to the bottom of the red core, and the black casing needs to be cut open. > [Teardown image](https://www.youtube.com/watch?v=1P_ucdyi1ms) > > But this solution is not quite robust as I want, it requires opening every switch and it may make it unreliable. Do I really need velocity control?? > > Also, I think aftertouch is *not that important* and all solutions I come up with is not reliable enough, so that will go for sure. > >I wonder what will Prajwal come up for his Portable Synth project... > ##### UPDATE *(February 19th, 2021)* > After a few days, I still can't quite decide on what button design to use. > > ![](https://i.imgur.com/7tQYgT7.png) > > I will try to use those 6 pin cheap push buttons that comes in much smaller sizes. I'm not sure if it is rigid enough to use like this. Also not sure if it will feel good to press, I think even the non self lock type have a tactile feel, like those old PC power buttons that click... > > And for the size, I think the OP-1's buttons' size have a great balance between usability and being compact, so, 15mm is it. Also low-profile mechanical switches are also 15mm wide, so the switches will be packed *real tight*. The Portable Synth project have done a lot of experiments on making the keys. Currently he simply uses mechenical switches that doesn't provide velocity sensitivity. He *is* going to add those functionality and I'm looking forward to see his solution. #### DISPLAY I don't think I will go with an OLED display as bigger displays cost A LOT. I'll try and find a TFT LCD that is high quality and have black blacks. I will try out a 2.8 inch 320\*240 IPS LCD display that has a brightness of 600cd/m^2^. Not sure if it is any good, we'll see. It uses the ST7789V display driver that seems to be similar to the ILI9341, which has great teensy library support. It also comes with capacitive touch panel. The capacitive touch allows panning/zooming, swipe navigation, virtual alphabetical keyboard for typing and touch pad input for pitch bend and other analog controls, but it will not be #### ENCODERS ALPS [EC12D1524403](https://tech.alpsalpine.com/prod/e/html/encoder/incremental/ec12e/ec12d1524403.html) rotary encoder seems good * 5mN･m light detent torque, requires little force to rotate * 30 detent for high resolution fine control * 17.5mm low profile shaft * Cheap ($1.57 on Mouser, $0.35 on Taobao trusted seller) ![](https://i.imgur.com/ofbuI24.png) If the detent torque is too small and the feedback is not enough, [EC11E15244](https://tech.alpsalpine.com/prod/e/html/encoder/incremental/ec11/ec11e15244b2.html) will also do, with a 10mN･m detent torque. ($0.93) Not sure if endless potentiometer will fit, they have no detents, and without feedback navigation and step increment will be horrible, although value entry will be so smooth and precise... maybe replace 2 with these? #### CASE The size of the final product is targeted to be the same as the OP-1 but inevitably thicker. I can't make it CNCed aluminum, but I can make it with hand-cut aluminum sheets and 3D printed frame. --- ### Planning - Software *written on February 2nd, 2022* So... software, I have no idea of how to do this. I am trying not to use the Teensy Audio Library because it seems... limited I'd say. I want to write my own basic audio library from the ground up. I am thinking of making a waveform a mathematical function, to support complex nested synthesis. It will be able to achieve the same effect as those visual mindmappy things. One issue I am concerned is the limited memory and CPU power of Teensy. I am certainly unable to fit 4 two minute tape tracks in memory, although I am thinking of not using the tape workflow OP-1 boasts. With two 8MB PSRAM chips populated, I can get 95 seconds of 16 bit 44100Hz audio tape goodness. That should be enough for some reverb and delay. But the limited CPU power of Teensy means sythesizing all tracks in real-time might be impossible. OP-1 get away with it by unlimited overdubbing over the existing tape, and I can't fit even one tape track of reasonable length. What if I have a more powerful chip that can synthesize a ton of tracks and notes...? Maybe basing on Raspberry Pi makes some sense, but I don't think that is the right fit. I'm lost. --- *editted on February 6th, 2022* I'm thinking about the workflow too. The OP-1 workflow of recording to tape is definitely the least CPU intensive way of getting a rich multi-layered sound. Although unable to change anything after recording kinda sucks. What if the hi-hat I added in the beginning is too loud? To save each track as notes like what most DAWs work is the better way, although it can mean multiple synth engines working at the same time, which may overwhelm the Teensy. Memory is very limited. If I could playback multiple streams from flash memory (not expecting to do so on a SD card), I could save each track as audio instead of notes, so when playback I won't need to do the synth part for each track. Basically one working track which is synthesized in real time, and other tracks are just audio recordings from previous playback. How many tracks can I play simultaneously from flash? I have no idea. If it can't do enough streams I may combine tracks. Every time you change a working track it will do some magic to repartition the tracks. One other solution is pre-synthesize. Which means the user might need to wait a sec to build a big audio buffer. I have no idea how fast a Teensy 4.1 is, and I already got some resets with overclocking the Teensy, so maybe I can't do that? --- ### Coding - Display and Touch Screen *written on February 5th, 2022* My display module (ILI9488, 480\*320) is configured to do parallel mode, which is apparently not ideal for me. Therefore I broke some traces, destroyed some solder pads, and rerouted in MOSI to SDA, MISO to SDO, and clock to D0. And after setting all the interface mode jumpers to do SPI 4 wire mode, it is working great. Bodge job | Everything working :-------------------------:|:-------------------------: ![](https://i.imgur.com/mIurxNU.jpg) | ![](https://i.imgur.com/3O9FaGE.jpg) The touch driver (GT911) is pretty simple, although the library from [blackketter](https://github.com/blackketter/GT911) caused some issues. It is just reading completely off data. [This one](https://github.com/u4mzu4/Arduino_GT911_Library) did work very well. > ***update (February 5th, 2022)*** > Almost rewrote the whole library, because the original version is definitely written by a Chinese. It was quite janky too, no proper config editting, etc. > Spent half a day fixing it up, it is now [here](https://github.com/jrymk/Arduino_GT911_Library), now it is really easy to change configs, and the code structure is more reasonable now. And here is result for today, the capacitive touch paint example project running on my hacked together hardware. ![](https://i.imgur.com/V3ypcMi.jpg) > ***update (February 6th, 2022)*** > SPI is so slow... My display can only go to 4Mhz, which get me around 10fps. I can use frame buffers and DMA, which allows asynchronous display update. The refresh rate is still around 10fps, but now it doesn't block the main loop. > I have a feeling that I will abandon SPI and go for parallel. > [Video](https://photos.app.goo.gl/VFypSgudFttAyspL7) > The one that have the main loop stay at over 100hz is the DMA one, that will use up tons of precious Teensy memory and still have slow refresh rate. The one that stays at 10hz is the blocking one, that shows actually how fast can the display receive full screen data and man that is slow. > > Unless I need more CPU time for audio processing, because no one is trying to do DMA on the Teensy with parallel, and it will also take up a ton of memory. The memory in the Teensy already only allows for a few seconds of 16 bit 44.1kHz audio. Even with a maximum of 2 8MB PSRAM chips installed will only give me around 1.5 minutes of audio, which isn't even enough for 4 track 6 minute tape that OP-1 has (and it is 24 bit 96kHz, although I am not sure if the tapes on the OP-1 are stored on memory). > ***update (February 7th, 2022)*** > So the parallel interface implementation was pretty painless. Can reach about 40fps full screen update with 16 bit bus without overclocking. If this module can accept faster SPI clocks like the good old red PCB 2.4 inch ILI9341s at maybe 80MHz, I could get a bit less than 25fps without spending any significant CPU time. Problem is, I can only push it to around 40MHz reliably. 50MHz the screen already start to flicker and some text are difficult to read, thus I get a maximum of 10Hz refresh rate, unless I use clip rectangles to partial update. > With my new [parallel ILI9488 library](https://github.com/jrymk/ILI9488p)(forked), I can get up to 62Hz full screen updates when overclocked to 1GHz. Although the screen start to have artifacts, I think it will be solved after the bus wires are shorter like in the final product. That also means the display can accept faster signals, which indicates that optimizations to my library *can* further increase performance. The porting process was super easy too, just editted the write and read data bus functions and fix up some weird stuff from the original author, and it just works. > Parallel might never get DMA, because I can't, and people that can probably won't. But I think this speed is good enough. When doing a partial update it takes like a few milliseconds, and even full screen ones take 25 milliseconds. If I don't constantly update the whole screen (like scrolling) I probably won't use up all the CPU time so the audio processing can keep going. But now the problem is, I **do** need to do full screen scrolling... > 16 bit Parallel | A little overclock brings the refresh rate to 52fps > :-------------------------:|:-------------------------: > ![](https://i.imgur.com/TdSaJ6o.jpg) | ![](https://i.imgur.com/b4DdnCl.jpg) [More photos and videos](https://photos.app.goo.gl/XcJ5qneopsj4kWT3A)