Analyzing combined filter types with BWise graphs for Jack

From Manipulating Jack/Ladspa Audio processing graphs from Bwise we know we can generate sequences of "jack-rack" processing racks and automatically connect up their streams with Jack audio processing (mainly in Linux, though there is a Windows jack).

Here is a start to actually compute something with Bwise that makes sense to electrical engineers, namely if there's a signal path within the filtering graph where a certain type of filter runs from input to output (or the converse).

So say we have the graph from the page above, we could assign a filtertype to each block, in the simplest case "1" or "2", and lets give the blocks a color which represents their type (for instance type 1=no poles, 2=no zeros, so that we can know if some paths give through DC components or leave high frequencies in peace):

 # say these three blocks get a variable saying they're type 1
 set higexp.filtertype 1
 set lowmidspea14.filtertype 1
 set df6.filtertype 1

 # now the ohers in the graph must get type 2
 foreach  i [net_allleft higpasslow] { 
    if ![info exists $i.filtertype] { 
       set $i.filtertype 2 
    }
 }
 # Now color according to type
 foreach  i [net_allleft higpasslow] {
    if {[set $i.filtertype] == 2 } { 
       $mc itemco [tag_and "$i block"] -fill red
    } {
       $mc itemco [tag_and "$i block"] -fill green
    }
 }

The idea is in this case we have no path of one color from input to output, but we want to ascertain this fact in an automated fashion.

One of the easy to implement ideas for someone with knowledge of the "fire" functions (net_funprop in this case), we could filter out the wrong color blocks from the "net_right" to make the nodes ignored for the fire rules with the wrong color, and check if the last block (in this case there's on output and one input to start "net_funprop" from) has received input values, so in net_right we change:

         ...
            set ot [lindex $ot 0]
            if {[lsearch $o $ot] <0 } {lappend o  $ot}
         ...

to:

              set ot [lindex $ot 0]
            global $ot.filtertype
            if {[lsearch $o $ot] <0 && [set $ot.filtertype] == 1 } {lappend o  $ot}

and clear the input pin variable from the last (output) block, run fun_prop from the right click menu, and the network run indicates input from the "higexp" block having transfered to the last block input pin. However, the last block didn't fire, because it received data from only one of its two connected (left side) blocks. And the block isn't green, so it doesn't make type 1 filtering happen, so the network passes no type 1 through.

We could change the higpasslow block to green by changing the filtertype var and rerunning the above, then still it doesn'n fire, because it receives only on of it's inputs yet. However we could take from the non-zero input pin (higpasslow.i, assuming clearing the network to initial state) that the signal has reached the outut, so there's a pass for type 1 now. Probably there's a nicer/easier way involving subnetwork filters, so lets make some.