New IO development (NIX) and Neo 0.4

[Achilleas Koutsou]

Hello all.

I am currently working with the G-Node to implement a NIX IO for Neo. Due to the upcoming changes in the API and data model, I have been working with Andrew Davison's analogsignal branch, to make the IO compatible with Neo 0.4. This has so far been rather stable, and judging from the discussion in the relevant PR, I get the impression that the changes introduced, at least with respect to the data model, can be considered fixed.

As far as I can tell, the most up-to-date development branch with respect to 0.4 is apibreak, though this branch seems to break frequently (as the name suggests).

I'm posting here to ask which branch would be best to work on to write the IO to be ready for 0.4. I'm currently staying with the analogsignal branch, that has already been merged, to avoid problems with the apibreak branch, since it is not required to build and run properly at any given time. However, it's clear that staying with the analogsignal branch will cause the IO's development fall behind in terms of changes to the data model soon, as more and more API changes are introduced elsewhere. Is there, or will there be at some point, a stable-dev branch that we can work on to keep up with changes as they are implemented? Do you think it might be better for me to work on the apibreak branch and try to work around (by delaying pulling) commits that break the build? I'd rather avoid this, unless I know that the build breaks infrequently.

More generally, beyond the changes discussed in the PR for the analogsignal branch, is the wiki tasks page the definitive plan for the changes that will be introduced in 0.4? Is this plan subject to change substantially, or can I consider it relatively fixed and plan the implementation of the IO accordingly?

Thanks for the help.

[Andrew Davison]

Hi Achilleas,

You should consider the `apibreak` branch as the stable development branch, which will become Neo 0.4 (unless some major problem with the new API is discovered soon).

As you saw, I've now merged the `analogsignal` branch into `apibreak`, and I've fixed a number of bugs so that the Travis CI build now passes. My aim is now to keep it passing.

The wiki tasks page was outdated. I've just updated it, so it should now be a good road map for 0.4 (certainly all the remaining API changes will be implemented soon; some of the implementation changes may be postponed to version 0.5).

Hope this helps,

Andrew

[Achilleas Koutsou]

Great! Good to know that there's a stable-dev branch. I'll switch to using apibreak and keep an eye on the changes.

Thanks,

Achilleas

[Achilleas Koutsou]

Something I'm not sure I fully understand in the new API is the role of channel_indexes in a RecordingChannelGroup. In the old API, each RecordingChannel was an object, so the many to many relationship between RCGs and RCs was quite clear. Now, as I understand it, a RecordingChannel is simply represented by an index (in channel_indexes) and optionally a name (channel_names). According to the new documentation, this is supposed to maintain the same structure as the old. Also, it seems that the channel indexes are meant to be used as indexes for the Signals referenced by the same RCG.

Does the code below conform to the intended usage?

rcg = RecordingChannelGroup(channel_indexes=[1, 5, 7])
rcg.analogsignals.append(arbitrary_analog_signal)
rcg_signals = rcg.analogsignals[0][:, rcg.channel_indexes]

Do channel_indexes signify that "rcg" is a grouping of the signals at the specific indexes of each referenced AnalogSignal or IrregularlySampledSignal?

Also, are channel index values unique across a Blocl? Does a channel index with value "1" reference the same RecordingChannel, regardless of whether two RCGs with the same index reference the same AnalogSignal or not?

Thanks.