Repository navigation
One execution path: FDNBuild as description, td/FLAMO as the only renderers #256
Description
Blocked by: #255 (toolbox audit) and #250 (system JSON format). Do this after both are merged.
Problem
pyFDN has a "traditional" FDN layer (FDNBuild and the DSS arrays) with its own processing functions, alongside the td graph and FLAMO. For execution, those processing functions are superseded by td and FLAMO. The result is parallel families (process_*, *_to_impz, *_to_td, *_to_flamo, trainable_from_*) that do the same job for different inputs, and the docs have to explain which render path to use.
FDNBuild itself is worth keeping, including for teaching: it is the simple, flat description of a vanilla FDN. The build-specific processing functions are not.
Proposal: three layers, one way through each
-
Description.
FDNBuild(the flat, vanilla tier) and the pyfdn-system: one JSON document format for every pyFDN backend (design + schema sketch) #250 graph (everything else). Pure data, saveable. -
Execution. One conversion per backend that accepts either a build or a graph:
to_td(system)to_flamo(system, trainable=…)
These are pyfdn-system: one JSON document format for every pyFDN backend (design + schema sketch) #250's
graph_to_td/graph_to_flamo; a build is lowered to a graph first. Plus oneimpulse_response(system_or_model, n)that works on a build, atdgraph or a FLAMO model. -
Theory.
dss_to_tf,dss_to_ss,dss_to_pr,is_allpass,general_char_polystay as maths on the arrays.
Make fs and the filter hooks optional in FDNBuild. Then a bare DSS system is FDNBuild(delays, A, B, C, D), and the dss_to_* / build_to_* processing families collapse into one.
What happens to each function
Usage counts are files that use the function (examples / tests), measured on the #255 branch.
| Today | Proposed | Usage |
|---|---|---|
process_fdn, process_dss |
to_td(system).process_signal(x) |
3/1, 6/3 |
build_to_impz, dss_to_impz, flamo_time_response |
impulse_response(system_or_model, n) |
6/2, 17/4, 12/4 |
build_to_td, dss_to_td |
to_td |
0/1, 0/0 |
build_to_flamo, dss_to_flamo, trainable_from_build, trainable_from_preset |
to_flamo(system, trainable=…) |
3/2, 11/5, 1/1, 0/1 |
extract_build |
graph_to_build(flamo_to_graph(model)), as #250 plans |
2/5 |
flamo_process |
to_td for signals; FLAMO for rendering and training |
2/0 |
FDNBuild, fdn_build_gallery, build_set_decay, plot_fdn_build, presets |
keep: they describe and design an FDN, not execute it | — |
About 12 public functions are replaced by to_td, to_flamo and impulse_response.
Notes
- Deprecation:
dss_to_impz(17 example files) anddss_to_flamo(11) need deprecation aliases for one release, not immediate removal. - FLAMO vs
tdsemantics:impulse_responseon a FLAMO model returns the FFT-length response, which can wrap around in time, while thetdresult is exact. The function should say which one it returned. - Teaching: the vanilla-FDN example should show the recursion as an explicit ~15-line NumPy loop instead of relying on a library
process_*function. - Existing internals to reuse: Toolbox audit: lazy import, merged duplicates, consistent DSS API #255 already routes
process_dssthrough thetdgraph and has one FLAMO core builder (fdn_core). Those become the implementation ofto_td/to_flamo. - pyfdn-system: one JSON document format for every pyFDN backend (design + schema sketch) #250 plan: worth recording in its design doc (§7) that its converters become the only execution entry points, so the implementation PRs don't keep both paths.
Activity