Saving a buffer can now speicfy the buffer used.
Offline processing uses a per signal binary search to hugely reduce
processing time that was mostly spent on an O(n) linear search
API now has range fetching API's for graphs etc
Implemented the initial offline processing implementation, with
dependency layer building and ordered processing
Processing is still single threaded and unoptimized so it can take some
time to complete, the next step is to move from a single threaded design
to a ThreadPoolExecutor that splits up the buffer into a set number of
chunks for processing
API and Protocol docs have been updated (GPT 5.6)
The API methods for fetching a sepcific signal descriptor and fetching
all signal descriptors now work in offline mode, the core_tui.py example
has been updated to fit the new tri mode architecture and loading
recording offload -> processing and then processing -> playback engine
all works
API has been update to return copies when returning immutable objects to
avoid passing internal references to the user that could then modify
them, breaking the internal state. Even if the copy operation is
obsolete in some cases, it is kept in as a safety should the API
functions be modified which would cause a return reference issue, the
concerned API methods are not to be requested at high frequency either
way so the performance hit is estimated to be minimal, the only API
method that may be queried at a high freqency is fetching live values
which are returned as floats which are immutable and therefore not
concerned
All internal and public errors have been revised (GPT 5.6 Sol) to return
more detail without horrendously long error classes, this has reduced
the number of error types but each now carries a reason and a code for
differentiation if needed
PlaybackEngine has been implemented and is functional, core mode changes
what signal descriptors are returned to avoid duplicates, the playback
engine currently discards the derived signals that would be recorded in
the DLPak and derived signals are reprocessed live
Future will require the behavior listed above to be selectable so one of
two options are possible:
A - Derived signals are reprocessed live by the relevant derive units
(current behavior
B - Derived signals are played back directly from the PlaybackEngine,
this requires turning off the routing to the live derive units to avoid
duplicate values
This will also require the option to perform offline processing with
derive units to be able to create derived signals after the fact, this
will likely incur a new 'offline' mode in the core to gate things
correctly, this will likely be useful for heavier processing that cannot
be done live, filters that require a lookahead, or more precise derived
signals using interpolated signals for higher acurracy which also brings
the ability to offline process on a fixed timebase instead of following
either input signal to the derived signal
Implemented DLPak design with zip storage, DLPak consists of two files,
a manifest.json which provides details on the signals, time of recording
and currently blank comment field and data.csv which stores all the
signals as csv with the nanosecond timestamp and indexed against the
signal id
h3cx