Hi Claude,
is there a way tu remove d2xx helper and all the d2xx drivers at one time on my computer ?
Since a few days, i have some issues when using LX Console with an Enttec Open Dmx Usb ("d2xx connection error : FR-DEVICE-NOT-FOUND").
I would like to try a "clean install" of Lx Console & D2xx helper before searching elsewhere.
Here is a screen copy of my d2xx library in the Terminal app :
MBP13DUDU:~ christophedurand$ cd /usr/local/lib
MBP13DUDU:lib christophedurand$ ls
audacity libartnet.dylib libftd2xx.1.2.2.dylib
ftd2xx.cfg libftchipid.0.1.0.dylib libftd2xx.1.4.4.dylib
libartnet.1.0.1.dylib libftchipid.dylib libftd2xx.dylib
libartnet.1.dylib libftd2xx.1.1.12.dylib
My configuration :
MacBook Pro early 2015 whith macOS Big Sur 11.3.1, LX console 5.8, LXNet2USBDMX when using a Enttec open dmx usb
Thank you in advance for your reply.
d2xx drivers conflicts ?
Both current versions of LXConsole and LXNet2USBDMX are soft linked to libftd2xx.1.4.16.dylib at the path:
/usr/local/lib/libftd2xx.1.4.16.dylib
For the ENTTEC open dmx usb, the d2xx output from LXConsole does not work and should NOT be enabled. Instead, the Art-Net output of LXConsole must go to LXNet2USBDMX which then creates a serial stream which the ENTTEC open dmx usb converts to RS485 (DMX).
Your output from the ls command does not show me which of the libftd2xx.* files are actual dylib files and which are symbolic links. But, importantly, it does not appear that the d2xx driver that LXNet2USBDMX needs is installed.
The LXConsole installer used to contain the version of the d2xx driver that it needed. But, this is no longer the case. With the transition to Apple Silicon processors, support for d2xx is anticipated to be removed from LXConsole entirely (along with µDMX support which requires an old version of libusb). LXNet2USBDMX is not anticipated to be Apple Silicon native and will be the way to connect with µDMX and Open DMX USB devices when LXConsole becomes Apple Silicon native. (It is the only way to connect LXConsole with Open DMX USB now...)
To solve your problem, you can either locate a copy of libftd2xx.1.4.16 and install it. Or, quite likely you can duplicate one of the versions you already have and name it libftd2xx.1.4.16.dylib. Be sure that you duplicate the actual dylib and not a symbolic link that points to a dylib. You want to be careful that two different applications are not using different versions of the d2xx driver at the same time. But, as long as you are careful about that, you shouldn't have a problem with multiple versions in /usr/local/lib.
/usr/local/lib/libftd2xx.1.4.16.dylib
For the ENTTEC open dmx usb, the d2xx output from LXConsole does not work and should NOT be enabled. Instead, the Art-Net output of LXConsole must go to LXNet2USBDMX which then creates a serial stream which the ENTTEC open dmx usb converts to RS485 (DMX).
Your output from the ls command does not show me which of the libftd2xx.* files are actual dylib files and which are symbolic links. But, importantly, it does not appear that the d2xx driver that LXNet2USBDMX needs is installed.
The LXConsole installer used to contain the version of the d2xx driver that it needed. But, this is no longer the case. With the transition to Apple Silicon processors, support for d2xx is anticipated to be removed from LXConsole entirely (along with µDMX support which requires an old version of libusb). LXNet2USBDMX is not anticipated to be Apple Silicon native and will be the way to connect with µDMX and Open DMX USB devices when LXConsole becomes Apple Silicon native. (It is the only way to connect LXConsole with Open DMX USB now...)
To solve your problem, you can either locate a copy of libftd2xx.1.4.16 and install it. Or, quite likely you can duplicate one of the versions you already have and name it libftd2xx.1.4.16.dylib. Be sure that you duplicate the actual dylib and not a symbolic link that points to a dylib. You want to be careful that two different applications are not using different versions of the d2xx driver at the same time. But, as long as you are careful about that, you shouldn't have a problem with multiple versions in /usr/local/lib.