Feature request: `.load_recording()`

[cwindolf]

Idea: it would be nice to have a function load_recording(path, stream_id=None, type=None) (or similar) which implements an if tree internally to try to guess what format a recording is. I wanted to open an issue where we can think about whether this is useful and what it could look like.

The motivation would be cases like writing spike sorting CLI tools. This function would make it possible to implement recording loading in GUI and CLI tools. Currently, tools need the user to pass in a BaseRecording of some kind, meaning that most tools rely on the user calling si.read_X() and launching the tool from within Python. For example, spikeinterface-gui takes this approach, but it could use this to implement a GUI path selector, and it could then be run from the command line or a launcher instead of from an interactive Python session. This could also make it easier for users to write format-portable scripts and make things easier for non-technical or non-python-savvy users. Future works could extend this to loading sorting outputs or other extractors.

API: not super sure. Sometimes a stream_id will be necessary; maybe in the common case where both LFP and AP are available, the AP stream can be chosen by default, or there could be a prefer_ap type flag? I imagine that some formats are ambiguous, so maybe a type= flag might be needed to allow users to override in those cases. I think it's okay if there are rare cases which are not handled by this tool.

Implementation: I think this function can start by calling load_extractor() and move on to other cases when that fails? It can raise a detailed error message in failure cases indicating that the path didn't match any of the formats tried (listing them), or it can let the format-specific loader functions raise errors about stream_ids and that kind of thing.

Curious if people have any thoughts!

[samuelgarcia]

Alessio just started to make a magic load() function that load recording/ssorting/analyzer.

Here you propose a magic read() that would be multi fromat with auto guessing. Good idea.

Then maybe the load coculd also internally make a try to this read().

Lets make some examples here.

[JoeZiminski]

Great idea!

[cwindolf]

Maybe if somewhere there existed dicts like

format_test_functions = {'spikeglx': test_spikeglx, 'intan': test_intan, ...}
reader_functions = {'spikeglx': read_spikeglx, 'intan': read_intan, ...}

Then this function could be something like

def read_recording(path, stream_id=None, stream_name=None, force_type=None):
    # some path processing probably...

    # start by calling si.load() or load_extractor() or BaseRecording.load()?

    if force_type:
        # may need to check which reader functions need the stream kwargs?
        return reader_functions[force_type](path, stream_id=stream_id, stream_name=stream_name)

    for format_name, test_fn in format_test_functions.items():
        if test_fn(path):
            reader_fn = reader_functions[format_name]
            return reader_fn(path, stream_id=stream_id, stream_name=stream_name)

    raise ValueError(f"something with how I tried {','.join(reader_fn.keys())} and maybe you should use force_type")

[alejoe91]

why not a try-except for every supported input format? We should at least have a read_recording and read_sorting though

[cwindolf]

Yeah, try is definitely better than writing a million test_XYZs!

[cwindolf]

Although, sometimes a recording really is spikeglx, and the error is that someone has given the wrong stream_id or something. Not sure how to handle that with trys.

[alejoe91]

Although, sometimes a recording really is spikeglx, and the error is that someone has given the wrong stream_id or something. Not sure how to handle that with trys.

we should maybe make a custom StreamError so it can be caught separately!