Open-source Igor Pro toolkit for PatchMaster/Nanion Patchliner electrophysiology analysis

Hi everyone,

I would like to share an open-source Igor Pro toolkit that we are developing for the analysis of electrophysiological recordings exported from HEKA PatchMaster, with a particular focus on data generated using automated patch-clamp systems such as the Nanion Patchliner.

Repository:
https://github.com/Gfernandezv/CBIB_igor_patchmaster

The goal of the project is to provide a reproducible Igor Pro workflow for common post-acquisition analysis steps in patch-clamp experiments, including:

  • batch processing of PatchMaster-exported traces;
  • baseline correction and drift removal;
  • peak current extraction;
  • analysis of current–voltage relationships;
  • estimation of passive membrane properties such as capacitance and series resistance;
  • organization of output waves and summary values for downstream analysis.

The toolkit is currently written as a set of Igor Pro procedure files (.ipf) and is being actively developed. At this stage, it is mainly intended for users working with PatchMaster exports who want to standardize repetitive analysis steps and reduce manual processing.

We would be very interested in feedback from the Igor Pro community, especially regarding:

  • best practices for structuring larger Igor Pro procedure projects;
  • compatibility across Igor Pro versions;
  • suggestions for documentation and example datasets;
  • ways to improve usability for users outside our own laboratory workflow;
  • recommendations for testing or validating Igor Pro analysis code.

The project is released under the GPL-3.0 license. Contributions, issues, suggestions, and critical feedback are very welcome.

Best regards,
Germán Fernández

jjweimer

Congratulations on the posting! 

I am glad to comment briefly to address some of your requests about package distribution and management. Start by reading the section on Creating a Package in the IP User Manual. Also, download and review the existing packages posted here for insights on how they structure their procedure files and their parameter sets. With regard to procedures, pay attention to establish consistent documentation using headers and comments (I see you have implemented generous and well-framed comments).

As for documentation, consider that focused "How To Do This" video tutorials are likely to garner greater appreciation than making users have to read a manual to get the same instructions.

Finally, rather than hosting on Github, consider posting the files here as a self-contained package to make them accessible via the Project Updater package and the Procedure Loader package.

Hope these comments are useful as you plan further developments.

gfernandezv

Thank you both for the constructive and practical feedback!

Regarding package structure and distribution (first comment), here is what I plan to address in the next revision:

1. File headers: I will adopt the standard pragma block across all three procedure files, including #pragma rtFunctionErrors=1, #pragma IgorVersion, version number, and author metadata following the template you linked.

2. Documentation: All inline comments and user-facing strings will be translated to English. Function headers will follow a consistent structured format (Purpose, Inputs, Outputs, Notes).

3. Incomplete features: Two functions currently under development (leak subtraction and a second baseline correction mode) will be clearly stubbed out with a user-facing message so they do not silently fail.

4. Distribution: I will prepare the package for submission to IgorExchange with the constants required by the Project Updater and Procedure Loader. GitHub will remain as a parallel development repository.

5. Video tutorials: Noted — I will prioritize a short screen-capture walkthrough over written documentation.

Regarding the Igor Programming Tool (second comment): thank you for the recommendation. I was not aware of IPT and will run ipt lint and ipt format on the procedure files as part of the cleanup pass before the next release. This looks like exactly the kind of automated check that will catch issues I might otherwise overlook.

I will post an updated version once these changes are in place.

gfernandezv

Thank you both for the constructive and practical feedback!

Regarding package structure and distribution (first comment), here is what I plan to address in the next revision:

1. File headers: I will adopt the standard pragma block across all three procedure files, including #pragma rtFunctionErrors=1, #pragma IgorVersion, version number, and author metadata following the template you linked.

2. Documentation: All inline comments and user-facing strings will be translated to English. Function headers will follow a consistent structured format (Purpose, Inputs, Outputs, Notes).

3. Incomplete features: Two functions currently under development (leak subtraction and a second baseline correction mode) will be clearly stubbed out with a user-facing message so they do not silently fail.

4. Distribution: I will prepare the package for submission to IgorExchange with the constants required by the Project Updater and Procedure Loader. GitHub will remain as a parallel development repository.

5. Video tutorials: Noted — I will prioritize a short screen-capture walkthrough over written documentation.

Regarding the Igor Programming Tool (second comment): thank you for the recommendation. I was not aware of IPT and will run ipt lint and ipt format on the procedure files as part of the cleanup pass before the next release. This looks like exactly the kind of automated check that will catch issues I might otherwise overlook.

I will post an updated version once these changes are in place.

chozo

Just a brief addition: Depending on your preferences, you may or may not want to skip 'ipt format', which brings all your code to a consistent style, but also erases any personal style such as indentation you got used to. So it has benefits and drawbacks. If you do this in an early stage and get used to the particular style, perfect. I personally don't go that far, since this would make the code less readable for me personally. If you use ipt lint it might be overwhelming at first, since the list of issues may be very long. But you can get at it bit by bit while you are working on your other points.

gfernandezv

Hi everyone,

Following up on the earlier thread about our PatchMaster / Nanion Patchliner toolkit — thank you again for the comments, and in particular to jjweimer and chozo, whose suggestions shaped most of this revision.

What changed since the first post

  • - All inline comments and user-facing strings are now in English.
  • - Every function carries a structured header (Purpose, Inputs, Outputs, Notes) following the template jjweimer linked, and the procedure files now use a consistent pragma block.
  • - Features still under development (e.g. leak subtraction, a second baseline mode) are explicitly stubbed with a user-facing message instead of failing silently.
  • - On chozo's recommendation I ran the Igor Programming Tool over the procedure files. I stuck to ipt lint for now and left ipt format aside, per chozo's caution about it overwriting personal style — the lint pass alone caught a number of things I would have missed.
  • - Added an example dataset (linked below) so the toolkit can be tried without your own recordings.

Main focus of this revision: reusable functions

Picking up on jjweimer's point about structuring larger Igor Pro projects, I reorganized the toolkit around a set of small, self-contained helper functions that are meant to be called by other functions — rather than one monolithic analysis routine. Each helper does one thing and takes its inputs explicitly, so it can be reused on its own or wired into a different workflow. The Patchliner analysis is now just one way of composing these primitives.

The reusable helpers cover, among others:

  • - logging to an on-screen console.
  • - data-folder navigation and path resolution.
  • - per-folder storage and retrieval of analysis parameters.
  • - baseline / drift correction and extraction of columns from 2D result waves.
  • - graph-window and trace management (create-or-front, append wave lists, XY pairs).
  • - cursor placement that works reliably inside hosted subgraphs (a workaround for CsrWave() in # subwindows).
  • - linked-axis synchronization between two hosted subgraphs.
  • - colormap loading and interpolation.
  • - passive-property estimation (Cm, Rs, tau) from a capacitive current transient.

I tried to keep cross-dependencies to a minimum so that most helpers can be lifted into another project individually.

One feature worth highlighting on the analysis side is the NeuroMatic export: it reorganizes the toolkit's channel/experiment data into a NeuroMatic-compatible folder structure, so recordings can be carried straight into NeuroMatic — a package widely used for electrophysiology analysis in Igor Pro — for downstream work, without leaving the Igor environment.

The files

the attached files contain:

  • - a utilities module — the reusable helper library described above.
  • - a common module — wave organization (channel/experiment hierarchy) and passive properties.
  • - an analysis module — Ramp and IV visualization and extraction.
  • - an amplitude module — interactive, cursor-based amplitude analysis.
  • - a NeuroMatic export module.
  • - a menus / panel module — the entry point and control panel.

 

Example dataset

An example experiment (wave prefix W251128_002_E4_4) is available here so the full workflow can be run end to end without any of your own data:

download link

A quick way to try it:

  1. Load the example waves into a fresh experiment.
  2. Open the panel: Analysis → Nanion → Panel.
  3. On the Organize tab, click Organize data and enter W251128_002_E4_4 as the prefix. The raw waves are sorted into the chan_X → exp_Y → {Trace, Stim} hierarchy.
  4. Select an experiment folder in the Data Browser, then use Plot Exp to view traces and stimulus, Ramp Analysis to extract peak and passive properties, and Amp Analysis to store amplitudes.
  5. Export to NM hands the data off to NeuroMatic.

Feedback still very welcome, especially on:

  • whether the helper API is clear enough to reuse outside our lab workflow;
  • compatibility across Igor Pro versions;
  • anything that should be split, renamed, or generalized further.

On the distribution side: I've kept GitHub as the development repository for now, but jjweimer's suggestion of packaging the files here for the Project Updater and Procedure Loader is on the roadmap.

On documentation, and following jjweimer's point that focused "How To Do This" videos are more useful than a written manual, I'll be uploading short screen-capture walkthroughs shortly — starting with the example dataset above.

 

Repository: https://github.com/Gfernandezv/CBIB_igor_patchmaster

Best regards, 

Germán Fernández