| Thinking about this in a more general way, I think it's fine to have
message logging levels like we do now. We might offer more
fine-grained controls for families of opcodes. In this case, it might
be interesting to have opocdes to set/get the message level. I.e.,:
fluid_set_message_level i
i fluid_get_message_level
And the messages may get printed depending upon the global msglevel
flag as well as the opcode family level.
This seems like it would scale for the future and could be a
recommended practice. It also allows opcode developers to add
configuration functionality without core being touched.
On Sat, Aug 17, 2019 at 4:07 PM John wrote:
>
> In the issues there is a request
>
> > can fluidControl get an optional flag to tell it to print the midi message
> > output or not?
> > atm, it is always ON, so when using fluidControl for pitch bending, it prints
> > hundred of messages, slowing down the computer because of this printing.
>
> > i am aware that i could turn off by a different -m setting in the command
> > line, but that would also affect all other warning messages of the csd.
>
> > Something like:
> > fluidControl ienginenum, kstatus, kchannel, kdata1, kdata2 [, imsg]
>
> > where imsg = 0 by default and thus printing messages.
> > When imsg = 1: no printing
>
> At present if the value of -m has the bottom bits set it prints. It
> seems sane to control these messages which in the case of pitchbend can
> dominate the rendering.
>
> Would it be acceptable to add the optional argument and not take
> account of -m values? Or is this too incompatible a change?
>
> ==John ffitch |