fix handling of synchrony columns in qualitymetrics

[zm711]

@chrishalcrow

I'm sorry I missed this during review, but we need to find a better way of dealing with synchrony quality metrics. I just discovered that we have the names sync_spike_2 etc hardcoded, but those are named based on user input with 2,4,8 or 2,6,8 being the defaults. So we should think about a more robust way to deal with that. Not sure how, but I discovered this in #3497 and added a note in comment for us to think on it.

[alejoe91]

Thanks @zm711

I agree this is hard to deal with. I would lean towards hard coding the synchrony sizes...what do you think? If someone needs some customization they would run the low level function

[zm711]

Yeah that fits with the rest of our metrics. Although I wonder if we would prefer to move this to the spike train metrics (when that is done). Synchrony should go there rather than as a metric of quality no? But yeah for now we could hard code it which would make everything easier.

[alejoe91]

I would keep it in quality metrics since in my mind spike train metrics are more on a single unit spike train level :)

[chrishalcrow]

Hello, sorry for the delay. I agree that we should just hard code the synchrony sizes: it's gonna be a lot of pain for an edge case. I'll have a go in the next couple of days?

[zm711]

That would be amazing from my perspective. I'm super busy the next week (and it is a holiday tomorrow in the US) so I definitely won't have time to change.