Best practices for reusable branches

[jonathanjfshaw]

In timeflux/timeflux_dsp#9 @bertrandlalo asked me to create a branch combining window, fft, expression and bands to get the power of a spectrum in bands. This might serve as an example and/or test case and/or reusable set of nodes to simplify implementing this use case.

I can imagine there are many other cases that would benefit from branches like this. There are many situations where simple basic nodes can be combined together to get a sophisticated but commonly-needed result, but it is not easy for someone who is not expert in timeflux to know the right nodes and how best to combine them.

However, I have questions about what the best practices are for creating branches like this:

1. Should branches always communicate with the rest of the graph via zmq? It would seem very easy to have a simple kind of branch that mapped the branches input/output ports to ports on the nodes in the graph within the branch. This would seem to make these branches much easier to use as if they were regular nodes.

2. Should we facilitate paramaterizing a branch (specify certain defined settings for it) without copy/pasting and modifying the whole graph of the branch? In the branch's init method with the graph loaded as as a dict we could override some parameters in the dict.

3. Should we facilitate loading a branch graph from a file? This would seem a natural approach for branches intended for reuse. At the moment the branch node has a "graph" parameter, maybe it should have a "file" parameter too.

4. Should be a "graphs" directory in timeflux packages alongside the "nodes" directory? If we are providing graphs as files, and they are intended for use rather than simply tests or examples, we need somewhere to put them.

5. Should the branch node be in timeflux/nodes instead of timeflux/core? It's really just another kind of node.

Let me know what your wishes are and I will be guided by them. If necessary I can create a new branch node class to implement these features.