Hi Francesco.
#'reduce takes a binary function, and combines the n elements of a given sequence. Check the docs for info and example usage, it seems a possible usage in your case could be something like:
(reduce #'bpf-concat list-of-n-bpfs)
Each list-of-n-bpfs could presumably be built by something like appending all the #'mat-trans’ed bpf-libs
#'bpf-concat’s optional parameter f2-offset can be set to a specific transition length (x) between the two functions, setting it to 0 will give you a step transition between the two f’s.
Hmm… this version always adds a transition function between the two bpfs, would it make sense to not add any in-between function?
Just a suggestion to help reduce memory usage in larger patches: in your loop you use 3 bpf-factories (perhaps this is just debugging or testing? they are superfluous here, just passing the unchanged bpf further down the graph). If you really needed one (say to get access to the x-points of a bpf passed to a sub-patch or an omloop), you can instead use the ‘slots’ version of the bpf box, accessed by Ctrl-clicking in the patch, typing bpf, and shift-clicking in the patch background. (Guess we should set up a key-event to toggle between a slots version and a factory…)
