The examples have no issues detecting and connecting to the device. I made a little library to wrap the OpenDMX object and also the following super simple test code:
static void Main(string[] args)
{
var openDmx = new OpenDMX();
openDmx.start();
openDmx.setDmxValue(1, 255);
Console.ReadLine();
}
Ran from VS this connects to the device and outputs full value on channel 1 for a brief period. Works fine.
start() connects to the device using FT_Open() which receives the device handle (this should stay valid for the duration of the session)
this in turn starts the initialization that uses the handle to do a few init operations on the device
The handle stays valid when ran from VS but somehow when running from VL the connection still performs fine but somehow the handle is not valid for any subsequent operations (debugged with breakpoints). Any idea where this discrepancy could be coming from?
Sidenote: The original implemention has the class and its methods as static but that did exactly the same and looked like a complete mess in VL (floating nodes with no inputs).
Here’s the library/documents even though I assume it might be slightly tedious to test without the device itself
For this document to load properly the previous document needs to be loaded before. VL doesn’t reference stuff when only used in a Script region? OpenDMXWrapperScript.vl (4.0 KB)
this concept is not really correct, since all methods are static. usually such (non-static) wrappers get and encapsulate the handle by acquiring one on create and implement IDisposable to correctly release the handle. so you have an instance that calls the native static methods on the handle, but looks like a non-static class from the outside.
like this you try to create a new handle each time you call start(), which might be invalid since usually a process can do this only once per life time. to do it a second time, the first handle needs to be released or the vvvv process needs to be restarted.
similar to this, but create the hand in the constructor:
The native dll imported methods are static yeah, but the handle is being kept with the object and I’m calling the start only once. I put it into the constructor and implemented a Dispose that closes the handle but it’s not really helping and I’m not surprised either. As I said I already had it fully static before, it just looked like a mess.
And even if the process isn’t 100% correct now as I’m just trying to get the absolute basics to work I fail to see the difference between the code in VL and C#. And still in C# it’s working absolutely fine while in VL the handle becomes unusable right away :(
Seems like it’s a 64 vs 32bit related issue, tested in 32bit alpha and the behavior seems better, the handle keeps being valid even though output still doesn’t work but I’ll probably figure that out. I’ll try to see if there’s a 64bit version of the library, I thought it just wouldn’t load otherwise but it did. If the handle refers to a memory location then it does make sense.
