> I mean that the (channel==9) has been the hard-coded hack at the time, and > is now replaced by the new hack "is_drum_channel" field. At initialization, > the new code still hard-code a 9, but not anywhere else as they were > previously. >
Yeah, but the comment was about bank selection (and that it was hard-coded to channel 10, or 9 if counting from 0). Given that your patch no longer hard-codes channel 10, how does it handle bank selection for drum channels? The later part of the comment on ignoring bank select is "comment in the > code" that can be implemented either way, based on what I can understand > from various bit and pieces of GM-spec docs and related documents. > Basically, FS can do whatever in this case. GM specs, and official stand > on this issue is a wash, water under the bridge, nothing, nada. > Right, so the implementation can do whatever it wants -- it isn't specified. But that is a policy decision that it seems like FS hasn't made yet, one way or the other (hence the presence of this comment). By removing the comment, you are effectively committing to a particular policy decision. I am saying that either a) the comment should remain in the program, in some form (modified to describe the new situation after the drum patch, but still giving developers an idea of the as-yet-unmade policy decision), or b) the FS developers need to commit to a particular policy (such as "FS will ignore bank change commands when in GM mode" or "FS will go out of GM mode if a bank change occurs"), change the code to match that decision, and then remove the comment. In other words, the comment shouldn't simply disappear without an active decision, rather than just "it happens to work this way now." Matt
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
