plot_input() should plot all inputs about hnn-core HOT 12 CLOSED

indeed. So the call would become something like:

net.spikes.plot_hist(type='evprox')

?

from hnn-core.

New discussion next week on Network reorganization? Tuesday 1-4pm is a good time for me.

from hnn-core.

works for me!

should we each open a PR before then with a small improvement to the Network class? It's better to touch code first so we can guide the discussion meaningfully

from hnn-core.

This is a great starter issue!

from hnn-core.

Should plot_input() be moved to the Spikes class? Instead of using gid_dict, I think Spikes.types could be used.

https://github.com/jonescompneurolab/hnn-core/blob/master/hnn_core/network.py#L359-L363

from hnn-core.

See #133 (comment) for a suggestion regarding the proposed net.spikes.plot_spikes_hist() and net.spikes.plot_spikes_raster() functions.

from hnn-core.

maybe a good issue for @ntolley ?

from hnn-core.

Thanks for tagging me, definitely a good issue to get involved. I'll try to incorporate the spike_types argument as suggested.

from hnn-core.

Feel free to already give it a shot before the coding sprint, so you have a working set up for contributing and we can discuss what are the pain points!

from hnn-core.

See #133 (comment) for a suggestion regarding the proposed net.spikes.plot_spikes_hist() and net.spikes.plot_spikes_raster() functions.

So this relates to the idea of refactoring the network class, but a complication with the interconnectedness of the feeds with network shows up here. What about moving to more standard types in Spike._types. For example, an input curently typed evprox1, could get _type "evoked" and a new attribute _projection with value "proximal". The index could be inferred from start times. The GUI depends on a consistent index right now, but I wonder if we can move towards an implicit index, where t0 of the input defines the order?

This would make steps that check the type of input so much easier, and the spike_types argument used here wouldn't be necessary. This idea also relates to #124

from hnn-core.

I am a bit lost :) Maybe let's add this for Zoom discussion with @rythorpe this week.

from hnn-core.

See #133 (comment) for a suggestion regarding the proposed net.spikes.plot_spikes_hist() and net.spikes.plot_spikes_raster() functions.

So this relates to the idea of refactoring the network class, but a complication with the interconnectedness of the feeds with network shows up here. What about moving to more standard types in Spike._types. For example, an input curently typed evprox1, could get _type "evoked" and a new attribute _projection with value "proximal". The index could be inferred from start times. The GUI depends on a consistent index right now, but I wonder if we can move towards an implicit index, where t0 of the input defines the order?

This would make steps that check the type of input so much easier, and the spike_types argument used here wouldn't be necessary. This idea also relates to #124

+100 yes! I totally agree @blakecaldwell that the best way to proceed with this requires that we first refactor some parts of Network and ExtFeed. Also note my comment here. I'm probably getting ahead of myself here, but I think it would help if we simplified the feed class s.t.

1. each feed type is associated with one and only one gid (i.e., even the rhythmic common feeds)
2. ExtFeed stores a list of all feeds using the same format (i.e., individual feeds are not items in a list of either "unique" or "common" type) by assigning projection, gid, and time attributes to individual, cell-specific feeds

from hnn-core.