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
In #9@bertrandlalo gave me valuable guidance on how best to setup spectral nodes, and we decided one or more branches would be useful to demonstrate how best to work with spectral nodes.
There are 3 kinds of question we have to resolve about this:
What is the purposes of the branch(es)? Is it documentation, is it a test, is it a toy demo, or is it something that is intended to actually be resused directly (not simply copy/pasted) in real production graphs to facilitate development.
What are the best practices in timeflux for branch construction. This especially matters if we're trying to make a truly reusable branch. I created Best practices for reusable branches timeflux#56 to resolve this question.
What are the spectral branches we need? Aspects of the pipeline include dejitter, window, fft/welch, bands, and extracting power or real numbers.
The text was updated successfully, but these errors were encountered:
My current ideas for the answers to these questions are:
Truly reusable branch components to simplify the implementation of complex tasks in timeflux seems like a good idea to me. They naturally function as documentation, examples and tests too.
As discussed in Best practices for reusable branches timeflux#56 I'm interested in the idea of defining branch graphs as yaml files in in a "graphs" folder. But in order to allow our branch to be parameterizable we will probably need to have a node class for it in spectral.py
Welch is great for post-processing the data during analysis after a session, but for real-time decision making of the kind that Timeflux is suitable I'm imagining that you usually want only the most up to date information and for that FFT is fine, so is the more common in timeflux use?
Power conversion / real number extraction troubles me. It seems really important, but it' quite esoteric and it's not easy to get information on it via Google. Maybe it should be a branch of its own, even if only that wraps a single apply node, in order to document how best to approach it.
I'd love to have a branch that handles dejitter, window, fft, bands and power. I'd like it to have parameters for: rate, window (in time or samples), bands, whether dejitter is needed, and whether power is desired.
In #9 @bertrandlalo gave me valuable guidance on how best to setup spectral nodes, and we decided one or more branches would be useful to demonstrate how best to work with spectral nodes.
There are 3 kinds of question we have to resolve about this:
What is the purposes of the branch(es)? Is it documentation, is it a test, is it a toy demo, or is it something that is intended to actually be resused directly (not simply copy/pasted) in real production graphs to facilitate development.
What are the best practices in timeflux for branch construction. This especially matters if we're trying to make a truly reusable branch. I created Best practices for reusable branches timeflux#56 to resolve this question.
What are the spectral branches we need? Aspects of the pipeline include dejitter, window, fft/welch, bands, and extracting power or real numbers.
The text was updated successfully, but these errors were encountered: