Review requirements and high-level goals for design package

[glopesdev]

This is to keep track of high-level development goals for the design package. Some ideas below:

• Reduce amount of custom UI code and split off reusable functionality for future cross-platform GUI.
• Review links between UI and expression builder properties to avoid excessive compile-time latency.
• Review visualizer requirements for NPX and other devices (e.g. run shaders visualizer in separate GL window).

The above can be split-off into separate issues and evolve with future discussions.

[jonnew]

There are several high-level issues that need to be taken care of in this refactor. Each of these probably deserves its own topic. I'm going to summarize what I have written here. This is not exhaustive.

Fitting the intended usage of both Bonsai and liboni

1. Bonsai is a programing language with build and run times. Bonsai.ONIX abuses this currently but performing lots and lots of hardware access during built time. The reason for this is that we want users to be able to control device configuration (e.g. sample rates, filter settings, probe configuration) before they run the workflow. However, this has caused lots of issues since its in opposition to the intended use of the Bonsai. We need to resolve this situation both from a performance perspective (since every hardware access involves setting up and tearing down a lib ONIContext) and just to use Bonsai as it was intended. One idea wa to cache changes in hardware state (Node Properties) and then apply them at the beginning of runtime. situation is that changes to hardware state

2. liboni is a low-level, hardware agonistic library for general purpose data streaming. Its design follows the principles of other libraries built for similar purposes (e.g. sockets, serial IO, etc). An opaque, unique context holds is created one to one with a piece of host hardware. It links the hardware to the API via a dynamically loaded driver. It is meant to be opened and closed infrequently. Currently a context is created and destroyed for every single access to a hardware property outside of runtime which is the complete opposite of its intended usage.

Changes to the library are needed to resolve both of these related issues.

Robustness against hardware configuration changes outside of runtime

A part of opening a liboni context is to build up a table of devices connected to the hardware and their location (as defined by their local clock source). For instance a list of data sources and sinks on the local hardware (hub 0) and another list of devices on a headstage (hub m). Currently, and related to the first issue, the library is extremely fragile when changes occur to the device table outside of runtime. For instance, if as headstage is disconnected or connected to another port, an old Bonsai workflow will fail to load because the addresses of devices within the table have changed. Ultimately, it would be cool to have absolute ID information associated with device hubs (unique serial number) that would make these types of changes easy to handle automatically. In the interim, it would be good to at least load a workflow without error and throw a device address mismatch exception during runtime.

Ease of use & docs

As you stated, there should indeed be a review of visualizer/core functionality decoupling. We would also like to take advantage of the integrated documentation functionality that comes with 2.7.

[glopesdev]

I think these are fine to discuss together for now. The only one I will split off is the last bit on docs, as this is tracked on #5.

[glopesdev]

In the interim, it would be good to at least load a workflow without error and throw a device address mismatch exception during runtime.

I agree, and I think this will be immediately solved if we simply remove all hardware access out of the expression tree compiler. I will try to outline a proposal to do this in a new comment below.

[glopesdev]

@jonnew Actually, I just realized we were discussing these bits in the design package, but I would actually like to move them into the main package requirements, tracked in #3. Once we agree on the general architecture, I think it will make it easier to think about the requirements for the design package.