Jidis

AC- No, mine's actually about 20 years old. She'll do that "plop down in the middle of your work" thing too. Those two were just guests for a day. My sister had temporarily taken them in for one of the homeless cat adoption agencies here. I've been meaning to call her and see where they ended up. I'm hoping they got to stay together. -George

;D

Stryd, Yeah, I already opened it on the second day or something, after trying everything else and reading about what the specific noises it was making indicated. One of the big hardware sites had an article about it, where they not only open the drive, but they swap head assemblies or something. It looked scary as hell, and expensive, and the bottom line was that even *if* it worked, the drive was not to be trusted for long afterward. This was for when there was a failure of the head mechanism itself. Everything I read seemed to imply that in a case like mine, where the platter was already damaged, you were SOL unless you had five or ten grand to have it sent somewhere to be read by alternate means. I too got to thinking about folder sync software after all this, but I think the obvious solution is just better backup practices alltogether. There's really no excuse for me having 130+ gigs of junk all in one vulnerable place like that. I probably only really needed to be carrying a small fraction of it around with me. @Sasha- That's exactly how I am with the permanent back ups. I figure if it isn't perfectly sorted for archival, I'll have to do it again later. Now look where it got me. :-[ I will say I was really happy to find the second copy of my studio pictures. I had been in that place for about six years, so they were about all I had to remember it by, plus before I disassembled everything, I had to get all the junk out, so the rooms were actually clean for the first time in years. ;D George PS- To add some humor to the otherwise depressing tragedy: I scored a good deal on a used 1.5GHz laptop last week, which was listed as "needing to stay plugged in". I figured that meant dead battery, but to my surprise it turns out the kid had tripped over the cord, breaking the DC jack and had wired the power cord directly to the wires inside, along with a homemade duct tape strain relief. Must have done the same thing to the RJ45 jack, as half of it was missing. After fixing it, I was bragging about the deal to my sister and mentioned how many "abused" laptops there would soon be, with all the kids dragging them around, knocking them off desks and tripping over their cords. I killed the drive literally ten minutes later. 8)

I worry that doing that isn't 100% safe either. I think I've had just about every common brand of drive croak on me at some point (usually going into "click mode" first). I've had to RMA two or three WDs and then was reading that they were recommended as one of the most reliables among some audio people in the Steinberg forums a generation or two later. I think it changes from line to line, but maybe even from one batch to the next. Two of the removables I used to use were IBM Deskstars and I had thrown them around like my car keys for years and they still work, but then I had one internal in my Mac which looked just like them, and it died within a few months. I think my main problem with the backups is that I need a better system of sorting (or just taking the time to do so). When I head out at night, I tend to drag all the saved and downloaded junk from my desk or whatever straight into the root of the external or removable I carry with me. If it went into a nice neat folder hierarchy until it built up to DVD size, I'd probably have had it all safely burned off, but I make such a mess that I'm never ready to save. I've misplaced my 128M USB flash drive too, but there was nothing on it. I'm thinking of grabbing a big one of those at least for carrying copies of the smaller important stuff like MIOS apps and layouts. There's a lot to be said for media with no moving parts. I actually went inside that dropped drive, and it has a circular gash going about 80% of the way around the platter. The head is supposed to skim along the surface, floating over it by like a thousandth of an inch or something ridiculous. Knowing that now, I'm afraid to even breathe too hard around an active drive. Thanks all for the sympathies. Not everybody understands that sort of thing. My mother actually yelled at me when I told her about it, because there were two or three grandchildren pictures on the drive (they only have about a thousand other ones). Take care, George

Digineural, Glad to see another sander fan in here. :) I use them for everything here (a bench sander and two handhelds). I usually cut all my PCB oversize and burn down to the layout lines on a belt sander, sometimes even after the board is populated. It's amazing how fast those things can eat a board. Bad part is, it's sort of a mutual thing, with the board eating away at the belt as well (I try to use older belts for it). Never used an SMD with the board still on it, but I have sawed many through-hole parts to help get the board off with the iron. Sometimes running a Dremel cutoff wheel between pairs of legs, and then sawing around the part will leave you with a bunch of small chunks of board with a couple legs in each. Then you can push downward on them while touching the iron against the legs and they drop right off one by one.

Well, last weekend, I think I had about the worst computer experience imaginable. I snagged the power cable for an external USB drive with my foot as I was leaving the desk, pulling the drive off the top of the computer, and landing it on the floor, most likely while it was active. It immediately becomes "unrecognized" and begins making a shuffling sound, which I imagine now was a head scraping across some new gashes in the platter at 7200rpms. For many years now I had been dragging around three 40 gig drives in caddies and using external bays on three different machines at home and the studio. I had finally gotten wise and moved to something hot-swappable and less "clunky", equipping the three machines with USB2 cards and copying all my data to an external. For the past couple months, all current activity and saves happened on the new external. After gradually realizing that nothing was going to revive the damaged drive over a couple days, the feeling was indescribable. The more I thought about the folders, the more stuff I remembered was on there, Nuendo sessions, Ghost images of "clean states" for my machines, hundreds of megs of photos, websites and hours of downloaded info and PDFs, and of course, MIOS/MB projects, including the panel layouts for a controller I started a few months ago. On the bright side, I discovered yesterday that three weeks worth of recent studio pictures from a place I had been in for the past six years, were also on one of the removable caddy drives in a folder called "safe". I hope nobody here even needs to be warned about doing something that foolish with their data. I've had more drives fail than I can remember over the years, but somehow I've grown accustomed to having them warn me a little in advance. This one happened in less than a second. Sorry for the long-ass self-pitying sob story. I guess I earned every bit of it. George

Dizzu, You should look further into the MIDI note formatting and where MIOS stores the different parts when it receives a note event (pretty well documented in TK's apps). There's a decent description about halfway down the page here: http://www.mibac.com/Pages/MIDIReference.html The three bytes you'll likely be interested in will get dumped into evnt0,evnt1, and evnt2. The first will be the status, which should be a hexadecimal 9x or 8x for note on and off, where "x" is the channel number, 0-15 (0toF hex) for the 16 MIDI channels. As Thorsten has noted, sometimes a note-off will be handled by a note "on" message with a velocity value of zero (9x xx 00). So with evnt0 being passed to the pinset call, you'll effectively be trying to activate some pin way up in the #150 range (hex 90 = dec 144), and probably the same pin each time, even if the note number changes (don't know how the app handles something out of DOUT range). The part of the message you probably want to send to the DOUT call will be the second byte (evnt1), which holds the incoming note number. Not sure what range you'll be working with, but by default, I guess they'll be triggered by notes 00 and up (pretty low). You may need to subtract something from that evnt1 argument when you use it, if you can't alter the notes you're sending the box. Also, make sure you incorporate something to turn 'off' the lights, or they'll stay on forever. For instance: if( evnt0 == 0x80 || evnt2 == 0x00 ) MIOS_DOUT_PinSet0(evnt1); should take anything that's a "note off" or "note on with a velocity (3rd byte/evnt2) of zero" and trigger a DOUT "off" message mapping the incoming note# to the pin you want to disable. Hope that helps, :) George (fellow C newbie) -- BTW, if you haven't already noticed, there's also the call David mentioned, where you specify pin on/off with the second argument you pass to it. I guess either way is OK.

Stef, I guess you mean MIDI Clock/Song Pointer. The MIDIMon has routines for that, which should help figure out what stuff you're looking for (in ASM at least). Good Luck, George PS- From what I remember, it doesn't actually disable one of the two (MTC or clock). If you throw it both, it just tries to display both. In Nuendo here, it's no trouble as you can uncheck the one you aren't using in the timecode output panel. May not matter either if you're just grabbing beat/quarter note messages for something else. ;)

Speaking of which- I was looking at some of Thorsten's "Programming Examples" from the bottom of the MIOS C interface page the other night, and there's an example which seems to do the same thing (I couldn't find the link between the incoming note # and the "pin" variable used for the DOUT call). IIRC, I had seen the missing part in one of his other apps or examples, so maybe the example snippet was pulled from one of them. Take Care

;D Here's a weird one for the record books.... Had time to dig a bit further into that board last night, and tried pulling the two DOUT ICs and running with just the DIN half, as switch #8 wasn't working either, and it's path to the 165 seemed OK. Lo and behold, running an MB64 app with no 595s installed, the last LED from DOUT#1 has a mysterious faint "glow" to it. ::) (thank god for visual indicators) Turns out a glob of solder on a pin somewhere had bridged itself a link between DOUT pin#15 and DIN pin#6. Not a perfect link, just enough for about 150 ohms between them. I thought I had gotten better about checking my freshly etched boards for shorts and crap, but I guess I need to extend my checks into the "post population" stages. As if I don't have enough trouble proofreading my newbie C code- now the soldering iron's in there with it. ;) George

What the HELL is that??? If I didn't live inside a mound of half-finished junk, I'd be trying to buy that now. What are you guys doing with a Richmond anyway?? That's where I live here. :P Does that controller go by some other name and has anyone else here seen one before, or is it some rare breed Dr. Moreau cooked up? :o George

GREAT GOOGLY MOO. :o :o :o :o Man I envy you. Have fun and be careful. ;) ...off to find a rocking chair George

That shouldn't be a problem (aside from the fact that they're all already installed on all my stuff ;D). If I'm not tied up tonight, I can try to start getting some together. As mentioned, a couple of the things I'm referring to wouldn't actually be install options (like that huge list of includes that MPASM has). There are also a few areas I've hit where the actual "installer" file might be a bit more specific (like the download links that drop you in a directory with 20 different builds, 10 versions, the sources, the "extras" bundles and docs, and a version or two you'll need if you're running <#@?>). --Linux people are probably used to all that. ;) I'm sure it would be against a bunch of license agreements, but wouldn't it be great if there was a "MIOS Development Kit" installer to put all that stuff in place with any path additions,etc., and the absolute minimal batch of files and apps? I remember with that MPASM issue, you would normally have to install the whole MPLAB package, but the actual MPASM junk you used could run from a self contained folder, in any location, and was less than a floppy in size. That Active Perl install was pretty hefty too IIRC. Take Care, George PS- And thanks for the interest! :)

Well, I dug that board out again tonight, and it's not the PIC, and it's not the 74hc165 (swapped out both). I may pull the PCB from the board if I've got time, and see if there's anything wrong with the DIN/DOUT board next. If anybody knows this: One DIN chip (165) and two DOUTs (595s) set in the software as SRIO number= 2 should still be OK right? Seems I've got other stuff running mismatch quantities there, but nothing with 1&2. Thanks

I wouldn't think it would be a good idea for anything to do that on it's own. If there's no fancy control panel/patchbay for the MIDI part of the interface, I would guess it lets everything go. Don't know on the Oxygen either, but if the port shows as a standard MIDI out available to your DAW software,etc., I would guess that should work as a one way dump. Sorry that's not much help. :-\

:-X Shot down by MinGW :-X I should've known from the filesize it wasn't a "real" installer. ;D Got the downloaded half now, so I'll take that with me tonight (there's no internet where I go at night). George PS- Hate to be a beggar, but I was thinking during an install the other night that it would be cool to have a specific listing here for some of these development apps, as to which components could be unchecked during install, or even deleted afterward by those who have no intention of doing anything outside MIOS apps and PICs. Many seem to dump a whole slew of libraries and included files which I suspect most of us don't need, but are afraid to delete or deselect during install. I remember there was once a similar discussion here about a bare minimum MPASM folder to compile MIOS apps. Might be good for some of us using machines of more "limited" resources.

Looks like maybe a graphics card driver issue. I backed up to one a couple versions older and didn't see any trouble all tonight. Guess I'm OK for now :)

Thanks again (and bravo on the writing)! I'm taking this along with the downloads I need tonight (hope I got them all :o). George PS- It seems I did read a recommendation for the nightly build. I had that with me when I tried, but I just installed the RC thinking I was being "safe".

Stryd (if you're here)- Was there any special setup or config required for that CodeBlocks install to compile MIOS apps? I'm running the regular 1.0rc2 install, and it detects SDCC, which I set as my default compiler. Were there any additional steps needed and does it automatically associate and link all the proper files for a MIOS app if you build/compile from within CB, or do you have to create a project and do a bunch of configuring as well? I think I'm in way over my head on that one, but I'll keep trying off and on. ;D BTW- That Crimson editor thing I found does a bunch of the same auto-highlighting and junk for the braces, so I'm probably OK with that for the time being anyway. I will admit that it totally F***s up things with long paths though. :-X George

Paul, That sounds like a healthy bootloader with no MIOS or app yet (the LCD would only have that row of blocks at that point), but somehow your MIDI output isn't making it out. Being simpler than the input part, it shouldn't be hard to troubleshoot. Have you checked the wiring of the MIDI pins? I think everybody in here has gotten the two main pins reversed at one point or another (or a hundred in my case). Remember you may be looking at diagrams referencing the front or rear of the five pin connector. Good Luck, George PS-- Make sure you're not using something which might ignore or filter a SysEx message on whatever you're feeding from it. I think my Kurzweil sampler's monitor might do that to certain message types.

Thanks Thorsten :) It didn't seem to reset however. The app keeps running and the loop never terminates. IIRC, I think I could hit it with a MIOS reset from MS's debug panel to restart the app and clear the loop. It also works well on two other boxes using the same number of lights. Been having too much fun playing with C apps to dig that board back out and wire it up unfortunately, so it is still possible that there's an electrical fault or maybe there's a difference in the PICs I'm using. I'll post if I get anything new on it. (and look into alternative means of long delays as you recommended) Take Care, George

Man, thanks! A lot easier than I thought. I remember that from Dos batch/junk, but reading the batch file that runs the compile scared the crap out of me. :o Thought I'd have to insert some switch way up in there somewhere. I will gladly check out Codeblocks. These messes of curly braces I'm making and conditional crap inside other conditional crap are making me understand old people I used to read about, who preferred to work in assembler or didn't even know any higher level languages. I grabbed an editor (Crimson) which colorizes stuff a bit, but even the simplest functions I've built still look like a train wreck. Take Care, George

Stryd (and all), Speaking of SDCC- Do you guys have a method of dumping (or finding) the full error listing after an unsuccessful make? I'm usually running in a dos box, where all I can ultimately see is that last stream of errors caused by the "real" one. Sorry to change the subject. It just reminded me. ;) George

FWIW, a Java reinstall (updated by a couple builds actually) didn't seem to do the trick. :'( I may drag another graphics card driver with me tonight or just live with it if I have to. I already know what most of the mangled buttons do anyway. George

Yeah, I'm in a habit of sticking mux and shift register chips on the boards with my controls, so I use salvaged internal computer cables when I can too. Man, I skimmed through those details and saw the number '8'. Didn't realize you were talking 8x8! :o Is there no way to isolate parts of the chain or anything to see how many work without the random mess? From the software angle, I know on that 8 pot box I've got, I'll sometimes compile for "number of pots = 1" and it ignores all the others, but I'm not sure if that would block out a more serious hardware issue. Do the random messages point to any one component's actual messages or are they not even stuff the box is supposed to send? Good luck again! - off to fight with my own box now ;D George PS- We need to get some sort of Batman beacon light we can turn on to call Thorsten on stuff like this. ;)