Andrew,
are you sharing the source code for the driver?
Andrew,
are you sharing the source code for the driver?
not at this time, it is a very generic driver though that works with any sound card and any software that supports easylase. Do you have an improvement suggestion?
Well, not an improvement, just a thought really but it will make it easier when people have access to your code.
It may facilitate programmers out there to have a universal API for writing to the DAC. So if your driver could be adapted to talk to other hardware like mocha, medialas and what else is out there, then the application programmers just need to talk to one API (the easylase in this case) and the user selects the driver according to the DAC he's using. I think that most DACs work alike (apart from pango maybe) so there could be a real benefit for the community - programmers have a larger audience and everyone has more programs to play with.
I don't think his code would help any in that regards. There is already a generic driver model out there that can be followed. Just look at the Mamba driver model. The MLD files are nothing but DLLs with a standard set of methods that are defined to work with Mamba. As long as you implement those methods in your DLL, Mamba will be able to communicate with your driver. DrLava did something similar by implementing the exact same methods that EasyLase does. This allows any software that can talk to EasyLase talk to his driver.
You are right those most DACs work about the same. All the ones supported by Spaghetti are almost identical externally. The APIs are slightly different but that's about it.
I am not quite clear what you are looking for but am interested. It would certainly be helpful for me if there was a common driver model for DACs so that I could simply detect and load any new drivers without writing code. But, there still has to be some customization at some level. For example, for the sound card DAC I have a custom screen that allows setting the sample rate, delay time, and channel information. For the RIYA DAC I have a custom screen to set the IP address. It probably makes the most sense for these types of things to be set outside of the laser software application. Probably from some utility application or maybe as a Control Panel applet. The main hurdle is getting the hardware manufacturers to buy into this common philosophy. Otherwise, it would be up to us to write and maintain wrappers, like the MLD mamba wrappers, for all the different drivers.
I created a C template for creating MLD driver wrappers when I wrote the Moncha mamba wrapper that I could give to you if that would help. It's nothing more function definitions, though. Nothing that anyone couldn't come up with on their own. I also have the code for the Moncha driver I wrote that I could share with you.
The aim would be to intergrate as much hardware with as much (homebrew) software as possible with the least amount of effort. Maybe one way to go would be to interface homebrew software (laseroids, spagetti, etc.) with the mamba layer because many hardware drivers already exist that the mamba layer can talk to. It would require an API to the mamba layer though, is that available?
Hi, well now that I have my X and Y going fine, I started to work on the blanking. I have the op-amp circuit going OK, but the thing is, my CNI laser requires some other weird signal to work?? I think it may be either a - signal, OR just a signal on the - line. Any idea's??
Cheers