Rec group set to shank_id in NP 2.0 multishank, but to probe_id for NP 1.0
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
Direzione di ricerca
No files or tests are named in the report. Start from the recording's group property and the NP 1.0 and NP 2.0 multishank behavior described here; determine how by_probe and by_shank behave with multiple probes, where shank IDs are retained, and document the rationale and downstream implications.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hello!
SpikeInterface version 0.104.3
As I understand the recording group gets automatically assigned "probe" as group for NP 1.0 and "shanks" for NP 2.0 multi-shank.
This is not necessarily an issue, but created some confusion when sorting began and the single NP 2.0 4 shank probe got split into 4 separate probes folders.
My question is: is there a particular reason for this choice? Can I safely change grouping for NP 2.0 multi-shank probes to "by_probe" rather than "by_shank"? Will that lead to some issues downstream? Because I don't know if any other processing relies on these groups to be shanks and not probes.
Here is a recording with two NP 1.0 probes and property > group of this recording assigns IDs 0 or 1 for each probe:
And here is a recording with single NP 2.0 multi-shank probe and property > group of this recording assigns IDs 0, 1, 2, 3 for each shank:
Let me know if this info was specified somewhere and I missed it.
I'm also wondering what would happen if I were to have two NP 2.0 multi-shank probes in a single recording. What would group property assign and where would shank id information go?
- Lingua principale
- Python
- Stelle
- 85
- Fork
- 49
- Merge medio
- 13h 47m
- PR unite (30g)
- 3
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di SpikeInterface/probeinterface
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
SpikeInterface/probeinterface#469 · 2 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
SpikeInterface/probeinterface#465 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 48/100
SpikeInterface/probeinterface#452 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
SpikeInterface/probeinterface#447 · 2 commenti · 1 reazione ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
SpikeInterface/probeinterface#444 ·
Tutte le issue di SpikeInterface/probeinterface
Issue simili
-
货币战争手改优先级配置缺少列表元素类型校验(P3) Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
syfoud/Simulated_Scepter#172 ·
-
A cancelled tests run makes the coverage comment workflow fail and reports it as a red check on main Apertaarea: ci bug perceived difficulty: 3
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Nitjsefnie-Harness-Commons/daedalus#921 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
EleutherAI/lm-evaluation-harness#4207 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ClickHouse/clickhouse-connect#1057 ·