moogah

Ok, just got these in today. Same form factor and pin configuration as what voti.nl has, but this one's not quite as bright. It's good enough tho. And check this out, the extra stuff it comes mounted in has 3x 74hc645 and 1x 145 in it along with 5 nice tactile switches and a 6 part bargraph. All through hole!

I was having a similar problem, my core stopped transmitting midi as soon as MIOS got uploaded. Turned out that removing the middle to the J12 jumper immediatly solved the problem. I as well was getting the LCD to light up slightly just by connecting midi cables. FWIW I'm currently using a M-Audio 1010lt where the midi in/out are pigtailed off the card itself, Smash seemed to think the root of the problem may by in an incompatibility between the bench supply I'm using and the computers switching PSU. I'm going to connect my MOTU interfaces with their own PSU's and see if they behave any better. Perhaps we've found a new caveat to the MB hardware. Also FWIW I added ALOT of bypass caps while attempting to solve the problem, only the 2 TK mentions made any difference.

... Funny, I'm trying my hardest to think of something witty and Bill & Ted related right now, but can't.. Ironic really. Sounds like it'd be cool. I'd use it to controll synths more than play guitar tho. I as well have been inspiried by what spectra symbol has to offer, many a good idea floating around in my head.

Hmm... Checked that, reads ~5v with a bench supply, ~4.6v with a 9v battery. With the PIC in and the LCD connected thr Voltage is still stable. Here is a copy of an email sent to SmashTV: In order to troubleshoot this further I'd like to know if there's anything that MIOS uses that the bootloader doesn't. **See update below** It seems that once MIOS got uploaded the midi out went on the fritz. Now, here's what happened. I used the auto feature in MIOS studio so that once I switched on the core, the upload began right away, once finished the LCD showed the OS message and then froze on the "fixed BOR setup" thing. Assuming this was normal and that a reset was prolly needed for MIOS to take over I switched the PSU off then on again. Nothing but blocks on the LCD, no incoming messages at all in MIOS studio. I figured something was wrong, but this was why I bought 2 more pics. SO, I loaded up the next one and repeated the process... and the process repeated ;( This time I didn't turn the power off but began searching for BOR, I as well found nothing. Curious that it was possibly just trouble with MIOS studio or the LCD screen I opened MIDIox and tried to upload the seq hex. The result was the same as if there was nothing connected to the midi cable. I tried sending it a send/receive with the request for flash memory. "waiting for receive", or whatever the message is, but nothing coming in. SO, this is where I'm at in the troubleshooting: -The midi interface/cable coming from the computer works. However, the core schematic shows pins 1&3 of J12 as both being M-. -MIOS studio/Midi-OX are working, to the best of my knowledge. -Information was certianly getting out of the CORE, further yet, it was the correct information, So, the core was/is prolly working, and the MIDI out is prolly working**. -At first I had the midi diode backward, which didn't affect the out port (apparantly, the request was getting through just fine). This was before being able to upload anything (duh). I've traced the schematic of this whole area now, all looks good. -I don't recall wheather MIOS studio really waited between sending 1k blocks. I used the auto feature, in the Docs it mentions a 750ms pause between blocks, the whole upload took no more than 3 seconds. -IF the bootloader is COMPLETELY incapable of overwriting itself than there is some set of processes that MIOS uses which the bootloader doesn't, one or all of these are causing perhaps even the bootloader to hang, perhaps just screwing up the midi out so that the 'loaders message never gets through. I'm assuming the root of this is in a bad or incorrect connection. I've been over the board at least 10 times now, with a magnifying glass. I've found nothing and would like something specific to begin troubleshooting. Is it possible to see if anything is being sent to the opto? I've got test equipment. **UPDATE** I've now tried this with the third PIC. I added the bypass caps first, and was able to get MIOS into the pic. I can now reboot and everytime I get the "MIOS v1.8 T.Klose" screen followed by "Ready." Except MIDI Out is still completely mute. Nothing AT ALL coming out. Stranger still is that this time as soon as MIOS got uploaded the core began spitting out LOTS os sysex messages. However, I then tried to upload the SEQ software, which never got anywhere. I tried the request for flash memoery again, which never got further than "waiting for input". Using the LCD debug in MIOS Studio works now. How would only the midi out stop working.. particularly if both were working before? I'm stumped.

So, I've gottan MIOS uploaded into a pic now, it flases the "MIOS v1.8" screen and then displays "fixed BOR setup" and hangs right there... Worse yet, powering off and then on again MIOS studio doesn't seem to receive the request for upload anymore...

Yup, check the site (don't have the link with me now). Look to be similar if not the same as what voti has (I just got his in the other day, they look pretty good. Six bucks tho.. thats quite a nice price.

I don't have my notebook in front of me at the moment, but I managed to get the touchpad working on the bench. Seems to have less resistance than the softpot's (which are VERY cool) and also seems that there are two "buttons" under the pad itself, which explains the extra leads. I contacted a sales rep about the softpots, ~9$ each for an order of 100, price drops quite a bit around 500, 2.50$ (US) if I remember correctly. With the proper drivers and some good visual feedback these could make a slick replacement for MF's.

Well, after struggling with the JDM I tried this.. And, no luck All the .exe's seem to hang (even with userpot configured). Worse yet, connecting a 9v from pin 1 to ground caused the PIC and battery to get very hot!! so much so that I could feel the heat through the breadboard!

Well. I just tried it with a PSU set to 15v and tested all the way up to 25v. I could get the peak voltage to imporve, but it still fluctuated, mostly between the space between read program and read data.

*UGH* This sucks. Can someone with a working JDM try to replicate my measurements during a read all? Can someone with a working JDM running windows XP post what type of motherboard they are using? Perhaps I've wrecked my PIC?

Ok, first off I must mention that AFAICT all the links in the "links to JDM trouble" thread lead to a 404 error. Secondly, no-one (with the exception of TK) who has credited their troubles to a specific motherboard or CPU/IO delay problem have fessed up to the specific details of which motherboards/CPU speeds worked/didn't work! SO. I'm working with: XP SP1 system ABIT NF7 motherboard Athalon 1700 plugged in I've also tried this on an old Compq Presario, 233Mhz running windows millenium. Same results as below I'm using a SmashTV board with an 8.2v zener/PIC18F452. This board appears to be missing the 10k from pin 38 to pin 31. My results have been the same even after connecting one to the bottom of the board Currently I have tried this with and without the 9v batteries, with little difference and no success. I've used both COM ports, with the same results, and have tried every IO delay from 1-20 and several over 20, no noticable difference. I've tried using API, totalio.sys driver for Direct I/O and simply using API. with totalio running, No noticable difference. Without the PIC plugged in my readings are as follows MCLR 12.6v / 13v with battery VSS 4.6v / 4.8v with battery. NOTE: with the battery connected VSS stays steady at 4.6 after it's been unchecked clock ~4v peak, rapidly drops. same behavior with battery, but I suspect the peak is higher Now, when I first check Data out, MCLR jumps to max and stays there so that the first check on MCLR makes no difference, unchecking it drops the voltage and re-cheking it them raises it again. This seems normal to me. Also, when icprog is not running MCLR is often at max, when it is started voltage drops to ~2v, when the hardware menu is opened the voltage drops to ~.5v and rises to ~2v after the hardware menu is closed. With the battery connected MCLR is ~5v while not running icprog, no difference at startup, opening the hardware menu drops voltage to about 1v, closing it returns to ~5v. Only small differences in voltage @MCLR with larger delay times using the totalio.sys. If I remember correctly there is a difference in voltage with API, perhaps not tho. With the PIC plugged in and without a battery: following the instructions to perform a Real All, MCLR varies from ~2v to ~10v MAX. switching on the battery: MCLR jumps to ~13v, starting the read drops the voltage to ~10v where it remains much more consistant. The voltage staying at 13v untill a read starts seems suspicious to me. I've quadruple checked my diodes, several times. NOW, If I start the program and do a Verify right away, it passes. If I then load a .hex and do a Verify it fails at "0000h". Every attempt at doing a burn has failed at "000000h". From my understanding this essentially means the computer was entirely unsuccessful in opening a connection with the JDM. I have never been faced with a ghost in the machine like this. QUESTIONS: How do I test my Zeners? Capacitors? Transistors? D5 shows 8v, D6 shows 4.6v While icprog is running D4 reads .2v, D3 ~2.5v, D4 .3v, D1 ~2.5v While a read is in progress D3 fluctuates with a peak of ~13v, D2 same with a peak of ~5v, D4 steady at .3v D1 peak ~3v After the read D3 & D4 hold at 13v and 5v. D1 & D2 hold at .7v I've checked against the schematic again, pulled up the datasheet for the BC547's. Everything is ok there. While doing the hardware test everything checks out. With or without the battery. MCLR is still a bit on the low side tho, just below 13v. I am 99% sure they are working after reading all the other threads here. My problems are too similar and it seems the root is a combination of flakey drivers and inconsistant power to the JDM from COM. Furthermore, there seems no correlation between success and failure from case to case. The X factor is simply missing from peoples reports and seems as much attributable to VooDoo than any scientific effort. It's late here, and my eyes are getting droopy. More to come tommorow. More questions: Should MCLR remain steady while a read is happening, or should it fluctuate? I've found that generaly it will peak at ~13v at the begining of the read and then fluctuate, often holding ~10v. There seems to be a relation between what icprog is doing and the fluctuations, so I assume this is normal. It seems to me that the "enable MCLR as VSS" option has no effect, and I believe it to be for a different chip/programmer anyway. UPDATE: I've got more info on the strange readings at CLOCK. It seems that toggling the VCC checkbox causes Data In to toggle ON. When this happens the voltage at CLOCK drops to -.7v. Enabling CLOCK results in the situation described above, peaking at ~4v and rapidly droping to ~2, falling slowly from there. Turning clock off returns the voltage to -.7 NOW what is strange is this: while Data In is on I can get the clock readings to return to normal by toggling MCLR. In fact, while MCLR is on, the clock voltage drops like described above. When MCLR is turned off clock returns to max, around 5.5v. Turning off data in or enabling data out, clock drops to 0v. Enabling MCLR now drops clock to -.7v

Just gonna add my .02 This is a fantastic project, and is what pushed me into midibox-making. Simply superb FYI I'm currently at the breadboard stage with each individual instrument trying to find a way to make all the params controllable so that more than just notes can be sequenced. Perhaps this is impossible. I'm gonna try anyway!

Free samples... Gotta love it.

Well, the samples are FREE it seems. So I just requested one of everything. I'll put the DVM to em when they show up and post what I find.

Hey, this stuff looks great! Put me in for a couple sets of MPC-style pads, those look perfect! I'd definatly be interested in the LED-rings too. They look nice. Same with the buttons really. Good work!

I'm making an 808 clone and would like to hook the SEQ up to the 808's knobs for full patch storage and realtime adjustments. I've got the circuits to replace the pots with voltage controll, but I see that the x8 module only works with the mb64 app. Can I possibly downsize the x8 module to work with the seq, or is this a firmware restriction?

Does anybody have a supply of these? Preferably in the US. They look just right for my 808 clones.

*Yay!* I'll be sure to post the code for all the 'grooves' once they are good and working.

I'm hoping to modify some of the program to allow "groove" quantizes I have found by examining drum breaks. To do this I will need a fairly high resolution, more than 24ppq. Is this the limit for the PIC? 96 ppq will prolly suffice

Aesteticly the blue screens look best to me, but it seems they may actually be a bit hard to read compared to some other color combo's. Anyone have thoughts about this? Reccomendations for good screens? The MIOS suppors 4X40 screens, right?

.... Isn't the audiophile a PCI card? I still don't quite get what is going on....

This blows my mind. Perhaps I'm thinkin this does more than is actually possible. How are people doing this? I though the PIC couldn't work with audio?

I checked mouser, and all I saw were > 50$ optical ones. What else is out there?