Hamming

With the possibility to scale each signal.
Maybe as a starting point create universal node which will take any closure as a summary definition?

Why do you have two identical tests in the generators module?

As far as I can tell, the num-complex crate is not re-exported by dsp. This means that working with complex numbers directly requires tracking dsp's version manually in Cargo.toml.

I would suggest putting pub use num_complex in lib.rs and having the other modules pull it from there.

To change the sample rate of the signal.
Resampling should require that both signals have the same sample_rate. Otherwise return 0 (Not correlated).

To correlate 2 different signals.

And use it to create chirp generator.

Load binary data from a file. The format should be compatible with GNURadio

Generate data from vector.
We can then generate data longer then vector by repeating data from vector

Some source can have infinite number of samples, same like files are finite.
It would be good to know when all data was read and there are no more samples.
This can be fixed with SourceNode::write_buffer Returning boolean value indicating if source finished generating its data (wrapped as result)

Processing node for multiplying each sample with constant value

It doesn't find correct tone in provided examples.

I noticed that when adding the dsp crate and running cargo build, I got a large number of crates to build. It appears to be primarily transitive dependencies of the rand crate, which is a required dependency in dsp.rs. It is only used in generator.rs.

Is it possible to move the rand dependency to a feature (which may be on by default), so I can turn the feature off and reduce build times?

Notes on features:

https://doc.rust-lang.org/cargo/reference/features.html
https://doc.rust-lang.org/reference/conditional-compilation.html

Nodes operate on the frames (buffers). This means that they are good for SIMD optimisation.

Also add benchmarks to measure the speed gain.

Generators are able to generate data faster then required. For example when the sample rate is set to 512 we should only generate 512 samples per second. This should be optional

What do you think of relying on an external linear algebra crate for the Vector representations and operations?
In this way, we could benefit from performance optimizations applied to the external crate.
Moreover, I think at a certain point we could face the need for Matrices (I am thinking, for example, to the implementation of the STFT) that for sure would be provided by the library.

Extend sine generator for complex numbers

Read binary data from the socket. The format should be compatible with GNURadio

Data can be provided as Vec and can be looped or generated only once.

Vector and finite discrete signal is not always the same.

Spectrum is 3D data. And most often is plot with coloraturas as 3rd dimension.
There is example spectrum.rs which only plots line with max frequency. It would be nice to improve the graph used by this example to use colors instead of line.

To write data into a sound card.

This will help to create finite length generators and stops processing when the generate all its data.

Add node to calculate zero crossing in the signal. Remember to calculate it over different buffers

This can be tested with:

cargo build --target thumbv6m-none-eabi 

Things to fix:
[ ] FFT crate doesn't support no_std. Maybe use https://gitlab.com/teskje/microfft-rs ?
[ ] Add libm for floats

From the spectrogram it looks that there is a problem with the Chirp generator. The end frequency is too high.

Similar to plot.

The library is designed for creating graph of nodes for frame processing (real-time like).
But it needs better documentation in README.md and rust doc.

Measure how many samples per seconds can generator create.

Signals of infinite length, where we can only access past values.

Update Spectrum example

Save binary data into a file. The format should be compatible with GNURadio

• Convert signal into frequency domain
• Remove given frequencies (make them 0)
• Convert back to time domain

Add SignalGen::new()

Write binary data into a socket. The format should be compatible with GNURadio

Command line application which will allow to filter data, find heart beat rate etc.

Before next publish prepare first version of the documentation

This generator should be based on defined number of sinusoidal signals.
Ideally it should get list of sine frequencies and list of weights.