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.

Wow!... I wasn't expecting that, although I couldn't understand what I was seeing unless this was the case. As you say, CIN=0 becomes useless.... I wonder if anyone has tried this under Linux? I'll see if I can find a system to try, though I've never played with MIDI on Linux before. Thanks for the response, Thorsten. Regards, Steve.

Hi Thorsten (and anyone else watching!), I'm making some progress with my MIDI device but have a question regarding the data coming via the USB port to the PIC18F2550. I've been examining the MIDINator code to get an understanding of how the data arrives - nice and easy as it can send the MIDI data to the serial port. As I mentioned in my first thread, the GetEP1 handler is interpreting the whole 64 byte buffer when there is only one valid USB-MIDI packet in the buffer. The debug code prints all 16 packets out, but (by luck or design?) only the valid packet is passed to a real MIDI device (basically because a first byte of 00 is invalid for USB-MIDI packets). I've got the MIDINator code compiling under C18 and compatible with the bootloader, so it's easy to try things out. By capturing the byte count, it seems that the Endpoint is actually receiving all 64 bytes. As it is based on your own code, I thought you may have an insight into what is going on. I was expecting a byte count of 4 for a single packet - or does the USB engine always get a buffer full of data, padding with zeros as necessary? This seems unlikely as there was no mention of it in the MIDINator article.... although I believe I saw the same behaviour in the original MIDINator firmware. Any comments welcomed, Steve.

Please take a look at the problem I've posted on Microchip's forums and let me know if you've any suggestions.... http://forum.microchip.com/tm.aspx?m=309093 Thanks, Steve.

Uh-oh... my 2550s have 0522 as their date code... I've got some new ones on order, I hope they'll be more recent!! Great... thanks for that... for now, however, I'm going to stick with the new Microchip framework, but if I decide to switch to asm I'll certainly take a look. Steve.

Thanks for the link... some useful stuff there. I'd already got the errata, but the user input is great. Are you aware of anyone trying the firmware from Embedded Inc. mentioned in that thread? Yowch! Tell me about it... I started out as a hardware guy, and that was one of the first things I investigated. That would be really useful - I'll look out for it. On the topic of errata, my 2550s all seem to have a revision code of 00000b... I think they must be very early parts (either that, or I'm reading the bits wrong, but I am seeing the correct device ID, so I think not). I've certainly had them for quite a while. If I make progress to the point where I think you might find the code of interest, I'll let you know. Regards, Steve.

Hi Thorsten, Happy to let you have the binary or the source I've been working with if you think it will be of help... it's basically the MIDINator code, fixed up to compile under C18 and configs tweaked to use an external 4MHz xtal instead of 20MHz. I've added in the Audio Control section of the config descriptors, too. I've noticed some anomalies with it, that I believe are in the original MIDINator, but I'm still investigating this... for example, in debug mode (data going to RS232 instead of MIDI), a whole bunch of zeros are being sent as well as the MIDI data... these are not the spurious zeros you have seen from the UART, as far as I can see, rather that the code seems to interpret the whole 64-byte EP1out buffer, not just the MIDI packets. In MIDI mode, it looks like the midi_out routine doesn't pass these through, so you'll only see it in debug mode, but the data is being passed on by the EP1Get routine, nonetheless. I've yet to work out why this should be; one thing I've noticed is that the Microchip firmware uses the bytecount field after returning the buffer back to the SIE, which doesn't seem right. As mentioned earlier, I don't have much time at the moment, so it may be a while before I get to the bottom of it. I'm probably going to use the newer C18 firmware framework for my own code, rather than the one MIDINator uses... it seems to be better structured and also supports the USB bootloader function which I may use. Let me know if you want the code, and the best way to send it to you. Cheers, Steve.

Incredibly, and without too much effort, I now have my device successfully recognised on the computer that enumerated it but didn't show a new MIDI port. Here's what I believe did it: I downloaded USBDeview from http://www.nirsoft.net/utils/usb_devices_view.html. This displays all USB devices that have been plugged into the computer, whether or not they are currently connected. The Options menu also lets you show Devices without Drivers. On my machine, there were three "Unknown devices" in this category. I deleted them and the entries for my own device. After this, everything worked as expected... I hope this helps someone else. Regards, Steve.

While I'm sure that it's possible to provoke severe timing discrepancies, and I've seen occasional problems when asking the computer to do a lot of other things at the same time, I haven't had too many issues when "single-tasking", just using a sequencer to drive a synth. It'll be interesting to see how things work out when I loop my wind controller through it ???. Though my main use will be for loading patches for the wind controller to use directly, so timing won't be a real issue anyway. Steve.

Well, after fixing up the interface numbering, I got a successful enumeration with the AC descriptors in the config, but there was no change to the situation regarding the availability of the new MIDI interface. On one machine, it failed to appear (the machine I need it on, of course), and on the other system it appears fine and MIDI packets could be directed through the interface. I guess I'm going to have to try to hunt down the reason why, and I know it's not going to be simple based on the initial attempts I made and the comments from Thorsten here. Anyway, thanks for the descriptor info... it made that part of the process much quicker. Regards, Steve.

Can't promise that I'll be able to get to this soon - this is a spare time project and I don't have a lot of that, but I will take a close look at your descriptors to begin with and see what, if any, difference they make and report back. If I'm still having problems, I'll certainly take a look at your whole code package, though I've not been using a bootloader so far so not sure what, if any, impact that will have. Regards, Steve.