Hard-coded filter number in Guardian.
Created by: terrencetec
Hi Guardian masters, I was just browsing the Guardian code casually and I noticed something that could potentially be a problem.
In particular, I was talking about visfilt
or anything other combination of scripts that turns filters in a filter bank on or off.
For example, in line 232, 233 of common/guardian/GRD_MASTER.py
:
if sus_type_is() in ['Type-Bp',]:
visfilt('IM','DAMP',['L','T','Y','R','P','V'],['FM4','INPUT'],-1)
There's a line that turns 'FM4'
on or off.
By hard coding the filter number into the Guardian, we "secretly" restrict operators to use only 'FM4'
(without even knowing).
This is not optimal as people might use multiple filters, i.e. 'FM4'
, 'FM5'
, ..., etc. in one filter bank, for purpose of clarity, or simply because somehow we get a filter that has >20 orders.
Of course, it's possible that we can recode the Guardian every time we make changes to the filter bank.
But this simply destroys the generality as every filter bank might need a different configuration.
And, this couples the workflow between filter shaping and Guardian coding, which is unnecessary.
So, in this sense, I don't think it's ideal to hard code the filter number into the master Guardian.
What I used to do for the very old Type-B Guardian is to (Something like this, can't remember exactly how I did it),
- Not touch the filters and let people who shape them decides which one goes on, which one goes off,
- Turn on a filter bank by the following procedure: a. Turn off input and output switches b. Reset the filter bank (So statics values go away.) c. Turn on the output switch d. Lastly, turn on the input switch.
In such a way, the users can utilize the full potential of a filter bank, without worrying that the Guardian might misbehave.