Emax

>>>>One thing - you already have EII comms working with a standard 
off the shelf USB connector, don't you???
<<<<
Yes I have, but it works only for sending banks from the EII to the 
PC, not the other way around, due to the synchronization loss... 
which was the reason why I posted this RS422 questions to Emu 
groups :-)

I you'd like to have the example C code I used for this and/or for 
the Emax bank unload, I can send them to you.
The Emax code "works" but as I mentoned before the communication gets 
out of sync after receiving about 40 datapackets, due to the lack of 
sync comm.
The code contains basically the port configurations (baudrate, 
parity, ...) and the open/read/write/close instructions to perform 
the actual communication. It uses the standard serial communication 
library of Microsoft (Visual C), based on things like DCB 
configuration. In these communication libraries I haven't found any 
structure/function yet which allows to set the baudrate to "external 
clocking" instead of a "number" (internal clocking).
But perhaps the provided software with your device can be driven in 
another way, allowing for other parameters sent accross the USB 
serial class.

...So we stay "on" topic in this board with the Q&A about RS422 and 
the experiments to get the thing working for Emax ?

///E-Synthesist

--- In emax@yahoogroups.com, mr julian <jujulilianan@...> wrote:
>
> first up, I know NOTHING about the windows driver side of this... I 
just 
> installed a driver that was supplied with the firmware, and I can 
see 
> that in windows system, it's come up as a generic serial port, with 
> settings for:
> 
> Bits per second: (75-128000)
> data bits: (4-8)
> parity: (odd, even, none, mark, space)
> stop bits: (1, 1.5, 2)
> flow control: (Xon/Xoff, hardware, none)
> 
> Also, I can open and close this port in hyperterminal, and adjust 
the 
> settings in hyperterminal.... 
> 
> Now, I imagine that wheen it is connected to my PC, this port gets 
> listed somewhere inside windows in an appropriate place, and 
> applications looking for serial ports find its information, and can 
then 
> request to connect/disconnect, and and send config information - 
just 
> like any other serial port.... but if I needed to add extra 
> functionality, like a synchronous BPS setting, I have no idea where 
to 
> put that... but maybe I could find out?
> 
> I'm still waiting for the 422 chips, so will start seeing what I 
can 
> find out about the driver, and the application-driver interface, 
plus 
> the driver-board  interface. and see what would need to be modified 
to 
> make this do exactly what we want.
> 
> But yeah. my ideal finished product would be a USB connected board 
that 
> connects to a PC, and windows sees it as a standard serial 
interface 
> with standard interface parameters including synch/asynch control 
> (whatever standard for that is!) and your program could therefore 
> connect to it just like it would connect to any other serial 
interface, 
> and work with it the same way for any sampler....
> 
> Also, I'm not interested in holding any kind of IP here - I'm 
really 
> just mucking about with configuration and possibly making small 
> adjustments to existing open-source code...... if I create a 
solution, 
> I'll provide all assembly instructions/code completely open for 
anyone 
> who wants to use it however they wat.
> 
> One thing - you already have EII comms working with a standard off 
the 
> shelf USB connector, don't you???
> 
> 
> 
> anyway - we should probably take this discussion off-list. it's 
getting 
> a bit OT for the emax community in general I think.
> :-)
> 
> 
> 
> esynthesist wrote:
> 
> >OK :-)
> >What are the parameters that *can* be changed with the standard 
> >driver ? Nothing ??? Isn't it possible to define parity, or 
clocking 
> >by software? If this is true, how can you change these parameters 
> >then ? I'm not sure I understand.
> >
> >I mean: as soon as I can write a piece of C-code (based on sample 
> >code provided by you of course ;-), which uses the standard USB 
> >driver library, but which contains specific Emax code, that's fine 
> >for me; then it's just a matter of writing another piece of code 
for 
> >each Emu sampler we want to support. I was not hoping for more.
> >But if the *hardware itself* is built in such a way that it only 
> >supports the Emax, then we would need another piece of hardware 
for 
> >the Emulator II, and that would be a shame...
> >
> >But I guess it will all be software-driven, right ?
> >
> >///E-Synthesist 
> >
> >  
> >
> >  
> >
>