OK, test environment first:
17" MacBook Pro running Bootcamp 2.1, XP Home SP3, latest hotfixes and updates.
DLink 7-port POWERED USB Hub.
On the hub is the following:
Korg nanokontrol
Akai LPK25 keyboard
Novation Launchpad
M-Audio MIDISPORT 2X2 Aniversary Edition
Connected to the MIDISPORT 2X2 is a Roland MS-1 microsampler acting as a controller for trigger input.
Note:
The nanokontrol, LPK25, MIDISPORT 2X2 and Launchpad are ALL bus powered and derive their power from their USB connectivity. This is all the more reason to use a POWERED USB Hub.
M-Audio Firewire 410 4X10 Firewire audio interface with MIDI
Connected to this is a real JLCooper CS102 surface.
MyDMX dongle is connected with a basic DMX tester plugged into it(it lights to show that there is data present) into its own USB port on the laptop. It is NOT plugged into the powered hub.
By not including the Korg nanoKEY and nanoPAD controllers into the equation, I avoid driving sharing issues, which is a valid concern.
All devices, as applicable, have their drivers properly installed and are recognized by the operating system. The MS-1 and JLCooper CS102, being true MIDI devices(no USB connectivity) DO NOT use drivers. These require that the device that provides the MIDI interface is installed properly.
Pre-testing:
First, the M-Audio MIDISPORT 2X2 Anniversary Edition was purchased to replace an MIDIMAN MIDISPORT 2X2 that was believed to be defective. Fact: MIDIMAN became M-Audio, which in turn was bought up by Digidesign, and is now as branch of AVID. It turns out through additional testing that the original 2X2 is NOT defective, but the driver for it no longer works with Windows due to some Windows update rendering the driver useless. Please be aware that this driver issue affects OTHER M-Audio USB MIDI Interfaces that use the same driver. So, be aware of this fact. The latest driver, version 4.3.00 does not address or fix this issue. COnsider yourself warned. Check the M-Audio site to see what interfaces are affected by this.
Now, theoretically, MyDMX should be able to see anything going on with MIDI because I am running it as a foreground application. MyDMX has been tested to work INDIVIDUALLY with all these controllers, but only one plugged in at a time.
Set-up:
To get lighting up on the Luanchpad, the included Automap sotware was loaded.
To ensure the equipment is working, the free program MIDIOX was used to ensure MIDI data was being seen. All devices passed this test. This means all connected equipment either generated or passed(as applicable) MIDI information that COULD/SHOULD be seen via DMX. Exit from MIDIOX.
MyDMX was launched and I went to my test scene. I use this scene for general screwing around and most important, programming MIDI.
Test Scenario, crude mode:
Choose the dimmer channel for a 64 LED Pro in EDIT mode. Right mouse click to learn MIDI. Wait.
Test 1: Hit the Korg nanokontrol, page 1, fader 4(what I normally use). NOTHING.
Test 2: Try the LPK25. Again, nothing. Although should I have gotten a success for a learned control, it would not be usable long term, but that's not what I'm testing for.
Test 3: Try MS-1. No better results. This device is going to the USB MIDISPORT 2X2 MIDI interface, just for reminders. MyDMX would not see it.
Test 4: try the JL Cooper CS102, which you will be reminded right now that this, like the MS-1, is a true MIDI device. It is connected to the Firewire 410. With faders, knobs and more to work with, nothing was seen via MyDMX.
Test 5: Process of elimination, lo and behold, the Novation Launchpad was the only device seen by MyDMX.
I'm tired, testing is stopped for now. Testing is inconclusive at the moment. Obserations say that MyDMX does have a problem listening to MIDI, and may also have an issue with USB.
All I can say is by removing a shared driver issue from my environment, it has no doubt made testing easier.
Please note the following:
I'm not posting to bash the MyDMX product. I am on the record of saying how much I enjoy the product and my position hasn't changed. I wouldn't waste my time and money testing this stuff if I didn't give a crap. But as someone who has dealt with product development and mission critical applications in addition to touring evironments, it's a part of my job to test things and in some cases BREAK things. I'm not being paid or compensated by ADJ to test this product, but I do so at my own time and expense(expense:I'm gonna buy the hardware anyways though so it's not a pure wasted purchase). In the end, it's my objective to have the product be what it's supposed to be.
Recommendations:
Althought my testing is not complete, I have the following recommendations based on the requirement and restrictin that "no new features will be added to the MyDMX product".
1: USB needs to be investigated. While my test environment is rather extreme, it does lack in a few areas. For the most part, people don't need all the insanity I am doing. But, I do have a real application where I need the nanokontrol for real time control, as well as the Launchpad for scene triggering. I would also like the option of incorporating the JL Cooper CS102 into the configuration for additional real time control. While perhaps a device like the Maschine or the APC-40 might be better options, and I could better incorporate the Launchpad to take over more functions, I prefer things to be a bit more straight-forward.
2: MIDI needs to be seriously overhauled. Any MIDI device should be able to be utilized. The current trend with USB MIDI devices will be an overwhelming choice for most users these days. While I'm old school and prefer true MIDI devices, I can't deny how cheap, useful and handy these USB MIDI devices are. They are easier to set and strike and use a lot less cables, hence are a lot more convenient. Add to this fact that they are also more varied and affordable than ever before. I mean, a $700+ JLCooper CS102 is replaced(mostly) by a cheap sub-$70 korg nanoKONTROL. Go figure.
If the OS can see the device as a MIDI device, or at least valid MIDI traffic/data, then MyDMX needs to be able to see this. Without adding more features, the concept would be that MyDMX still listens, but must also properly associate some sort of ID with the device(specifically a device ID), which is a requirement of USB anyways. It shouldn't matter if the device is a USB MIDI device or a true MIDI device hanging off a MIDI interface. The issue with MIDI interfaces is that the OS stops recognizing anything past the MIDI interface, so now it's the user's responsibility to ensure their channels and programming remains consistent, which has always been the case with true MIDI devices.
In my scenario, I can get MyDMX to listen to the 1394 MIDI interface, and individually listen to any other device, but not all at once. The MIDI issues are one set of concerns, while the USB is another set of concerns as well. If the USB issues are concerned, it may resolve SOME of the MIDI issues.(such as stuff on the USB buss), but it needs to see any attached USB MIDI devices, USB MIDI interfaces, 1394 MIDI interfaces and eve gameport MIDI adaptors/interfaces and even SM Card bus, PCMCIA interfaces and serial interfaces(I have 2 Opcode Studio 64 XTC's and they interface via serial).
More testing to follow. I am leaving out details, and the testing will only get more complex. But this one was a real fast complex text, done without the intentin of getting definitive results, just to see what would happen.
If anyone has any suggestions for testing, now is the time to speak up. I want to get to some phone calls later. Some people have questions. I may have answers. Honestly, I'd rather deal with them via email but I do what I have to do.
, so I'm not able to send a full complement of MIDI signals
Original Post