[WIP] specparam v2.0.0

[ryanhammonds]

trafficstars

The next major release of the 'fooof' tool will update the name of the tool to 'specparam' (for spectral parameterization).

Plan for migrating from fooof to specparam.

Naming

• [ ] Name change across module (#205 )
• [ ] Sweep module to find naming discrepancies if any (i.e. understanding peak_params vs periodic_params)

API

• [ ] ~~Flexibility for other aperiodic/periodic fit functions (i.e skewed gaussian, double exponential, gamma, etc).~~
  • The plan for this is to be post specparam release to speed up transition.

NOTE: Updated by Tom, and some milestones moved, as we organize updates across versions (1.1 / 2.0 / >2.0)

[ryanhammonds]

@TomDonoghue everything should be complete here (after review + merge), except the flexible fit func (#194) PR and the final naming changes.

[ryanhammonds]

@voytek This is the issue that can be used for the changelog and progress report.

[TomDonoghue]

Thanks for the organization and work on all this Ryan! With the name update in progress (#205) this should now all be done / in process, so I'm going to close this issue now.

[danieltomasz]

Is there any timeline for specparam release? So the best practice would be now to refer to the package as specparam instead of fooof while writing a new manuscript?

[TomDonoghue]

Hey @danieltomasz - there isn't an exact timeline layed out - but hopefully soon (I hope to finish and release the new version as SpecParam in the next month). Note that the model isn't changing, so practically the new SpecParam will be equivalent to the current fooof. In a manuscript, you can refer to either name, or I would perhaps write something like: "spectral parameterization (v.1.0.0; REF) was used to..." - I don't think it matters too much.

[danieltomasz]

@TomDonoghue @ryanhammonds any timeline for the release? Does the released version will be much different from the current main branch? Algorithm will stay the same, but there are some API changes

[TomDonoghue]

Hey @danieltomasz - ooops / wow, I can't believe how long it has been already! The delay is my fault - as I'm in a new position, I got distracted from finishing the code work here.

The new version, in terms of the naming updates, is pretty close to being done over on this branch: https://github.com/fooof-tools/fooof/tree/name ^For this, which we intend to be the new release, there are a lot of name changes, but no core algorithm changes. The plan is to release a specparam version that should match the algorithm of the previous fooof release, and then build from there for any future algorithm changes. Practically this means people should be able to continue using the current fooof release, or pull from the specparam branch and start with the new API, without having any important differences in algorithm / results.

In terms of timeline - I don't want to over-promise with any particular date, but I can note we are close (a couple of weeks or so) from releasing the main new code project from my current position, at which point I plan to dedicate my code work time back to this project (and neurodsp).

[danieltomasz]

Sorry for delayed reply :) I can understand delay :) but still anyway await new release (in its proper time :) ) My question after looking into time of last changes: are the important changes from the main backported into name branch ? I would like to propose one thing - maybe use the major version number as a branch name ( specparam2.0 and fooof1.0 or the same way as mne is doing)?

[TomDonoghue]

This issue is effectively outdated, as the main branch is now updated to specparam2.0. There are still ongoing updates to be included in 2.0 as open PRs, but those are beyond what's discussed in this issue - so I'm going to close this issue now!