At 12:33 PM 7/23/2008, Frank Brickle wrote: >On Tue, Jul 22, 2008 at 5:22 PM, Jim Lux ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: > >The question is really do you want to play at the Firewire/Midi >message level, or at the PowerSDR API level. The midi message level >seems fraught with peril, since it has to play nice with the midi >messages between PowerSDR and F5K. > > >Let's go through this again, slowly. > >Regardless of the fact that -- at present -- the F5K MIDI ports are >visible from Windows, in principle and in the future the *only* >exposure of the F5K internals is through a set of virtual resources >that are not yet available to the public, as of July 2008.
I don't think there's any disagreement here... I was referring to today's F5K with today's Windows drivers. Obviously a future version of PowerSDR (or whatever) might do things differently (including not using MIDI over firewire.. it could use some other messaging protocol over firewire, for instance), and might decide to provide a virtual MIDI (or other) interface to other programs (just as PowerSDR provides a serial port interface for CAT). So, regardless of what the PC side does now or in the future, for now, barring a firmware revision, if you have an F5K, you could write your own controller that works with the MIDI messages, as now defined in the source code. I don't make any claims that this is a sufficient body of knowledge. There could easily be operating details in the interaction between host and F5K that aren't obvious from the source code nor documented anywhere. Maybe there's some critical timing interaction, for instance. A possible implication of your statement above is that a future revision of the F5K firmware will "hide" or remove the MIDI control functionality, and the equivalent function (performed however it's done in the rev) will be exposed as virtual resources (which will be published). This would have the effect of killing off the work of anyone who was ambitious enough to write their own MIDI control app (which I suspect will be nobody). It would also mean that a change in the existing PowerSDR that, say, exposed I2C control functionality with CAT commands that use the existing API calls in console/FWC, would also stop working (as would old versions of PowerSDR in general). Or, the MIDI style interface might still exist, but the opcodes for I2C_WRITE and I2C_READ would go away. This isn't particularly surprising.. often firmware and software upgrades have to go hand in hand for compatibility, and maintaining total cross version compatibility is often more trouble than it's worth. After all, there's no guarantee from Flex that the F5K control interface definition (which isn't published in any case.. only inferred from the source code) is going to be constant. This is unlike the SDR1K, where the interface is literally fixed in hardware. Flex's only obligation is to make the source code available, not to keep the interfaces constant, nor even understandable or open. If they wanted to implement a encrypted handshake, they're free to do so. (I just got out of meeting where we talked about two factor authentication, X.509, Kerberos, etc.. so it's on my mind) Jim _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/