edfcore 0.5.54 → 0.5.56
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +40 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
|
|
|
109
109
|
readonly reserved: 224;
|
|
110
110
|
};
|
|
111
111
|
/** Published package version. Kept in sync with package.json by a test. */
|
|
112
|
-
export declare const VERSION = "0.5.
|
|
112
|
+
export declare const VERSION = "0.5.56";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,46 @@ alone does not tell you whether you were affected.
|
|
|
6
6
|
edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
|
|
7
7
|
defect; those are called out below.
|
|
8
8
|
|
|
9
|
+
## 0.5.56
|
|
10
|
+
|
|
11
|
+
- **Added** the rule `precededByGap` carries, checked however the chunk was asked for. It is stated
|
|
12
|
+
in three places and was tested in one. `chunks.ts`: the field is `undefined` "in two different
|
|
13
|
+
situations: no gap, and nobody looked". `stream.ts`: a streamed chunk carries "the same
|
|
14
|
+
`precededByGap` a `readWindow` chunk would". `biosemi.ts` states the sharpest form — the gap
|
|
15
|
+
"precedes the RUN, not whichever sample the window happened to admit first, which could be a whole
|
|
16
|
+
record later", a rule narrowed in 0.3.67 after 0.3.92 wrote down a wider one.
|
|
17
|
+
- Four entry points produce chunks, and the field is computed from the index rather than from the
|
|
18
|
+
read — so what it says must be the same whichever asked, for the same records.
|
|
19
|
+
- One file with a twenty-second hole after record 4, and every way of naming the records around it:
|
|
20
|
+
`readRecords` by number, `readWindow` by time, `streamRecords` in pieces smaller than the run, and
|
|
21
|
+
`readEnvelope`. The gap appears on exactly one chunk in each — the one whose first record is
|
|
22
|
+
record 5 — and on none of the others, including the chunk starting at record 6, which is inside
|
|
23
|
+
the run and after it, and the chunk starting at record 4, which spans the hole by record number
|
|
24
|
+
and is not preceded by it. At four different `chunkRecords`, exactly one streamed chunk carries it
|
|
25
|
+
every time.
|
|
26
|
+
- The other of the two situations is checked beside it: on a probed index the same read gives
|
|
27
|
+
`undefined`, which is "nobody looked" rather than "no gap" — and the samples are identical either
|
|
28
|
+
way, so only the field about structure differs.
|
|
29
|
+
|
|
30
|
+
## 0.5.55
|
|
31
|
+
|
|
32
|
+
- **Added** the window that begins before the recording does. "A window that starts before record 0
|
|
33
|
+
is how a pre-stimulus epoch is spelled" is the sentence `tal/ticks.ts` uses to justify `floorDiv`
|
|
34
|
+
and `ceilDiv` existing at all, and `annotations.md` builds a section on negative onsets around the
|
|
35
|
+
same idea. 0.5.15 tested the two divisions; what a caller actually writes —
|
|
36
|
+
`readWindow(recording, { startSeconds: -2, durationSeconds: 4 })` — was tested for its bounds and
|
|
37
|
+
not for the negative side of them.
|
|
38
|
+
- There are three outcomes and only one is an error, and it is not the one a reader expects. A
|
|
39
|
+
window straddling t = 0 is read, clamped to the samples that exist. A window entirely before the
|
|
40
|
+
recording comes back as `[]` — the same empty array a window past the end gives, which
|
|
41
|
+
`api-reading.md` says in as many words. Nothing throws for either: a negative bound is a
|
|
42
|
+
legitimate question with a possibly empty answer, and only a non-finite one is a mistake.
|
|
43
|
+
- The trimmed result is where it matters, and it is asserted sample for sample.
|
|
44
|
+
`trimToWindow(header, series, -2, 4)` starts at 0 rather than at -2 and holds exactly the samples
|
|
45
|
+
in `[0, 2)` — the arithmetic that needs a floor rather than a truncation, on operands that are
|
|
46
|
+
negative for the whole first half of the window. A bound that is not a whole second is checked
|
|
47
|
+
with it, and `sampleAt` is checked either side of the boundary.
|
|
48
|
+
|
|
9
49
|
## 0.5.54
|
|
10
50
|
|
|
11
51
|
- **Added** the claim the `index` option on `validateRecording` is only worth having if it holds: a
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED