• Final revisions on the DIY keybed

    T. B. Trzepacz03/30/2017 at 00:20 0 comments

    Even though I have finally found a source for buying keybeds (they keyboard part of the keyboard is called the keybed) for the NanoEgg synth, I still kinda need the previous prototype to work before I start over on the new one, so I still did a bit of work on the keyboard.

    One of the greatest problems was that the stems on the front of the keys that keep the keys lined up straight would break off easily due to the "grain" of 3d prints. Frequently, they would break before they were even done printing!

    This was especially a problem for the black keys, which had no flat side to lay on the 3d printer bed.

    Additionally, because there was no flat side to orient down, there had to be a lot of support material which was hard to get off cleanly, and the "button pusher" plastic on the bottom was frequently not really where I needed it.

    This would frequently cause keys to break off in the process of cutting away the support material.

    I tried many techniques to fix this, from filling in most of the key body, to printing at an angle, to using superglue to reinforce the questionable joints.

    Finally, my brain started working.

    If the grain of the material is causing the stems to break, then I need to print the stems with the grain as a separate part.

    If the button pushers on the bottom are deformed by being on the bottom, then they should be printed as a separate part.

    If the part has too much support material due to not resting flat on the bed, then it should be modified to rest flat on the bed.

    I made the changes. Friction fit stems and button pusher elements, and the key bottom made flush with the bed.

    Still some messy bottom from removing support material on the mounting block, but not so bad there as before.

    The button pushers have a tight friction fit, but can be inserted with pliers.

    The friction fit for the hooks was a little loose, so I used some super glue to keep them tight/

    And, finally, we have a working thing!

  • Hacking the new keybed

    T. B. Trzepacz03/29/2017 at 23:31 0 comments

    I've got a terrible cold this week, so I thought I might catch up with some past updates.

    I FINALLY found a source for minikey sized keybeds at the NAMM show, a company I had attempted to contact through AliBaba before, but never got a response from. It turns out AliBaba shakes them down for money for the contact info, which they didn't want to pay, so I couldn't get through. Next time, look up their company name and go direct!

    So, I bought one of their keybeds as a sample while I was there, and disassembled it quickly when I got home.

    Here it is, intact.

    Note key pitch is again slightly wider and less long than my design.

    It was quickly disassembled...

    Their design uses a separate spring for each key, each key being a separate piece of plastic. The key works as a lever, and has a very thick block to keep it from flying up. Their injection molding setup must be able to handle an overhang, which was a no-no with other places I talked to.

    The keybed I bought as a sample has as an internal connection a flat flex cable, as you do.

    In order to access those pins, I needed a flat flex connector. I didn't want to unsolder the one from the sample. So I ordered them.


    But the connectors have a pin pitch that won't fit in my breadboard.

    So I needed to make an adaptor. Since the pin pitch doesn't fit in standard protoboard, I had to find a way to mount it.
    I determined that the connector pins would fit nicely on the edge of a circuit board.

    I have a bunch of protoboards I got for free from PCBWAY with my last order, but they had contacts in the edges that didn't fit the connector pin pitch either. So, I took it out to the garage and dremeled off the extra copper layers.

    I also cut it down in the band saw. I set it up so that it would straddle the groove in the center of the breadboard.

    Soldering it was kind of a pain, because wires had to go between the connector pins. Trying not to bridge the connections was tricky.

    So now I have it hooked up to the teensy and I can work to determine what the pins mean.

    I used the Arduino keypad library and the incorrect information I got from the manufacturer to finally determine what all of the key buttons were. There are two buttons per key, and the timing difference between button hits determines how fast you pressed the key down. I still have to write a library to handle that timing.

    BTW: I had made some necessary changes to the Arduino keypad library, and submitted them to the owner. My changes exist on the GitHub version, but never made it into the Arduino Playground version for some reason. You can find it here: https://github.com/Nullkraft/Keypad

    The changes are to add the key state to the event listener for keypad events, so if you are doing real-time checking of keys, you can tell if the key was pressed or released without having to search through the internal data structures for the key. I still left the original event listener so that older code would not be messed up, but it would have been nice to just remove that stuff completely and make the internals "private".

    Anyway, having finally decoded the keyboard, I have created this lovely schematic. It is missing the diodes, tho.

    I broke it down by octave and noted each key name. I might have some of the "b" versions of the key reversed... I don't really have a good way to know which is which at this point (no logic analyzer...) but I am sure that will become apparent when I finally write the library.

  • Teensy 3.6 Testing

    T. B. Trzepacz03/05/2017 at 09:14 0 comments

    In the final days at the Supplyframe Design Lab, I got one of the latest Teensy 3.6 microcontrollers to test.
    It is a very nice piece of kit, and with double the speed (more so if you overclock!), 4x the RAM, 4X the flash memory, more I/O, and FLOATING POINT SUPPORT, and mostly code and hardware compatible with our previous Teensy 3.2 efforts, for just $10 over the price of the old one, it seems natural to switch development to the new board. The additional I/O lines alone save me from having to use my MEGSY pin expander board, which almost makes up the additional cost there.
    This is wonderful, but since I did base my previous designs around my own MEGSY expansion board, I can't just drop the 3.6 into the circuit and have it work. I'm going to have to design a new board for the different pin arrangement. And before doing that, I need to test the Teensy 3.6 and make sure that my assumptions on how it is going to work are correct. Can I really use the pins I need for what I want them to do?

    So I'm back at the breadboard, shoving pins in holes.

    The first test was get the screen running. I used PJRC's $12 TFT touch screen, wired up to the same pins as before. Now, on the Teeny 3.2 I had some issues with frame rate. Running flat out on an overclocked 95Mhz Teensy 3.2, a straight screen clear took 56239µs, giving about 17 frames per second. If you are doing a lot of stuff, that even interrupts audio calculation, which is not good.

    So I ran the same test on the Teensy 3.6, overclocked to a blazing 240MHz, and only got it down to 44936µs, or about 22 FPS. That is not nearly the gain I expected.

    So I looked at the ILI9341_t3 library code. It showed an SPICLOCK speed of 30Mhz. I tried raising it up, but it didn't help at all. It turns out that value is just used to calculate a frequency divider off of the CPU clock, which can't be lower than /2, so raising it couldn't make the value any higher.

    Some digging in the PJRC forums found a thread on the topic and so I asked. Kindly Mr. Frank Boesing pointed out that I needed to increase the bus speed using F_BUS. I searched around and finally found that value in "kinetis.h" in the avr/cores/teensy3 directory. Paul was kind enough to put a little note "Uncomment these to try peripheral overclocking. All the usual overclocking caveats apply..." and had two additional speeds for F_BUS available for each processor type.

    Of course, I had no idea which value of F_CPU matched my CPU, but I added some Serial.printf commands to my code to output it and knew exactly where to be (240000000 is correct for the Teensy 3.6).

    So I tried the 80 MHz F_BUS speed first, and my frame rate went up to 29 FPS ( 33711µs per screen draw). A lot of games run at 30 FPS, so that isn't too bad.
    The 120 MHz setting gave 44FPS ( 22492µs ). That still isn't the 60Hz rate that videogames like, but it might be ok for my UI if I am careful.

    Ultimately, I've got processor to spare, but if I am blocking waiting to send SPI data to the video, I'm wasting most of my CPU doing nothing. So I'll probably have to be careful about when and how much I draw. While I was never intending to draw the screen flat-out all-the-time, sometimes, like when turning knobs, it needs to update a part of it fairly quickly. So I'll have to be careful to structure my code to eliminate blocking while waiting for graphics to render and to only update the parts of the screen that need it. Well, my UI needed a rewrite anyway...

    Another nice thing with the Teensy 3.6 is that it actually has enough RAM to store an image of the entire screen, unlike the Teensy 3.2. Frank Boesing is working on a fork of the ILI9341 library that does just that and then uses DMA to send the data to the screen all at once. I will probably end up using at least some of this for my own screen updates.

    There is also another version of the library forked by Kurt E. who added support for different SPI busses on the Teensy 3.6's ARM chip. I don't think I need that capability, but...

    Read more »

  • De-clicking the keybed

    T. B. Trzepacz02/04/2017 at 12:34 0 comments

    So, in the last project video, you could definitely hear the keys clicking when I played it.
    When I looked at other keybeds, I noticed that they used stick-on felt on some surfaces to reduce that sound. I searched around and found sheets of the stuff at JoAnn Fabrics for about $2.50. I'm sure one can do better on price, but it isn't worth the time to find out for the prototype.

    I cut the felt on my paper cutter for nice straight, clean edges.

    Before I took the whole bloody thing apart again, I checked the length against the keyboard.

    I put felt on the bottom of the spacer / keystop lips so that the hooks on the bottom of the keys would not make a noise as they rose.

    And then another strip under the slot where the hooks go, so that they wouldn't make a sound if the hooks actually contacted the bottom wood.

    Finally, I put a felt piece under the keys themselves, which is probably the loudest actual point of contact.

    I'd love to have a video of how quiet it now is here for you, but I found some other problems (middle "C" not working) so the whole thing has been disassembled on my desk again. But, for a brief, shining moment, it was quiet!

    Edit: Ok, I fixed it! All of the keys now work. Still some key noise on key up... evidently the felt I put there wasn't enough?
    Meh. Here is a video.

  • Quick Demo Video

    T. B. Trzepacz02/04/2017 at 12:24 0 comments

    I got the keybed mostly working, so I thought I'd make a little video.

    A lot of stuff is secretly broken in this video. The SD card is not reading, so it can't load the configuration or patch files, which means I'm trapped on the default patch, and none of the knobs do anything. The low "E" key is not working, nor is the high "C" key, although that is because I am using an old PCB from when I was still expecting a 24 key keybed.

    In this video, you can kinda hear the keys clicking as they are slapped down. I have a solution for that in the next project log!

  • Teensy Audio Engine Changes

    T. B. Trzepacz01/30/2017 at 22:16 0 comments

    I had a question from Paul Stoffregen, creator of the Teensy series and most of the other components of this project, and I realized that I never talked about the changes I made to his audio engine. I answered in a comment, but realized it would be a good project log, so here you go!

    Paul Stoffregen wrote:

    I'm curious what you've done with the audio library improvements. Are they published as open source? Anything I should merge back into the library?

    Tim Trzepacz wrote

    Great to hear from you Paul!

    It wasn't so much "improvements" as "bypass most of it". Ultimately, I just needed a way to bang precalculated words as directly to the D/A on the Teensy audio board as possible. After a lot of puzzling about, I found the part that does that and rather messily replaced it with the final stage of my synth engine.

    Since my synth engine is integrated with it, I can't share that part, but I can give the details on what I did.

    The part that I modified was AudioOutputI2S::isr in output_i2s.cpp . I actually made my own version in "buffer_output_i2s.cpp" called "BufferOutputI2S", so as not to disturb the actual library code. Essentially, I made a new component for the Teensy Audio Library.

    I ripped out everything after it sets up "dest" and just dropped my calculation loop right in there, writing the results directly to the buffer at "dest". I skip all of the stuff with blockL, blockR, offsetL, offsetR, "AudioStream::release", etc.
    I end up with a loop that looks like this:

    for( int j=0; j<AUDIO_BLOCK_SAMPLES/2; j++){
        //Calculate all the things
        *dest++=(int16_t) left_channel;
        *dest++=(int16_t) right_channel;

    Originally I did this because I was having some trouble with the libraries that I originally attributed to my code not being fast enough when using the libraries, but later determined was due to an error in how my code was calling the Teensy Audio Library. Still, having done this, I *am* saving a few cycles, so I decided to stick with it.

    I'm still running a lot of the Teensy Audio Library setup just to make sure my stuff gets called, although I'm not sure how much of it I still need.

    The whole thing is going to undergo a pretty heavy rewrite when I move it to Teensy 3.6. I'm planning to make the modulation routings much more flexible, and possibly support output through the built-in D/A either in addition to, or instead of the Teensy audio board. The original version of this was written for the Arduino, and now that I have a lot more power at my disposal, I can re-examine many of my assumptions.

    Thanks for making great hardware for me to work with, Paul! Your efforts have made all of this possible!

  • Test Unit 3

    T. B. Trzepacz12/08/2016 at 21:36 0 comments

    I have been busy and negligent in writing up my progress, but I wanted to show that I did finish the third test box, so here are some glamour shots of it. It looks pretty, but the internals are pretty hacky. Keyboard is still kinda not worky, but I'm making progress when I have time to work on it. I'll be doing more in the new year!

  • Investigating injection molding

    T. B. Trzepacz10/05/2016 at 09:39 0 comments

    During the last month-and-a-half of my residency at the Supplyframe Design Lab, I didn't write many updates to my Hackaday.io page because I was actually working hard on the project and didn't have time for much else. So I am now going back in time and reconstructing events for your edification.

    I always knew that I'd have to find some way to produce the keyboards, but this project is too small to send out to some company for injection molding. Molds seem to be $6-10k each, and I've got at least 10 plastic parts! So, I'm hoping to find a DIY solution. Fortunately, fellow Design Lab resident Bruce Dominguez is working on a project that is almost entirely about injection molding, so perhaps I can ride on his coat tails a bit.

    We had a conference call with a fellow who is knowledgeable about injection molding, and learned some things.

    1. A "small" job is 5000 units.
    2. Mold making is expensive (we knew that)
    3. Aluminum molds are a thing that exists! While tool steel is preferred, aluminum molds can be used for small jobs. And since a "small" job is 5000 units, that seems reasonable for us.
    4. There is a thing called a Morgan Press that is a more affordable injection molding machine. There is an even more affordable one from Medium Machinery. There is even an attachment for the Tormach CNC mill, but that is perpetually out of stock.

    Now, the design lab does have a Tormach CNC milling machine that we could use to make molds, so the idea of DIY injection molding is a distinct possibility!

    There is also the possibility of making molds for resin casting as an alternative. I could make nice prints using the fancy Objet printer in the lab and then make molds from those to resin cast. I have questions about the finish and quality of that type of material, and not really any time to research it, so it will have to wait until I leave the lab.

    After that call, Dan tried to convince the bosses at Supplyframe to get us an injection molding machine for the Design Lab, but it was declined. But my eternal cry is "I know a guy!" and indeed, I knew of two places that had some sort of injection molding machine that was possibly available for our use. One is well known to me, MAGlab in Pomona has had a machine for years that they never had running.

    Also, Hexlab in Northridge has an even bigger, more elaborate machine.

    I brought Bruce over to MAGlab, and we took measurements and rubbings of the holes for attaching material to the MAGlab machine. It turns out that Trent from MAGlab actually used to work at a company running that machine and had a wealth of information for us on injection molding. I'm very optimistic about eventually getting his machine running and making parts on it! Bruce thinks it will take a long time to get it to work.

    So I went to HexLab and talked to Mike about their machine. Well, I tried to.

    What I got, instead of a look at the machine and a tracing of their fixturing, was a detailed analysis of my business plan for the NanoEgg synthesizer, a critique of my production ideas, my pricing, pretty much everything. He suggested to me that I could have everything made in China for far less than I anticipated, and his company would be willing to consult for a very reasonable rate...

    In other words, I got a sales pitch and then got booted out the door with some prices for "further consultation".

    I dunno, didn't sound right to me. If somebody wants my business, I don't pay them for the sales pitch. They can make and present a plan to me with estimates and "not-to-exceed" prices. Maybe he is right on all of the things he said (or maybe not?), but it isn't a very good sales pitch to tell the customer that his product is doomed to fail, unless this is some kind of scare tactic?

    The whole thing made me feel really depressed for a couple of days, but it caused me to think more about my company and what I am trying to do. I know the modern way is to go out, get a whole bunch of venture capital, sell off most of your company...

    Read more »

  • NanoEgg Prototype 2 Box Complete

    T. B. Trzepacz09/15/2016 at 23:46 0 comments

    I've had lots of adventures in constructing the 2nd prototype of the NanoEgg synthesizer box, but I've been too busy working to write them up. I'll be sure to backtrack and cover those later, but for now, here are some glamour shots of the 2nd Prototype!

    Next revision will have straighter keys, I promise!

    Currently has screws sticking out of the bottom. That may change, eventually.

    Side View

    Rear view.

    The rotopod in the back rotates!

    More to come!

  • Keyboard model recovered, more test prints

    T. B. Trzepacz08/20/2016 at 23:15 0 comments

    So, with a lot of help from the kind folks at Autodesk, the keyboard model was finally recovered in a way that allows it to be edited again. Yay!

    More test prints were made.

    We tried a set of keys on Bruce's Make-It Pro. He is a whiz at 3d printing and has his machines impeccably tuned, so those prints came out a bit better than the others. This is hot off the press, so it still has a lot of sprue, but compared to the ones from the Rostock Max V2, it is very clean. This one looks like it is made of spiders!
    After many experiments with using cookies and various jigs to print the black keys in two parts, I decided to print the keys right side up with support material. Here it is used from the bottom to show the support structure that Bruce was able to set up. I think he was using Cura for that, although we did play with Simplify 3d a bit for that.

    Here is an earlier print on the Rostock Max V2, using Matter Control to generate the G-Code. The support material is a lot more solid....
    When the 3d printed objects come off the press, they are very messy, and I have to work at them with a knife to remove all the excess plastic (aka sprue) to make a smooth-ish object.

    Back to the print from Bruce's machine, I accidentally broke a key off in the process of trying to remove the support material, so I had to glue it back together. It turns out that superglue is actually the best thing for PLA plastic!

    The keyboard was designed with small screw holes inside so that the white key and black key parts could just be screwed together. No more messing around with 3d printed cookies...

    The keys from Bruce's printer were a tiny bit shorter than the other printer for no apparent reason.

    I also did some experiments to see if the finish could be improved. With ABS plastic, one can smooth the finish by placing the model in a acetone vapor bath. Acetone is in fingernail polish remover, so is reasonably safe to work with. With PLA, the same thing can be accomplished with Tetrahydrofuran, but since I didn't have any of that, I had a different idea. Since the models are formed by heating plastic to a melting point of about 210 degrees F, I thought that by treating the model with heat, I could melt just the outside a little bit and make it smooth.

    While heating can make it a little bit smooth, it also causes the model to deform quite a bit!

    I had a full keyboard done in the wrong size, so I tried that with the heat treatment. As you can see, the keys bent quite a bit, long before the surface finish had any noticeable change.So, maybe not heat treatment...