Jump to content

stever

Members
 View Profile  See their activity

  • Posts

    28

  • Joined

  • Last visited

 Content Type 

Posts posted by stever

  1. Put Waveblaster daughter board (Yamaha DB50XG) in a box?

    in Design Concepts

    Posted

    Stever,

    What is the 128kb Storage used for? I read through the articles a few times, but i couldn't find much info about it.

    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.

  3. Put Waveblaster daughter board (Yamaha DB50XG) in a box?

    in Design Concepts

    Posted

    Awsome design! I wish I had the know how to make my own custom boards. Would you maybe do a pcb bulk run for us midi boxers? I still have to read through the article but are you editing sounds with cc messages? Any sound samples?

    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.

  4. Put Waveblaster daughter board (Yamaha DB50XG) in a box?

    in Design Concepts

    Posted

    I have a wish list:

    • optional Audio Input for the DB60XG
    • encoder for the menu
    • bigger display, e.g. 4x40 or 2x40 to display all channels, instruments, ...
    • support to save and load QS300-Voices over the memory


      @joeribl
      The PSU is not the problem, because it is external.

      Can you try this midi files from Trond Olsen

    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.

  8. Put Waveblaster daughter board (Yamaha DB50XG) in a box?

    in Design Concepts

    Posted

    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.

    @Steve, nice project.  :)

    Do you have created a board for preview?

    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.

  10. Put Waveblaster daughter board (Yamaha DB50XG) in a box?

    in Design Concepts

    Posted

    I recently saw an article in Nuts and Volts magazine (Feb 2009 edition, I think) showing a PIC based controller for the DB50XG. Had USB interface, but the PIC wasn't one we use here.

    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.

  11. Project complete

    in Design Concepts

    Posted

    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.

  12. MS MIDI driver problem

    in Design Concepts

    Posted

    yes, I'm interested in testing your firmware, especially under MacOS.

    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.

  13. MS MIDI driver problem

    in Design Concepts

    Posted

    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.

  14. Size of received MIDI data from USB

    in Design Concepts

    Posted

    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.

  15. Size of received MIDI data from USB

    in Design Concepts

    Posted

    I can confirm this - the byte count always corresponds with the "bytes per packet" definition, which has been made in the OUT endpoint descriptor. I guess that the actual package size is full under control of the USB host, so it might be a windows specific issue. I believe that the unused buffer area will always be patted with 0x00, because I never noticed something else (e.g. artefacts from previous transfers)

    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.

  16. Size of received MIDI data from USB

    in Design Concepts

    Posted

    I can confirm this

    ...

    <snip!>

    ...

    However, I see the point, that it makes CIN=0 packages useless for future extensions.

    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.

  17. Size of received MIDI data from USB

    in Design Concepts

    Posted

    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.

  19. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    Which ID is printed on the package?

    E.g., my non-working (EUSART bug) rev2. has 0504409, the working rev5 has 07351KG

    I guess that the first four digits stand for year and calendar week of production.

    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!!

    I've released the source code + some documentation now:

    -> http://www.ucapps.de/mbhp_usb_pic.html

    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.

  20. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    Last saturday I incorporated all the framework errata which are documented here http://forum.microchip.com/tm.aspx?m=275422

    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?

    I feel that I'm not able to continue debugging without a hardware based USB analyser. But they are too expensive, especially for a sparetime project.

    Yowch! Tell me about it... I started out as a hardware guy, and that was one of the first things I investigated.

    For next weekend I'm planning to write down all the findings, put the documentation and unstable firmware on the website, and to freeze the project again - in the hope that sooner or later somebody else will find the bug, or can give me a fully working firmware for further analysation.

    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.

  21. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    Would it be possible to get a copy of your firmware (binary is sufficient) - as I wrote in this posting http://www.midibox.org/forum/index.php?topic=10447.msg79114#msg79114 I noticed a new issue - three different firmwares are failing under Mac OS. The strange thing: the Cypress based MBHP_USB firmware is running fine, so that a Mac specific driver issue can be excluded.

    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.

  22. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    please keep me informed about the progress

    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.

  23. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    You can't be trying very hard ;)

    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.

  24. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    ....but I will take a close look at your descriptors to begin with and see what, if any, difference they make and report back.....

    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.

  25. USB-MIDI newbie... questions!

    in Design Concepts

    Posted

    Could you please try if my own PIC based implementation works better with your host?

    Note that it requires the USB bootloader, which is provided by Microchip (it simplifies the firmware upload). Therefore my firmware begins at 0x800.

    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.

×
×
  • Create New...