nebula

FWIW: the 7-pin "C64-style" jack isn't all that hard to find over here. I got my 7-pin DIN jack from Digi-Key. The one that I got was p/n 275-1021-ND. It's now a non-stock item but it still shows a minimum of 1 piece, so it would be worth phoning them about. They also have a shielded version, part # 275-1026-ND, which should also work great. It's discontinued, 631 still in stock, $1.52 ea USD. Other board-mount 7-pin sockets seem to differ in the spacing of the two front mounting pins. The other variation, with the more closely spaced front pins, are a bit more common, but you could probably just bend them or break them off and still be fine.

My second-last C64 power supply just bought it. Don't forget, if you're using an original Commodore "brick" power supply, do NOT LEAVE IT on a carpet! No air flow underneath = overheating = dead power supply. So ... time to bump this thread ... I still hope to participate in this bulk order!

Personally, for live synth tweaking I prefer pots to encoders. Even pots that jump to the value of their position as soon as you move them. You get a far more tactile feel of what your parameter values are, because the knob has a pointer, and a definite "stop" at the minimum and maximum values. This is also the way the original PG-300 works (its pots are sliders). For sitting down in the studio and programming patches, I prefer encoders to pots, because you can nudge parameter values a bit more intuitively, and you have finer control. Encoders are connected to DIN modules, and pots are connected to AINs. A fully populated AIN (AINx4) module allows 32 pots. A fully populated DIN (DINx4) module accommodates 16 encoders.

Well... with my MB-6582 done (except for a case that won't close due to my long ribbons), I have started the plans for my next project, which is a simple standalone sequencer based on MB808. This is a bit of an experimental design, and it will really come together if I can figure out how to dedicate an encoder to the "rotate" function. I don't need anybody to do it for me or anything, I'm quite keen to try, I am really looking for a go-ahead. To me it sounds easy, but just in case it would be extremely difficult, please tell me now, because I am designing a panel that will use this encoder. Thanks!

Amazing. Thanks TK.

My next mold will have the buttons on top, and I will drill 1/16" holes through inconsequential parts of the mold to get a bit of air to it. I am of course completely prepared to fail, so do you have any ideas where I should get bicomponent silicone? Or is there something I could use as a hardening agent for the silicone I'm using?

Like many here, I like the idea of using rubber buttons for on-the-fly, live programming. Love it or hate it, the Monome has made a splash ... its rubber buttons are ergonomic by virtue of the materials used, rather than its minimalist design. I have an Electribe ER-1 which just feels awesome under the fingers, so I want to build a percussion sequencer using MB-808 firmware and rubber buttons. I have already started on panel layout, and I have some nifty ideas for how I'm going to put this whole thing together, but from what I've seen. making your own rubber buttons is entering into no-man's land. There have been one or two efforts from people here on the forum which have generally been abandoned. So ... here's what I've done so far: I used "GE Silicone II" which is a high-grade bathtub caulking. I chose it only because we use it a lot at my work, and I thought its rubbery consistency would translate nicely to panel buttons. I created a mold by drilling 11/16" holes in a piece of aluminum, about 3/16" thick, then putting a piece of textured, powder-coated steel beneath it, and fastening tightly with metal screws. This left some nice little wells to fill with silicone, which would be shaped like round buttons when extracted. The metal was from the scrap bin at my work. The extracted 11/16" buttons would be just slightly smaller than the 3/4" holes I would later drill in a panel. In order to allow for a button membrane base, I suck a couple of tie-wraps (a.k.a. cable ties / zip ties) down at the edges of the mold with hot glue. This way I could fill up to the top of the tie-wraps and scrape off the excess with a knife. Prior to squirting pouring in the silicone I sprayed the whole thing with "Pam" cooking spray. As I later learned, this stuff does a decent job of preventing the silicone from sticking to the mold - mostly. I allowed the stuff to cure for about a week and a half. As it turned out, this was not long enough for the silicone deeply inside the buttons to harden. When I pulled everything apart, the button tops were still gooey. As a result, the tops of the buttons are pitted and bumpy. But the entire molded piece of five buttons is remarkably sound - I can bend it and manipulate it as much as I like, and the buttons have a solid but pleasant rubbery feel. Since I used the clear silicone, light passes through it pretty well. I will be able to light up each button with two bright LEDs. And I plan to put a 6 mm tactile switch (100 gram force) centred beneath each button. This was my experiment. The next mold I make will be to fit my panel. Of the pictures I took, the ones I'm attaching here are the only ones that make much sense.

^^^ wow this last post was based on that page as it existed last night. Um ... why do we have a top-level "troubleshooting"? We have a forum for that. Answers to how to troubleshoot anything should be in the project-related pages.

I have just had a chance to review the namespace map, shown at: http://www.midibox.org/dokuwiki/doku.php?id=wikify Since I seem to be one of the few against a hierarchal namespace, I will concede that and instead offer some critique from "the other side" :) First: Why, within projects, are we creating separate namespaces for synths, controllers, and sequencers? I don't see any advantage, since we won't end up with duplicate names of projects. When you end up with something like MB-808, is it a synth or a sequencer? Even MIDIbox SID has integral sequencing. And looking to the future, other projects may blur this line more, and still others don't fit in - like a light controller, or a merger, or MIDIO128, etc. Since we don't handle different types of projects differently, I think that sub-classifying the projects within the namespace like that is adding an extra layer we don't need. Second: I think we need an additional top-level classification for misc. We have a lots of documents that don't fit anywhere else. Even though I dislike the FAQ theme, there is an excellent MIDIbox "primer" document whose home is in the Wiki, but doesn't really have a place to go under the new structure. Also, things like Wiki conventions (like the namespace, document templates, etc), forum rules, MIDIbox licence, all belong in the Wiki but I don't see a clear home for them. We have a Wiki page about Eagle right now, which would also need a home. Various documents about basic electronic theory as well.

Would it not be possible to select it on-the-fly by pressing one of the step buttons at the same time? (So you hold down the "external start" button and press step 9, for example, and the sequencer would send a start command when it reaches that step.)

Sweet! Did you get those button matrixes from Sparkfun?

MTE ... you're always at the top of the out-there case designs. Beautiful work. Did you panel-mount the pots, or did you make a new board for your custom layout?

I find that the overall extra work it creates outweighs the practical benefits. Right now if we try to implement a namespace system, all links from ucapps, the forum, and elsewhere on the web get broken. If a person (like me) is an occasional wiki contributor, and decides that the community could be well-served by creating a new page, they will need to familiarize themself with an established namespace convention instead of just writing a document and saving it. Sometimes you see a person in a forum who posts some really great nugget of information, and so you tell them "dude, you should put that in the Wiki". But if you want people to document stuff, you need to give them a clear path to do so, unencumbered by additional rules they must think about prior to sharing information. The WWW itself is inherently flat in structure, but despite the huge number of web pages out there, we can generally get where we need quickly because of good search tools (like Google). The MIDIbox Wiki's search engine makes it possible to find any page you might be looking for within MIDIbox, with no need for a hierarchal system, from a browsing perspective. If we must move to a hierarchal system, it should probably be hierarchal in the same way a user is likely to browse the Wiki, otherwise it doesn't make sense. For example, right now I might go top>projects>user Projects>MB-6582>baseboard parts, and then that page might have a link to the MBHP Bankstick principle, which is already integrated into the board. So if we had namespaces, we would have a link like ../../../../MBHP/modules/bankstick. With a flat namespace (which even works fine for a Wiki as huge as Wikipedia), I could just have just linked to "bankstick" and be done with it. People who are contributing already have their brains full of component values, board layouts, ribbon pinouts, c and assembly code, and excuses for why they don't have time for their girlfriends, so anything that makes this stuff faster is appreciated. The flat Wiki we have (mostly) had so far has been slowly but steadily becoming a better resource, and I can't see how rearranging/renaming all the pages and imposing new rules can do anything to improve that.

My 2 cents: I personally vote against all namespaces. It makes linking a nuisance. If we must use them, then all links should be fixed as we go, and there needs to be a Wiki page, linked from the top page, explaining the namespaces. (This is just my opinion, and anybody is of course welcome, even encouraged, to disagree)

I have a DR-55 that's been waiting for me to do something with it. I'm especially curious what you did with MIDI. Are you able to trigger the sounds with notes? Is it syncing to clocks? Did you use MIDIbox?

That's a great idea Stuart! It would be cool if this was somehow adjustable to something other than a bar. In techno it is sometimes fun to bring in a new rhythm at a different part of the bar (usually 1/8 note, 1/4 note or 1/2 note). That's a really "Detroit" thing to do, and you can expect to hear it from the likes of Derrick May or Jeff Mills. At the right time, it drives a crowd nuts when it's done well. So ... maybe the behaviour of this "sync" button could be configured? Or maybe hold down sync and then press the button for the step you want the "start" message to be sent on.

Very nice, Gobz! I like the look of that, a lot. But I'm already experimenting with molding my own silicone button panel anyway. So far I have had good results. I'll be starting a new thread once I find time to copy the pics from my wife's Macbook. ... until you port it to MIOS 8)

for a 16x4 matrix: 4 button pad 4x4 @ 9.95 ea 16 top bezels @ 3.56 ea 16 bottom bezels @ 3.56 ea 4 breakout pcb @ 9.95 ea ... for a tidy sum of: $193.52 not including LEDs and the bajillion screws you need to fasten the bezels down. I'm really glad somebody other than monome.org is selling this, but I'd like to see lower prices somehow ... maybe they could offer board/pad/bezel kits for a discount? Oh, and maybe sell a proper 4x4 bezel?

Does anybody have a rule of thumb over whether you use tantalum vs aluminum electrolytics? My understanding is that it's generally better to use aluminum across a DC line for filtering, but for most other applications, tantalum is often preferred. I came across this article which discusses the issue some, but I'm curious about how the experienced MIDIboxers practice this: http://www.electro-tech-online.com/general-electronics-chat/26407-electrolytic-caps-vs-tantalum-caps.html

I can attest to this. At work we used some SMT film capacitors (very tight tolerances) for use in a very precise notch filter. We found that, unlike ceramic caps, we finally needed to heed the warning we got during our surface mount soldering training: Surface-mount chip capacitors should not be applied using the same method we usually use for chip resistors. Standard practice for a chip resistor is like this: heat up one of the pads with your iron and put a bit of solder on it. Apply a small drop of flux on top of the hardened solder. Then place the chip with one side on the pad you soldered, so that it is partly immersed in flux. Using your iron, apply heat and allow the solder to bond to the chip. As you pull your iron away, the chip will centre itself correctly over the pad. You can then solder the other side. The problem is that a capacitor can be damaged by this uneven application of heat. We always ignored this warning, because we never had that problem with the ceramic caps we used. But with these film caps, they ended up having a different value after they were soldered, and our filter frequency was going off as a result! The solution: first apply solder to both pads. Regular solder works here, but solder "paste" (a suspension of tiny solder pellets in a thick flux) works better. Unfortunately this paste is dispensed from a special syringe using a metered, compressed-air paste dispenser. If you use regular solder, you must then apply a drop of flux to each pad. Place your chip capacitor, then use the hot-air blower from your ultra-expensive SMT rework station to blow a little jet of air (at about 850 degrees F) over the component until the solder melts and flows over the joints. (The paste really works best for this, because it helps to hold the component in place while the hot air is blown over the capacitor, preventing it from flying off the work surface like a single piece of confetti). The solution works because it ensures the entire capacitor heats up evenly, so the metal layers expand evenly and do not crack.

Why do you guys have problems with alcohol for cleaning a board?

Leave Stryd's little pointer out of this!

I often bathe circuit boards in isopropyl alcohol. Just don't immerse things like trimpots or anything that might be internally lubricated, and you'll be fine.

Are you wanting to send a value (0-127) with your controllers, or just send a cc message with a static value, i.e. to inc/dec something you're connected to? Are you looking to do this with all of the encoders on your 64e, or do you also want some to operate normally?

Why would you want to do this? MIDImon is the application written for the MTC display. Do you want to display something else?