The current implementation doesn't abstract the message collection from the end user.
This of course gives maximum flexibility, but based on work in liblsl_coordinator, a general polling isolate might be useful and messages can be sent and consumed via streams.
The upside would be easy LSL message handling, the downside of this method would be that a buffer would need to exist on the isolate side and the buffer pointer can be passed to the main isolate (then turned into an LSLSample).
This design shouldn't require too many deep level changes, but maybe should exist as an alternative class hierarchy...if so then there would be some refactoring to avoid code duplication in LSLInlet etc.
The current implementation doesn't abstract the message collection from the end user.
This of course gives maximum flexibility, but based on work in liblsl_coordinator, a general polling isolate might be useful and messages can be sent and consumed via streams.
The upside would be easy LSL message handling, the downside of this method would be that a buffer would need to exist on the isolate side and the buffer pointer can be passed to the main isolate (then turned into an LSLSample).
This design shouldn't require too many deep level changes, but maybe should exist as an alternative class hierarchy...if so then there would be some refactoring to avoid code duplication in LSLInlet etc.