Create a Stream Metadata class

[toni-neurosc]

There are many lines of code dedicated to retrieving and fiddling with data that is inherent to the input stream/file itself (e.g channel names, sampling frequency) and not with data processing settings. This means it should not go into the Settings class, but rather than having it floating around in pieces I think it would be better to calculate it once in a single, well-localized place and then look it up in the same place always.

Also when we handle more types of files/datastream formats, there will be a bunch of optional metadata that we potentially might want to handle. LSL adheres to XDF standard it seems: https://github.com/sccn/xdf/wiki/Meta-Data

Having the metadata atomized like it's right now also makes it difficult to construct Preprocessors generically like I did for Features. For example, if one takes the channel names but the other one doesn't.

Another added bonus is that it will probably help with GUI design too. For example for sure one of the key metadata pieces the stream will have it's whether it's a file or a datastream.

[toni-neurosc]

Well, so actually that is already a class in MNE-LSL as I should have imagined in the first place: https://mne.tools/mne-lsl/stable/generated/api/mne_lsl.lsl.StreamInfo.html#mne_lsl.lsl.StreamInfo#302

So I imagine when PNStream is replaced by StreamLSL we will get access to all the LSL goodies including this one.

[timonmerk]

Thanks for addressing this point @toni-neurosc. Given that the lsl.StreamInfo class exists all of the necessary information for py-neuro Stream initialization would be already available right?

Practically that would mean @SamedVossberg that once you are retrieving the live lsl stream

py_neuromodulation/tests/test_lsl_stream.py

Line 182 in 8890c99

ch_names = [f"{i}" for i in range(8)]

you could automatically retrieve the info such channel names, types etc. are obtained from the lsl.StreamInfo object.

On a different note, to prevent that the branches diverge too much from another, please merge the changes done by @toni-neurosc once he made the PR merge from #305 into main. That will probably affect quite a lot of files, so it would be great to keep working on a similar code setup, that resolving the merge conflicts won't be too challenging.