This is definitely a design goal: I guess we’ll find out how well it works out once people have the code and can start hacking. This explanation will make more sense once you can actually see the code base, but there are three broad layers:
Algorithms: do the actual number crunchingClients: aggregate algorithms and define parameters / interfaceHosts: use template magic to emit the appropriate glue that manifests a client in a given environment (Max, SC, PD etc.)
The general idea is that the algorithms layer should be useful as an API in its own right. What comes out of the clients is currently more geared to being easy for machines to deal with via template goo than towards being a human-friendly API.
From my limited ofx-understanding, it looks like using the algorithms directly would work well enough for ofx, because it doesn’t seem to have especially strong expectations about the form that classes take. JUCE is closer to being a host in the same sense as Max etc., and it will be interesting to see how well their inheritance based model can be made to jive with our clients.
I suspect that in both cases we’ll discover room for improvement 