Nexus Meeting Notes 2016-11-04
- I created a "dashboard" page on the GPII wiki for tracking Nexus pages: https://wiki.gpii.net/w/Nexus_Dashboard
- Update on Antranig's Nexus work
- Update on discussions at Cyprus and potential work to make whole of AsTeRICS model component values available via API
- Face-to-face Feb 2017
- Be ready with what we want to show at the review in March
- Review April 2017
Update on Antranig's Nexus work
Goal for review:
- Connect to Nexus with browser-based client
- View tree of Nexus components
Longer-term, working towards an authoring environment.
State that needs to be established by configuration:
- Peers constructed
- Peer component path
- Peer grade name(s)
- Model relay rules relating peers
- Component paths of source/target peers
- Model paths of source/target peers
- Relay rules
- WebSocket bindings between peers and external devices
Current process to establish above state:
- Peers are constructed explicitly and separately from establishment of WebSocket binding
- Integrated things need to implement the Nexus WebSocket protocol and must be configured with Nexus and peer location:
- Machine address on which Nexus is running
- Nexus port number
- Path of peer in Nexus
The aim of the discovery work is to simplify or remove the work needed to establish a working configuration:
- Listening or watching for the appearance of devices
- local network
- Adapters or bridges for devices with standardised protocols
- MIDI controllers
- RTP Midi: https://www.npmjs.com/package/rtpmidi
- Timing/synchronization protocols
- Abelton Link: http://ableton.github.io/linkkit/
- Korg WIST: http://www.korguser.net/wist/
- Clock Synchronization for Interactive Music Systems: http://opensoundcontrol.org/files/dannenberg-clocksync.pdf
- We should check up on the status of peer projects such as
- Node RED: http://nodered.org/docs/
- Their "nodes and flows repo" at http://flows.nodered.org/
- Their existing discovery system https://www.npmjs.com/package/node-red-node-discovery "uses Bonjour/Avahi"
- Distributed Node RED: https://github.com/mblackstock/node-red-contrib
- IFTTT: https://ifttt.com/
- Apache NiFi: https://nifi.apache.org/
- Microsoft Flow
- Choose between Flow, Logic Apps, Functions, and WebJobs: https://azure.microsoft.com/en-us/documentation/articles/functions-compare-logic-apps-ms-flow-webjobs/
- Node RED: http://nodered.org/docs/
- Creation of peer upon discovery/detection of Nexus/device (see below for more discussion)
- Configuration of model relay rules for known about sets of devices (with UI prompting)
- A MIDI keyboard is plugged into a computer running a synthesizer
- A UI is displayed offering options on how it should be configured
- Someone brings a personal tablet into proximity with a kiosk -- the kiosk may be operated from the tablet [this was oringially an idea from Cloud4All and we would need to check with Gregg and Matthias to check and see if it would be suitable for a P4A demo]
- => HELP <=
If we stick with music, could we integrate Tony's music work?
- Music notation visualization
- Highlights as you play the melody (maybe does not move on to the next note if you don't hit the right one)
Single switch sequencer
Mobile smart single switch that pairs with GPII enabled device.
We need to distinguish Nexus from AsTeRICS:
- Discovery and auto-configuration
Demo idea: show Antranig's visualizer during discovery: see configuration being automatically added
- Model relay rules configured within peers or external from them?
- Example of external rules: https://github.com/simonbates/nexus-experiments/blob/master/modelRelayInSibling.js
- Example of internal rules: https://github.com/simonbates/nexus-demos/blob/master/demos/constructNexusPeers.js
- Who constructs peers?
- Done as part of the discovery process?
- How to differentiate between multiple connected things of the same type?
- We can give them different peer names but the name must be communicated so that it can be used when establishing the WebSocket connection
- --> The "co-occurence engine" will construct the peers. Relay could be either internal or external to the peer definition itself, since this will be a detail that can be configured in the "co-occurrence recipe specification"
- --> "co-occurrence rules" will have a semantic/structural form a little as if they were kinds of RegExps targetted against the entire tree (thankfully we will express them as JSON to avoid the horrour that is PARSING)
- ----> A kind of "prior art" in a kind of distant cognitive sense is the *SMIRKS REACTION TRANSFORM LANGUAGE* : P http://www.daylight.com/dayhtml/doc/theory/theory.smirks.html - in that this is a dialect expressing the possibility for co-occurrence of CERTAIN THINGS in which the result is the instantiation of OTHER THINGS
- ----> Our situation isn't quite as complex as SMIRKS since we don't propose the destruction of the reactants (we will consider these immutable as most things morally are in Infusion), but nonetheless we will need some kind of cognate of "capturing groups" that will allow specific elements in the reaction products to bind onto particular elements in the reactants
- How to know what types of things are connected?
- Grade of peer?
- Contents of peer model?
- Some other component property?
- A device registry that is separate from the peers? (device registry wouldn't contain relay rules or other details on device relationships)
- --> Yes, there will be a device registry mapping "things which can appear on buses" to concrete peer definitions. As per our earlier discussion this will constitute a form of "device driver" for the things (e.g. looking up PCI hardware vendor ids, device classes etc.)
- Is it possible to alter the model relay rules of an existing component?
- --> not quite sure what is meant by "alter" but in terms of "at runtime", no. These rules are set up at construct time and torn down at destroy time. However, they can be overridden (if namespaced) by derived grades (Simon: yes, I was thinking "at runtime", thanks)
- What about when things disappear?
- How is disappearance communicated?
- How are the peer relationships updated?
- What about unreliable connections that come and go?
- --> I imagine there will be "policy definitions" for which some defaults will appear in the device registry (e.g. "no reconnection for x seconds means destroy the peer") but which can be overridden by the user on some kind of class-based basis (e.g. a preference with respect to "communication over buses of a certain type" or with respect to (GPII) contexts - this will represent a standard kind of preference in the GPII ontology)
- --> If any of the prerequisites for a "co-occurence rule" fail to be met (as a result of the peer being destroyed), the actions of the rule will be undone - that is, anything which it constructed will be destroyed
Longer term, we will want a "device driver" repository, which we could integrate with the QI.
Have a Design Crit for brainstorming use cases / demo ideas for the Nexus: explain discovery and what it will enable.
Peer constructed by device driver
Recipes that need particular types of things, would have holes where concrete components are placed -- a "holder" for a particular type of thing that includes the model relay rules relating the component to peers within the recipe.
For example, a device driver makes a "cheese" peer and a co-occurrence engine recipe includes a "cheese holder", with model relay rules for connecting the "cheese". When some "cheese" becomes available, it is placed in the "cheese holder".
Probably the best API point we have currently for implementing this "dynamic injection" is "recordKnownComponent" here - https://github.com/fluid-project/infusion/blob/master/src/framework/core/js/FluidIoC.js#L1014 There should be a Nexus API for this (perhaps a variant API of "fluid.construct") but we don't have it You can see this API being used in this capacity at the point where we construct "injected subcomponents" in fluid.initDependent here: https://github.com/fluid-project/infusion/blob/master/src/framework/core/js/FluidIoC.js#L1357