FDN presets saving

We should have a config file system for FDNs. Something like a JSON file that contains the architecture and coefficients of an FDN.

This is interesting for different reasons:

We should aim for this to become a library of well-tuned FDNs.
For lean init in Example files use configs
Also: dss_to_flamo is quite neat, update other examples and replace vanilla FDN

Why not just submodule "flamo-rt/rt-fdn”? It's the same thing, same node types, same tree structure, same separation of config from exec as described above and it has been implemented and tested already.

@cucuwritescode

@cucuwritescode For a clearner code structure: do you think it would be ok, to move the json config and the flamo <-> config converter to the pyFDN repo? Then the rt-fdn would contain from the json->faust.

@jeremybbq

@jeremybbq legacy FilterMatrix and similar are gone from the code. There is only the vanilla FDN, process_fdn left.

Another subtle point to discuss is the difference between raw and structured components. Probably, this is mainly for the matrix.

For example, the Hadamard matrix has "parameters". But then there is also the resulting "elements" of the matrix.

Is the config holding the information "Hadamard" + "parameters" or "Matrix" + "elements"?

it’s currently holding “matrix" + "elements"

What would you suggest?

@jeremybbq

If you collapse to matrix + elements, then you loose any potential benefit of using special matrices. That’s good for compatibility, but not good for efficiency.

I’m fine with that for Faust, but for FLAMO this is not acceptable.

So, maybe there is a reason to separate those config files.

@jeremybbq Any idea on that?

I can modify that on the pyfdn-integrated version of rt-fdn. Should be straightforward. Should the main rt-fdn stay as is then? What do you think?

flamo_to_json looks already well written. Do you think it would be possible to make a 'full' version? So, it allows us to go back to FLAMO without ambiguity?

Then I see these options:
A) full version in pyFDN; reduced version in rt-fdn.
B) same full version in pyFDN and rt-fdn 'extracts' necessary parts from JSON.
(C) full version in FLAMO.)

Yes I’m working on the full version. When I have something working I’ll commit, will keep you posted about it.
I see, personally I’d go for option B.

Hi, I missed a lot from this thread for some reason while working on this, but I'll still give a brief update on what I did...

I was trying to write a FDN builder essentially, hoping it would serve as a central distributor for different backend as I mentioned earlier. It essentially looks like a FLAMO wrapper without the actually operations defined using dataclasses. They live on branch feat/graph-config if you want to check it out.

In hindsight you guys are right, FLAMO is compact enough to serve as the config builder and distributor. But the .json format definitely needs more caution, since they serve as: 1. storing format 2. readable format 3. intermediate between backends.

the three roles you mention (storing, readable, intermediate) are the design goals the current JSON IR already addresses. namely:

storing/round-trip: flamo_to_json captures full metadata (nfft, grad flags, module attrs) under a flamo key. json_to_flamo reconstructs the model exactly from it.
readable: nodes are named and typed, topology comments are auto-generated in the FAUST output.
intermediate: json_to_faust reads the same format and ignores fields it doesn't need. so any future backend does the same
(option B, as discussed above).

this is implemented and tested on main. if there are specific concerns about the format, feel free to open an issue on rt-fdn.

as i said a few weeks ago I think it’d be best practice to finish it on rt-fdn as it’s more advanced and working and then integrate it… otherwise it’s just hard to coordinate and actually time-consuming to keep up with two different versions of it.

the three roles you mention (storing, readable, intermediate) are the design goals the current JSON IR already addresses. namely:

storing/round-trip: flamo_to_json captures full metadata (nfft, grad flags, module attrs) under a flamo key. json_to_flamo reconstructs the model exactly from it.

readable: nodes are named and typed, topology comments are auto-generated in the FAUST output.

intermediate: json_to_faust reads the same format and ignores fields it doesn't need. so any future backend does the same
(option B, as discussed above).

this is implemented and tested on main. if there are specific concerns about the format, feel free to open an issue on rt-fdn.

as i said a few weeks ago I think it’d be best practice to finish it on rt-fdn as it’s more advanced and working and then integrate it… otherwise it’s just hard to coordinate and actually time-consuming to keep up with two different versions of it.

Yes I agree! To be clearer I meant I will put the branch on hold, and keep track of the progress in rt-fdn. In the meantime I'll test some .json generated from there and see if I can translate them to a Numba JIT FDN I'm testing. Will also keep you guys posted!

Oh that sounds great. Thanks, please do!

@jeremybbq

@jeremybbq

I added a fdn_build_to_dict preset management into #211 . It's not set in stone, but I needed a solution to be able to continue.

Resolved by #222, but only for standard FDN formats. For arbitrary graph might go for something that is more flamo/td native or similar to ADAC.

Navigation Menu

Repository navigation

FDN presets saving #146

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

FDN presets saving #146

Description

Activity

jeremybbq commented on Apr 24, 2026

cucuwritescode commented on Apr 24, 2026

SebastianJiroSchlecht commented on Apr 24, 2026

SebastianJiroSchlecht commented on Apr 24, 2026

SebastianJiroSchlecht commented on Apr 25, 2026

cucuwritescode commented on Apr 26, 2026

cucuwritescode commented on Apr 26, 2026

SebastianJiroSchlecht commented on Apr 26, 2026

cucuwritescode commented on Apr 26, 2026

SebastianJiroSchlecht commented on Apr 27, 2026

cucuwritescode commented on Apr 29, 2026

jeremybbq commented on May 13, 2026

cucuwritescode commented on May 13, 2026

jeremybbq commented on May 13, 2026

cucuwritescode commented on May 13, 2026

SebastianJiroSchlecht commented on Aug 11, 2026

jeremybbq commented on Aug 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions