Casio CZ/ VZ/ FZ - Pro Series

See RESULTS below:

--- In CZsynth@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> It still doesn't make any sense to me, but I was willing to design some tests to see what results I can get with my E-Mu 2x2 usb-midi interface.  The most extreme test I could think of is this:
> 
> 1. Run my arduino midi program into the usb port on a Win 7 laptop using the hairless usb-midi bridge.
> 2. Send the arduino's midi data out the E-Mu 2x2 usb interface to the CZ-5000.
> 
> One snag >>might<< explain why slowing down the midi stream seems to work.  See below.
> 
> I can set the arduino and usb-midi bridge to 115200, 57600, 38400, and 19200 to see if the E-Mu 2x2 can successfully receive the midi data from the arduino and then retransmit it to the CZ. If not, I'd take this as evidence that the problem is not that modern computers have faster CPUs that computers did in the 1980s, but it is a matter of serial communication rate differences.

RESULTS:
With the arduino sending serial data at 115200 bps and the hairless serial midi-usb bridge receiving the data at 115200, the E-Mu 2x2 usb midi interface successfully midi data to the Casio CZ-5000. (The program sends out CC, note on, and note off data sequentially on 16 midi channels at a fairly fast rate. I have used it with E-Mu's Proteus VX-a free multi-timbral VST.)

I did this test in two ways:
(1) with the usb-midi bridge sending the arduino's data directly to the 2x2 port connected to the CZ, and
(2) with the usb-midi bridge sending the arduino's data to midi yoke and midi-ox routing the midi yoke port to the 2x2 port.
Both methods seem to work just fine.


> For a second test, I can try sending a patch request command and waiting for the patch dump. I know it worked using midi-ox on a Win XP PC, but that's a 32-bit system. Perhaps there's something about Win7 and/or an 64-bit OS that would cause a problem. 

RESULTS:
This worked too exactly as expected. I sent F0 44 00 00 70 10 60 70 31 F7 to the CZ-5000 using midi-ox which in turn received the requested data (263 bytes).


> I can imagine two results: either test 2 will succeed or it won't. If it does, that should put to rest the CPU speed differential (between modern computers and older computers) as the cause of the problem. 

CONCLUSION: Based on these tests, I do not believe the speed of CPUs in modern computers are causing the problem. (See the thread for other possible culprits.)


> If test 2 doesn't, I can try putting in some sort of delay. Unfortunately, that will neither prove nor disprove that the problem is caused by the CPU speed differential between modern and older computers. So far as I can tell, it could be any of a number of other causes.

CONCLUSION:
Delays were not needed in this case; however, with different midi interfaces and their drivers delays might help make up for design deficiencies.

> (Not sure when I will be able to run these tests, but I am interested to see what the results are.)
> 
> Steve
> 
> --------------------------------------------------------
> "Can I use the native MIDI baud rate, 31250bps?
> 
> It would be nice to be able to use the hardware MIDI baud rate, 31250bps. This means the logical signals from Hairless Bridge can be used with real MIDI hardware, with just some electronics to adjust the serial voltages to become MIDI current loop signals.
> 
> Unfortunately, most computer serial ports can't actually talk at 31250bps. For historical & technical reasons they're usually limited to multiples of 300bps.
> 
> However, if you're prepared to hack around a bit, the FTDI USB/Serial chip (as found on the Arduino Duemilanove) can talk the native MIDI rate. Have a read through these Arduino forum posts and you can see how to hack the driver on OS X or Windows, so that when you choose a different rate (like 38400bps) it is actually 31250, behind the scenes.
> 
> This is not a supported configuration for Hairless Bridge, but it can be made to work in some circumstances." 
> 
> 
> 
> --- In CZsynth@yahoogroups.com, analogmonster@ wrote:
> >
> > His reasoning makes a lot of sense actually. 
> 
> [snip]
>

CONCLUSION: I stand by my original claim that blaming the speed of CPUs in modern computers doesn't make sense.  As usual, I am open to other opinions provided they can be verified by valid, reliable tests and sound logic.  

Steve