Jidis

Snaper, The standard connection is just regular MIDI, so as long as you've got some form of MIDI interface on your machine (USB or old 8-pin serial), you're OK. This is also assuming that you're running an audio program or sequencer which will let you map incoming MIDI to the onscreen controls,etc. I'm pretty sure most everything does these days. Take Care, George

John, I'm the same way with 9 (since I can't run 7.6 ;D). My G4 never went to X, even though it came with it, and if it's doing audio at all now, it's got a Core2 card which can't do X. Take Care, George PS Adam- they had a thread recently in the MOTU forums about the cessation of MIDI support in Java. Couldn't help but wonder if that was something which would affect you (us) in some way??

One suggestion I've read was to mix it into some powder (concrete mix, I believe), so you get a nice solid rock which can be thrown in with the regular trash (I hope). George

I thought the same thing. Funny, because that "rounding up the components" task is probably the easy part for many. I went and looked at the SSL clone, then found that people were selling bundles of the chips on eBay for 20 bucks or so. I've got no problem etching some boards, and have a nice pile of copper here, but compiling a DigiKey order terrifies me. It'd be nice to just grab a Ziploc bag full of junk from one of them. ;D Stryd- Are you really dead set against plugs? I've moved just about every process I need now to stuff in the UAD bundle. Every time I start thinking about modding something here, or looking at DIY analog projects, I get to wondering where I honestly need them, whether I've already got something similar on the UAD cards, and whether it would be worth the loss of multiple instances, instant patching, automation, instant recall and everything else. Needless to say, the racks will start looking a little lonely, but you can always make "fake hardware" to run the UAD plugs with MIDIbox guts: (that was for the Neve 1073 they put out a little while ago) Their Precision Limiter is really nice. ( http://www.uaudio.com/products/software/UAD/limiter/index.html ) It stays on the last stage slot of my mains in Nuendo during exports. It's pretty open and clear sounding and takes a lot of reduction to get crunchy or anything (maybe not good for tape distortion though). I've only briefly used the Waves ones (over used more likely), but I do remember them being easier to "hear". Universal also just brought out the Neve 33609 bus comp, and they already had the Fairchild, the LA-2A, 1176LN and everything else. (starting to sound like a Sweetwater salesman here) Take Care, George PS- (back to Sweetwater mode) I'm really liking some of the fuzz I can get from their Space Echo emu too. If used just for the distortion, with too much input gain, it can add sort of an "exciter like" sound.

In my case it's just with regular toner transfers (no blue stuff here right now). I get bubble problems and lifting,etc. during the cooling process, after the transfer. Not sure if relief cuts or holes would change that much, but it couldn't hurt. George

I also couldn't help but notice the name was a bit "casual" about rinsing the ferric chloride soaked enclosure in his sink. ;D I've stained many things with etchant which should've been weak and diluted enough not to do anything. Still have a nice line down a stainless steel sink at my aunt's house from a droplet of "mostly water". Thanks too for the links. I had read that tip on cutting air relief holes in prints before, but had forgotten about it. I'll remember that on my next transfer. Bubbles are something I've always had trouble with. So is sanded "slush" from the spray paint,etc. all that guy puts in the etched areas? I like that look. I've been into aluminum with black text lately, but am doing the toner directly to the metal and leaving it on. I'd like to see how clean a print I can get with the etched method. BTW- Unfortunately, it looks like that nice muriatic acid post was one of the casualties of Friday the 13th. :'( I had to etch with some again the other night and went looking for it. Can't find a local copy either, but could've sworn I saved it. Take Care, George

Good to hear. :D Doesn't heat up now that the opto's in right, does it? I use 2x40's a lot here, and it seems anything with longer lines, running an app which just supports the 16 width, usually just aligns each row to the left edge (with a bunch of wasted space on the right), unless you change the offsets. I haven't seen any other weirdness, but they're all 44780 compatibles with pretty standard pinning. George

HL-SDK, It sounds like a soldering or construction fault somewhere, from the heat description. I had an issue like that long ago. I'd double check everything before something bites it. Also don't go too high with the input voltage. Maybe someone else will chime in on the suggested range, but IIRC, it was closer to the desired 5V than I used to think (maybe 6-8or9V on input). You don't want the regulator to have to drop it by too much. The black bars may still be OK if it hasn't gotten a solid MIOS dump in it yet. Also sounds like it's putting off the request properly. I guess it's a matter of preference, but I'm quite partial to MIOSStudio for dumps (and everything else). I'm ashamed to admit, but I hadn't even bothered to pull the input monitor down until not too long ago. I used to bounce over to MIDI Ox for a bunch of stuff. Get MS back up and running if you can. Ox has given me much more trouble. Take Care, George --- Almost forgot http://www.midibox.org/mios_studio/MIOSStudio_beta7_4.jar Meeshka has announcement posts with release notes,etc. in the "MIDIbox Tools & MIOS Studio" forum here, so keep an eye on that. Also make sure you've got the Java bundle that it needs installed.

That's funny, "Skunk", in this other thread http://www.midibox.org/forum/index.php?topic=4366.0 says a design pointed to at http://www.mawzer.com/ was I guess he's partly responsible for that recent one. ;D

-Yes, one here. ;) Who's knobs are those? From the picture, they sort of look like those of the notorious Alesis 3630 compressor (some of my all time favorite black knobs). I wanted some a while back and they would only sell me a few, but I figure there must be a source somewhere other than Alesis. ??? -- Beautiful SID, BTW! George

Steve, The 6N138 schematic you're talking about, looks just like an "official" one I'm looking at here from the MBHP Core, so I guess you're good to go, as far as that's concerned. :) I got hard up for an optocouple here myself a few weeks ago, and fought with a 6N136 or something, which never managed to work. There was a thread or two about using that here, where a pin was disconnected and a resistor value was changed, but it didn't work anyway. I think my 136(?) had already been sent to the next world. What I ended up with was a PC900 in "dead bug" mode (upside-down with jumpers wrapped around it). The PC900 re-mapping I have written down here was: 138 900 2 - 1 3 - 2 5 - 5 6 - 4 8 - 6 Your PC900 picture looks about the same. The only difference I see in mine here is that mine looks like there's a 5.6k resistance pulling up that fourth pin to the PIC (where yours has a 220). I don't know where my 5.6 came from. It's probably from the thread about using a 136. Either way, it sends and receives dumps OK, but that's about as close as it's gotten to being "tested". Take Care, George PS- I realize your question is about switching to the 138 circuit, so yes (to me) the re-mapping of the pins looks right, as do the resistor values (judging by this core schematic). If anything else acts funky, make sure you check the connections to pins 4&5 of your DIN socket or whatever. I've accidentally reversed those two on stuff more times than I can remember here. :o

That's what I'm guessing my gripes are with the buttons on my Alesis. When it was new, they weren't nearly that bad, and they've barely been used (or abused). Now, it's like you have to "peck" at them really hard with the tips of your fingers to get an accurate trigger. If anyone has any good tips (or threads/links) on cleaning or protecting that sort of switch, I've been planning to take it apart and see if it gets any better. Thanks!

I've been wondering that as well, but I have no idea what these particular ones feel like. ??? Has anyone here played on a Monome,etc.? I know there are "good" rubber membrane switches and bad ones, but for any performance type use or drum/sequencer input, it would seem pretty important. Take Care, George PS- My Alesis SR16 buttons get me so frustrated sometimes I feel like playing it with a hammer. ;D

Hi Timboroni, Yes, they're no different than any of the boxes you see with pots/knobs (not the encoders & LED rings). You just need 10k linear taper faders of whatever length you can find. Only PITA is that, like with the pots, your control's pointers or fader positions may not always be in sync with the pot/fader status in whatever you're controlling. You'll have to use stuff like "snap mode" and go around and manually set the faders when you open a session,etc. I'm wondering if anyone has done a "fader/knob set" mode, with LEDs or anything. Like on a JL Cooper fader unit I have here, if you hold down a shift key, and move a fader which isn't currently at the same value as the DAW program, you have two arrows with LEDs in them which will light to show you which way you need to turn the control to get everything to match up. This way, when you load a session, you can sit there for a minute and line up all your faders without actually sending any outgoing control changes. Take Care, George

Man, wasn't expecting that. :o Sounds awesome. Like a hardware MIDI/SysEx editor? I look forward to reading about it. Hope everything turns out perfect, George

Good to hear! :) Maybe someone else could figure out what the cause of the conflict was on the input monitor for you, but it sounds like you're OK with the LTC anyway. It would be neat to see what your app is (and what it does) when you're done. I'm still fighting with a "baby app" in MIOS/assembler per Thorsten's suggestion. I'm trying to get MIDI i/o with basic buttons and LEDs for audio mixer stuff, but starting from scratch, with no MB64 app or anything, leaves a lot to be done. :'( George

Christian, Read the reply on the way out but didn't have time to mess with it, so I tried at the studio and brought back an edited main.asm with the Rx/Tx lights working (I usually have them shut off in stuff I'm running). Unfortunately, I've gotten comfortable with asm and still have trouble with lots of areas, so I'd rather get that straight before trying to move into C. Therefore, I don't know much about the combination when working with MIOS apps, but it sounds like you can use a little of each (?), so maybe these pieces of code can point you to some stuff you need. This is all from the regular v1.9 assembler skeleton. There was only one minor addition outside the main file, and that was for the two (Rx/Tx) counters it uses. You'll add that in the app_defines.h file. My test file was blank "variable-wise", so it just went to the first couple free spots. MIDI_RXTX_RX_CTR EQU 0x010 MIDI_RXTX_TX_CTR EQU 0x011 Next is the main. These are edited pastes from the MB64 files. It actually uses some stuff from the midi_rxtx.inc file, but I stuck the stuff directly into the places where it gets called, to keep it in one spot for clarity. Thorsten has all of the calls commented pretty well, so you should be able to see what it used to do by looking in the original MB64 files. Sorry to have hacked it up like that, but I thought it might make it easier to see what was needed for just a blank skeleton with Rx/Tx lights. These MB64 copy/pastes are also missing some conditional stuff and have some variables replaced with their actual data (in this particular app). The MB64 has lots of ways different people can set it up, and needs to act accordingly, but these edits assume that you want MIDI monitor lights, and that you'll be using the first two DOUT pins for them. I'll just paste the functions from main where I actually inserted anything: USER_Init ;; define number of shift registers: for 128 IOs, we need ;; 16 registers. Btw.: thats the maximum number of supported DIN/DOUTs movlw 3 ; I happened to only be using 3 SR's (24 buttons/lights) call MIOS_SRIO_NumberSet ;; define the update frequency (latency) of DIN/DOUTs in mS movlw 1 ; ms call MIOS_SRIO_UpdateFrqSet return ;;------------------------------------------------------------------------------ USER_MIDI_NotifyTx movlw 15 ; there was a MIDI_RXTX_LED_DELAY variable here (#defined as 15ms) SET_BSR MIDI_RXTX_TX_CTR movwf MIDI_RXTX_TX_CTR, BANKED return ;;------------------------------------------------------------------------------ USER_MIDI_NotifyRx movlw 15 ; LED "on time" delay -same as above SET_BSR MIDI_RXTX_RX_CTR movwf MIDI_RXTX_RX_CTR, BANKED return Alright, then here's a piece of my junk (not edited from MB64 source). It just spits out a C note on/off when the buttons get hit (so there will be some actual MIDI going out). Also goes in the main.asm: USER_DIN_NotifyToggle ;; first it checks to see whether the toggle was pushed or unpushed ;; (button state is in MIOS_PARAMETER2) IFCLR MIOS_PARAMETER2, 0, goto ON OFF call MIOS_MIDI_BeginStream movlw 0x80 call MIOS_MIDI_TxBufferPut movlw 0x3C call MIOS_MIDI_TxBufferPut movlw 0x7F call MIOS_MIDI_TxBufferPut call MIOS_MIDI_EndStream return ON call MIOS_MIDI_BeginStream movlw 0x90 call MIOS_MIDI_TxBufferPut movlw 0x3C call MIOS_MIDI_TxBufferPut movlw 0x7F call MIOS_MIDI_TxBufferPut call MIOS_MIDI_EndStream return Last paste into main is this. This one is where the two actual DOUT numbers (0x00 and 0x01) replaced the MIDI_RXTX_RX_LED and MIDI_RXTX_TX_LED stuff: USER_SR_Service_Prepare ;; Decrement Rx counter if != 0 SET_BSR MIDI_RXTX_RX_CTR movf MIDI_RXTX_RX_CTR, W, BANKED skpz decf MIDI_RXTX_RX_CTR, F, BANKED ;; Decrement Tx counter if != 0 SET_BSR MIDI_RXTX_TX_CTR movf MIDI_RXTX_TX_CTR, W, BANKED skpz decf MIDI_RXTX_TX_CTR, F, BANKED ;; ;; remove the code below if you don't want to use LEDs to ;; indicate the counter state ;; ;; set the Rx LED depending on counter state SET_BSR MIDI_RXTX_RX_CTR movf MIDI_RXTX_RX_CTR, W, BANKED skpz movlw 0x01 movwf MIOS_PARAMETER1 movlw 0x00 ;my dout pin for MIDI receive call MIOS_DOUT_PinSet ;; set the Tx LED depending on counter state SET_BSR MIDI_RXTX_TX_CTR movf MIDI_RXTX_TX_CTR, W, BANKED skpz movlw 0x01 movwf MIOS_PARAMETER1 movlw 0x01 ;my dout pin for MIDI transmit call MIOS_DOUT_PinSet return I hope some of that can help you figure out what may have been missing (and that you can use actual asm code in your skeleton 8) ). It dumped and worked OK at the studio, and on another box here. Take Care, George

Christian, I think those MIDI i/o light prefs are all in the main.asm file (at least with the MB64 apps I'm always messing with). If you're not running that, you may be able to paste the necessary lines from the MB64 batch into what you're doing. Just make sure you fish around for any source lines which go with them and import those too. Thorsten or someone could probably specify what parts are required, but maybe you're working with an app which already has it all. Hope you get it going, George PS- From MB64 main, in the defines area near the top of the file: ; For MIDI activity monitor: define the DOUT pins for the Rx and Tx LED #define DEFAULT_MIDI_MONITOR_ENABLED 0 ; if 1, the Tx/Rx LEDs are enabled #define DEFAULT_MIDI_RX_LED 0x40 ; DOUT SR#9, pin D0 #define DEFAULT_MIDI_TX_LED 0x41 ; DOUT SR#9, pin D1 - Here, you'd just be switching the "DEFAULT_MIDI_MONITOR_ENABLED" to enabled (change 0 to 1), then changing those hex numbers (0x40,0x41) to whatever numbers your lights are connected to. * Obviously, make sure you recompile afterward, so you're not just sending the same old hex dump (do that on many occasions myself ;D). BTW- Windows calculator (if you're on a Windows PC) will do hex (0x) to decimal conversion if you put it in "scientific" mode. (above, you're looking at numbers 64 & 65, if you didn't already know --and they start at 0)

As weird as it sounds, it also helps sometimes to actually resolder a particularly troublesome pin. I found that tip on the web or usenet a while back, and it's worked well on many occasions. On joints where you've managed to get most of the solder out, but there's a bunch around the inside edges of the hole, it merges into the old stuff and then the pump or bulb can make one big clean suck to get it all out. BTW- I like that spring loaded pump tool with the latching button much better than the bulbs I've got, but they all get clogged too quickly. >:( Take Care PS- I "torched" a board with propane once, after reading about it. Nothing dropped out. The board just turned crispy and black with all the components still seated. :o

Man, he does have some cool stuff! :o He's also got Chickenheads and a 40mm aluminum (jog/shuttle?). Check the lighted toggle too (light in the tip): http://tinyurl.com/zqbea No spring loader though Stryd. :'( George

Damn, they've got Moxi and Pilo and everybody in that place. :o Makes you feel left out. ;) jOi- From what I remember, Moxi wasn't happy with the material on his flexible attempts. Mine went the same way with some very brief tests with liquid latex. I liked the latex over fiberglass and other substrates, but not on it's own. Many of the remotes here are now using a hazy white/clear rubber button sheet with a surface mount LED or something behind it. It looks good (I'm sure you've already seen a bunch). It looks about like Moxi's hard buttons with the lights. The material feels about the same as a glob of dried silicone. I'm wondering if you mixed some white and clear (or even just the clear) with the proper solvent, if you could cut it down to something which could be poured?? - I'm sure there's a liquid form of the same stuff here, but the regular "tube" style is all over everywhere. Take Care, George

That is a cool as s*** idea. ;) Maybe someone here could work out a way, but it does seem that since the DOUT register's output pins are just an on/off (all or nothing) state, it would have to happen at the current limiting resistor stage, so it would probably involve additional circuitry as well as software (if it were under digital control). Maybe there's a way a stacked (stereo) pot could do that, with one whole side dedicated to the LED's resistance, and one to the regular AIN feed. Good idea nonetheless, George

Yeah, I didn't mean to knock them like that. 8) I had my box with those at the studio with me tonight and mapped them to a VSTi drum module just out of curiosity. They weren't that bad at all, but I could get some false triggers if I held them in and "wiggled". Keep in mind, mine are also surrounded by "nothing". I don't think they were meant to be installed like that anyway. ;D I bet those lit ones look cool as s***! (for mute/solo/rec especially). You've got me wanting some. Take Care George PS- Mute/solo duty is the same thing the ones in the picture were set up for (thus the yellow&red LEDs).

I think I've got a bunch of them on something here. Mine must be the KS01-A, if that's the "unlit" one (bought an unmarked bag). The one you're looking at should be fine. Looks like they've just got two LED connections stuck between the 4 regular pins for the switch. FWIW- Those aren't some of my favorites in the "feel" department, but they're not the worst I've ever had. They've got a sharp, soft click with a little bit of side to side wobble happening (if that makes any sense). I haven't been hitting them much, but the triggering isn't as tight as some of my better ones either. They'd probably be better for "selecting" things (key commands and such) than for constant tapping or "timing critical" response. Just someone's 2 cents. ;) I don't hate them or anything. If they lit up, I'd probably like them a lot more. George PS- It seems someone else here has the round headed version.

I'm just trying to figure out how you jump back and forth from Denmark to Spain. You find some sort of wormhole or something?? 8) Take Care, George