stever

The storage isn't being used yet. When I wrote the original article, I left hooks in the design so I could add storage and implemented it when I designed the PCB, but there's no code support for it yet. My plan is to support storing patches in the memory so I can switch between them when not connected to a computer. Depending on how that goes, I might also look at storing a MIDI file in there that can be played back (as a demo, for instance), but that's very speculative at the moment... the patch support is the main new function I want to add. Before that, however, I'm looking at whether migrating to the latest version of the Microchip USB stack makes sense. The current design uses v1.3 and v2.4 is the latest from Microchip. I'm not sure there are any pressing reasons to migrate, but I may do so just to get familiar with the new stack, which has changed significantly since v1.3. Cheers, Steve.

I've played that through mistralXG... now that is some great sequencing and sounds fantastic. I've also got a tremendous version of Birdland (Weather Report)... I have the same concern about copyright, however. Steve.

Thanks for the compliment. I'd consider getting some PCBs made if there was enough interest. Basically, you have full access to the DB50XG... you can send CC, Sysex, whatever you like. I don't have anything recorded at present, but it's an idea... I may put something up there when I get some time. Steve.

Ok, let's work through your list: Sorry... can't help with that, I don't have a DB60XG Presume you mean a rotary encoder to control the device... again, not my design goal, so can't help. I'm sure it wouldn't be too difficult to implement though, and the mistralXG code is available (for personal use). Hmm.. that would be nice, but it's not something I plan on doing any time soon as I don't have a bigger display, nor the need. This is in my plans... I've incorporated memory into the design since the publication in Nuts & Volts (the new schematic isn't up there yet, but I'll put it on my site sometime). Now the hardware is finished, my immediate plans are to migrate to a later version of the Microchip USB framework and then add code to load patches from memory. My spare time is getting less rather than more, so it may be some time. I tried three files from the site by Trond (Dune Mood.mid, Garbage Can.mid, Jumper.mid) and they all sounded fine to me. Regards, Steve.

Just in case anyone is interested, I've now finished the mechanical design and some pictures of the final product are up on my site (www.grapevyne.com/pic.projects). I plan to carry on developing the code as time allows. Steve.

Well it took a little longer than I thought, but the project pages (mistralXG) on my site are now available. There are a couple of bug fixes available, along with the original articles I wrote and the N&V article. Steve.

Fantastic! I've seen those DB60XG clones and been intrigued by them... I'll be very interested to hear how things go! Good luck, Steve.

This, or something like it, was what started me thinking about using my DB50XG for a project quite a few years ago... It was seeing the MIDI-Nator project that completed the puzzle and made me realise I could add a USB interface by using a suitable PIC device. Thanks for the compliment. I've made a few changes since the initial design was published and have a prototype board back that seems to work fine... I'm working on an enclosure at the moment... I hope it will be done in a month or so (not much spare time!). The results will be on my website (www.grapevyne.com/pic.projects)... I hope to include PCB info. Regards, Steve.

Thanks - I enjoyed developing the project, and being able to access and get pointers from resources such as this list made things easier than they might have been. Steve

That's my design... I exchanged some notes and ideas early on with Thorsten about implementing USB-MIDI... he was good enough to run my routines through his test suite, too. The article was spread over the Feb/Mar 2009 issues of N&V.. all the code is on their site. I'll be putting it up on my own site (www.grapevyne.com/pic.projects) in a month or so, and any new developments will go there as well. Steve.

Off topic for MIDIBOX, but I got some great support from Thorsten on here when I first started playing with MIDI via USB so thought I'd pass the news along that my MIDI project (phase 1) is now complete and fully operational. I've written it up as a couple of articles that are being published in Nuts & Volts (Feb/Mar 2009 - www.nutsvolts.com). I'll also be putting it up on my own site (www.grapevyne.com/pic.projects) once the April issue of the magazine is published and in print. If you dig around, you can find the source code already on the N&V site. Future enhancements will also go on my site as they occur. Many thanks again to Thorsten for some early USB-MIDI info. <Added> The project is called mistralXG Regards, Steve.

Hi Thorsten, I've now finished the USB-MIDI>MIDI function and done some testing... Have successfully wrapped data through the PIC and back, including Sysex data. I now have a build you can take a look at if you want. Let me know how you'd like me to get it to you.... Let me know if you want Running Status implemented on the outbound stream... this will be a user option, but I haven't built the interface yet. Thanks for the MIDItrix tip... don't need it at present, but a useful tool to have available. Cheers, Steve.

Still making progress on my project... I now have the MIDI>USB-MIDI state machine implemented and it appears to be working well. While trying to implement what I thought would be the simple part (USB-MIDI>MIDI), I ran into Sysex corruption, which had the symptoms of pointer mismanagement on my part. After checking my code over several times, however, I became convinced that the corruption was occurring elsewhere. A quick Google and I discovered http://www.midiox.com/cgi/yabb/YaBB.pl?board=bugs;action=print;num=1130961608 (and TK had visited that page, too!). I searched for this on ucapps.de but didn't find anything so thought I'd post it in case it's of use to someone. Turns out the MS MIDI class driver corrupts Sysex data if buffers are smaller than the total message size. Changing MIDI-OX's buffers fixed the problem! Fortunately, the application I'm using appears to use large enough buffers, as the corruption doesn't occur with MIDI-OX out of the chain. Thorsten: my MIDI implementation on a PIC18F2550 is now almost complete and usable without the user interface and other features I plan to add. Let me know if you're still interested in testing it out and I'll send you the hex and the I/O info you'll need. Steve.

It was late last night... I'd seen that statement on buffer sizes but forgotten it. It's a bit weak, as you say. I also answered my own question this morning... a sysex message appears as multiple packets in a single transfer. So it comes down to, in Windows at least, that the 00 CIN is not usable with the standard drivers. Thanks once again for your assistance, Thorsten.

Just thought of something else.... good to hear that you haven't seen any "old" data - that makes things a little simpler. But have you ever seen more than one packet arrive in a single IN transfer? If not, is there a problem with making the input buffer just 4 bytes? Even if you have seen more than one packet in a transfer, would a four byte buffer be a problem? Steve.