A good first check on a FAUST program (after getting it to compile) is to generate its block diagram using the -svg option.13 For example, the command
> faust -svg cpgr.dspcreates a subdirectory of the current working directory named cpgr-svg which contains a ``scalable vector graphics'' (.svg) file for each block-diagram expression in cpgr.dsp. For this example, there is a block diagram generated for the process line, and for each of the last five lines in the with clause (not counting the comment).
Figure 6 shows the block diagram generated for the main process block from Fig.5:
process = firpart : + ~ feedbackThe dot on each block indicates its standard orientation (analogous to a ``pin 1'' indicator on an integrated circuit chip). The small open square at the beginning of the feedback loop indicates a unit sample delay introduced by creating a signal loop. Needless to say, it is important to keep track of such added delays in a feedback loop.
Figure 7 shows the block diagram generated for the firpart abstraction:
firpart(x) = (x - x'') * g * (1-RR)/2;
Similarly, Fig.8 shows the block diagram generated for the feedback path:
feedback(x) = 0 + 2*R*cos(A)*x - RR*x';If not for the added sample of delay in the feedback loop (indicated by the small open square in Fig.6), the feedback-path processing would have been instead 0 + 2*R*cos(A)*v' - RR*v''.
Note that the block diagrams are drawn as though all details of the expression are to be evaluated every sample. However, the FAUST compiler instead computes constant expressions at init time and allocates memory locations for them. More generally, the FAUST compiler separately optimizes full-rate signals at the sampling rate (calculated in the inner loop), slowly varying signals (updated at the ``buffer rate'' outside of the inner loop--currently every 64 samples), and constant signals (evaluated once at initialization time).