@larsoner @mscheltienne Kindly review this PR and let me know if any changes are required

I'm happy to look over this @larsoner

@Anushreebasics Thanks for opening the PR.

It would be good to set some explicit __get_state__ and __set_state__ methods as per this comment, much like we do for Spectrum and TFR objects (e.g., for TFR objects).

Additionally, we should really also add this save/load behaviour to SPoC, like suggested in the issue/forum post. Actually, the format of generalised eigenvalue decomposition tools was standardised with introduction of the _GEDTransformer class, so now it might make sense to also add the features to the CSP and XdawnTransformer classes (especially now that SPoC inherits from CSP). Though perhaps there might be some caveats making this more complex than I imagined.

Please have a think about adding __get_state__ and __set_state__ methods for the _GEDTransformer class that can be customised for the individual GED classes. For an example, you can have a look at the AverageTFR and EpochsTFR classes to see how their __get_state__ and __set_state__ methods build on those from BaseTFR.

@tsbinns please review the changes
I’ve added explicit getstate / setstate methods to SSD, building on those in _GEDTransformer, following the same pattern used by BaseTFR. Serialization is now explicit, avoids storing callables, and reconstructs the covariance estimator deterministically on load.
For this PR, I am intentionally limiting the scope to SSD only, to ensure the proposed getstate / setstate approach is correct and aligned with MNE’s design expectations. If this implementation looks good, I will follow up with a separate PR extending the same pattern to SPoC.

@tsbinns please review the changes

@Anushreebasics I can't see any changes apart from merging the main branch. Please check that you have pushed the commits with changes.

@tsbinns sorry it was not pushed, please review

@drammock Please may I get your input on how __setstate__ should be handled.

For Spectrum/TFR objects, we don't support direct instantiation, so if inst is a dict we know to call __setstate__ and skip the normal instantiation. However, we do allow direct instantiation for GED transformers, mainly based on Info.

Should we go for a similar behaviour to Spectrum/TFR objects and say if info is a dict rather than an Info object, we call __setstate__? Or, do we instantiate the GED class with some dummy variables, then call __setstate__?

If we go for the former, I'm just wondering if users mistakenly pass a dict to info it could lead to some obscure failures. Would it be a good idea to run a check that if info is a dict and it is missing expected attr keys, we raise an error directing the user to provide an Info object?