stryd_one

I've seen it done... What you do, is drill a round hole, and glue in a shiv to make the 'D'. (I've also seen cork used but that's another story)

I couldn't tell... Scrolls riiiight off the side of the screen. If you go much more high res, we will be able to check the PIC's silicon die for errors ;)

What about their assistants? Edit: Image removed - Offsite documentation can do things like run out of bandwidth and spoil your fun. :D

Nope, that's broken. I'll come back to that in a few posts time... Why not now? Well.... Guaranteed path to trouble. Don't do that. Always use smart mode. Only turn it off, if some guru dude needs you to turn it off to test something, and then turn it back on as soon as you are done with that test. If smart mode is not working, fix that problem first, because smart mode ensures a good upload, and without it, you can't be sure that anything you put on the PIC is not corrupted...... so all subsequent tests are rendered useless. I'm sure you don't want to waste time :) The instructions don't mention it because you shouldn't have to do that. So now we have two issues to approach: Toolchain setup, and MIDI uploads. Fortunately these two issues don't interact at this point, so you can decide which one you want to fix first :) Now that's enthusiasm! Get em!! :D

Wow that is SERIOUSLY nice work!! Love the joysticks! (to mention just one thing hahah) It's a damned shame you're taking the documentation offsite. It's MUCH better to put it on the wiki here. </broken record>

Thanks :) If you use the 'code' tags (The # button up there ^ ), it will render in a fixed width font - handy for ASCII art (which I love)

The upload requests out of order are concerning. If you have a problem between sending from your PC and receiving at the core, then it can often cause the core to continually request like that... But the core is obviously recieving MIDI... just.. not correctly... Once you've ensured you're not on the blacklist, you might like to check your PSU, and perform the midi troubleshooting tests on ucapps. On other matters... When you burned the PICs, you did it in HVP mode and you verified the upload right? (That's the feature where the app reads back the contents of the chip after the burn, and compares it to the hex file - I don't mean a human-driven-verification). Your board grounds the unused AINs?

Thanks twinnie :D I was stressing about this, because we all know what happens when someone goes and changes the license on MIOS code (which is posted on the wiki)... >:(

Just bumping this thread to bring it to the attention of the new mods... Guys, we need to check every post (yeh, yeh, I know it sucks) to ensure the tags aren't effected by this, and if they are, manually delete them and recreate as necessary. We should check them all anyway; to remove the junk tags (some seriously spurious tagging goes on around here, it messes up the cloud); to fix up typos etc; and to ensure that common tags are used (eg delete a tag that says mb-6582 and replace with mb6582); among other tidy-up type stuff... This is just one more thing to add to the list of checks. I'm no longer making efforts to chase the bug down, as the plugin is likely to be replaced with alternate software in the not-too-distant future (is that still right, twin-x?)

Royal: Sounds like the PDF reader is not correctly associating with that MIME type (which it obviously recognises, judging by that error) Chrome is a beta so I won't start bugshooting that... But My FF works fine there... sorry mate, I think it might be your machine that's broken.. :( A few basic things: What PDF reader do you use? What OS? Any plugins you have installed? Does it work OK if you disable the browser plugin, so that it downloads and then reads the file in the standalone reader?

... Kicad ;)

in 11 days (less some for building/testing) you will only be able to get common stuff... maybe you can get a JDM off ebay or a set of components to vero one up... You're really cutting it fine though :( I'd get to ordering as per the ucapps.de partslist if I were you... actually if I were you, I'd work on an alternate software solution first, as a fallback in case you get time to start a clockbox but not finish it.

Nice :) I like the minimal unmarked face... kinda reminds me of that black PC keyboard... --> MBOTW Forum ;)

I would say it's a bit late to order PCBs for this... If you are a fast worker and experienced, perhaps you could make a core module on vero board or similar?

Heya guys... (I guess this is mostly for you, Twin-X?) I was trying to fix up these two pages: http://www.midibox.org/dokuwiki/doku.php?id=how_to_use_midibox_cv_with_a_dout http://www.midibox.org/dokuwiki/doku.php?id=how_to_use_midibox_cv_with_a_dout_german As they appeared to be 'orphaned' - they had no backlinks. But, I found the links to these pages on the midibox CV page. That's bug #1 The links had not been correctly created, so I went to fix it up, and found this message at the bottom of the page: Huh?! That's bug #2 ...and very concerning! Then when I tried to save my edits: Fatal error: Call to a member function getUserData() on a non-object in /home/midibox/public_html/dokuwiki/inc/common.php on line 1287 That's bug #3 Awwww, I think I broke it :( Thanks in advance guys...

Yeh... movf MIOS_PARAMETER2, W ; pin number: note number - 0x24, we start with C-2 addlw -0x24 Maybe you could do with some checking in there, to deal with what should happen when the note received, is lower than C2...

Wise, and kind. :) I'll try to help you figure it out... I just saw this: Driver reinstallation is just the kind off change that would fix the problem with your midi interface. I gather that the midi interface was not working on either PC or laptop: Was this test done as per TEST INOUT1? Or was it a direct cable connection from the midi interface 'out' to 'in' as per TEST PC2? Particularly the second problem, indicates a problem with the PIC. If a direct loopback like TEST PC2 fails, it was definitely the PC... But a PC failure does not exclude a PIC failure also. The most difficult bugs to diagnose, are the ones where two separate things have gone wrong, at the same time.... It seems that maybe that's what happened here... I have some suspicions, but I can't be sure yet as I lack some details... Let's sort out the details above, and it will lead us to an answer...

Heya midnite, We're now using a free, cross-platform toolchain to build midibox apps - this means, GPUtils, rather than MPLAB; GNU make rather than batch files, etc. nILS' post is right on the money, follow those instructions and it will work :)

Hah, that explains a bit... I was looking at the code in SVN (which is the 2.0c version), not in the zip file.... ooops!! Sorry!!

That is definitely a PC failure, not your PIC chip... Perhaps something changed on your PC (even a reboot or something could be enough) and by coincidence, it happened at the right time to make it seem that the problem was the PIC? Hey, it works, that's a good start :D

I hear that's a good way to conjure magic blue smoke to be on the outside of the box...

Every so often, the replacement part has the same fault.... Good luck! (Are you following proper antistatic procedures while handling these?)

Thanks! :)

Welcome aboard :) You won't find a better MIDI clock anywhere. Tests in MIDI-Ox would be irrelevant, as the timing is at least several hundred times more accurate than the timers your PC has to offer - an oscilloscope would be required, and I know that TK used his when testing this software :)

That's a good deal too!