You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Slack user reported that the most recent 'release' didn't work for them.
build_mex completes, and making sure the liblsl-matlab/bin is in the path - still getting an "Error loading the liblsl library: Exiting now. Make sure liblsl-Matlab/bin is added to path and try running build_mex.m"
it seems the problem is in lsl_loadlib_ (the MEX-file) which throws "Error code: 126"
Temporary solution - downloaded an older version (1.13.0-b11) and extracted only the liblsl64.dll file, replaced it, and now it works...
This is an all-too-familiar problem when there's some minor difference that prevents liblsl from working with a new version of Matlab. Typically a recompilation of liblsl on that specific machine is required, but in this case one of the older release libraries happened to work.
liblsl-Matlab would really benefit from a continuous integration solution. Apparently Azure DevOps and CircleCI now have Matlab support!
Unfortunately, the cloud-hosted machines only support Matlab using Linux images. So that makes this pretty low priority because it's Windows where we encounter the most problems. Until then we will just provide releases on demand. And maybe I should update the instructions a little to make it clear that the user should try building liblsl themselves.
The text was updated successfully, but these errors were encountered:
It could be that the machines will start hosting Windows as well in the future, especially if Azure is doing it. But I wouldn't hold my breath for OSX.
I still have this dream that one day Mathworks will do this for us so that we don't have to deal with it, but that's kind of like the frog who dreams of wings to spare itself a sore bum. Unfortunately Matlab moves fast and stampedes over 3rd party libraries. Talk to the EEGLAB people if you want to hear some hair-raising tales of keeping up with the biannual Matlab release and count your blessings that we don't do anything with graphics.
Until things progress, I think this is just going to have to stay a pain point. The vast majority of LSL users are not going to be able to build liblsls themselves or even set up their machines with development features that Matlab can hook into to build the mex files.
I've modified the instructions in the README to tell users to first try downloading a release, and if that doesn't work then try building it themselves, with some extra words of encouragement. This includes a few different options for getting liblsl, the first being "do nothing and let liblsl-Matlab download it for you when first needed". I just tried it and it still works.
A Slack user reported that the most recent 'release' didn't work for them.
This is an all-too-familiar problem when there's some minor difference that prevents liblsl from working with a new version of Matlab. Typically a recompilation of liblsl on that specific machine is required, but in this case one of the older release libraries happened to work.
liblsl-Matlab would really benefit from a continuous integration solution. Apparently Azure DevOps and CircleCI now have Matlab support!
Unfortunately, the cloud-hosted machines only support Matlab using Linux images. So that makes this pretty low priority because it's Windows where we encounter the most problems. Until then we will just provide releases on demand. And maybe I should update the instructions a little to make it clear that the user should try building liblsl themselves.
The text was updated successfully, but these errors were encountered: