#482 Option: Disable sending CCs at playback

[Lorenzo]

Rosegardens still seems to always send MIDI controller changes for:
a) MIDI channels of tracks with segments
b) MIDI channel 10 regardless of the fact it does or does not have segments
(see screenshot)

For each of the above channels it sends controller changes that reflect the corresponding General Midi 'mixer' settings, namely:
CC 7 volume
CC10 pan
CC91 reverb
CC93 chorus

While this might be useful with general midi (e.g. soundfonts) there are use cases when this is not useful and actually even bothersome:

• using synths which have their own settings (and state savings) for volume etc. for example Yoshimi
• synths / software which does not use General MIDI (for instance were controller can be mapped freely)
• even general midi synths (e.g. soundfont) which is using its own settings for volume effect (think Qsynth or Carla)

Of course this has nothing to do with control changes embedded in segments which should always be sent.
It also makes sense to keep sending CC64 (pedal) and CC123 (not off) every time playback is stopped.

Ideally there should be a way to disable this per file/project. Even better this would be set for the MIDI device - e.g. I might want to use yoshimi (do not send anything) plus general midi soundfont (sent controllers)

Otherwise have a global option would be acceptable interpreting this as a general behaivour.

Another (less good) option could be to set this per track

[Ted Felix]

You can turn off CC91 and CC93 on a per device basis by deleting those controllers from the device in Manage MIDI Devices (select the device and press Controllers...). Unfortunately, removing CC7 and CC10 does not actually remove them. That needs some investigation.

The mess on channel 10 is related to the metronome. However, even if the metronome is turned off for playback (Studio > Manage Metronome), CCs are still sent on channel 10 at playback for the metronome. I've not looked into it, but thanks for letting me know this is an issue. I will have a closer look.

[Ted Felix]

[r15750] removes the <volume> and <pan> tags in the .rg file for MIDI instruments. This was making it impossible to stop Volume and Pan CCs from going out. Even after deletion, the CCs would mysteriously come back after a file load. Now, if you remove all the controllers from the Device, absolutely no CCs should ever go out (other than those in the Segment, of course).

[r15751] fixes extraneous CCs going out on channel 10 when the metronome is muted in playback and/or record.

The combination of these two now make it possible to disable all CCs generated by rg.

This should cover this feature request. Please test the latest svn and let me know how it goes.

[D. Michael McIntyre]

This seems so obvious in hindsight, but I sure tried and never figured it out.

[Lorenzo]

Thanks for taking care of this. As a recap from some quick testing I did (useful maybe for other users as well).

Now it looks like:

• Will send out all of the CCs if you create a new file with those enabled
• Will send out any of the 7, 10, 91 and 93 controllers when starting playback if set to be displayed in the MIDI Devices settings AND there is at least a note or a CC change on a segment in that track
• Will send CC 64 and 123 with value 0 when stopping (this is still good IMHO in order to avoid note and sustain hangs in many synths and sound generators)
• If the CCs are displayed (e.g. in the default general MIDI) it will send the last CC the user moves when the playback is stopped. To test move the volume knob on a track, playback, stop. The CC 7 value is sent out every time playback is stopped (not sure this is intentional or not... seems like a bug to me).
• It will still send CC 10 only when the CCs are set to be displayed but even if there is no metronome enabled.
• CCs explicitly added (e.g. in the matrix editor) are still sent in both cases (good)

[Ted Felix]

If the CCs are displayed (e.g. in the default general MIDI) it will send the last CC the user moves when the playback is stopped. To test move the volume knob on a track, playback, stop. The CC 7 value is sent out every time playback is stopped (not sure this is intentional or not... seems like a bug to me).

I tried to reproduce this, but I could not. Can you still reproduce this? If so, can you provide a more detailed test procedure to get this to happen? Thanks.

[Lorenzo]

And here is a quick screengrab of testing it, hopefully it's useful

[Ted Felix]

It appears as if my changes break loading of volume/pan settings. E.g. try loading one of the example files. It's very likely that the track volume will be 0 for them. More work needs to be done on this before this can be shipped.

[Ted Felix]

Looks like we just need to determine whether <controlchange> tags are missing and fall back on <volume> and <pan> tags. This only affects older files, so not a really big deal. Will get this in shortly.

[Ted Felix]

Should be fixed in [r15765].

[Lorenzo]

Unfortunately it seems that CC7 and CC10 are still sent on the channel used either on channel 1 or on the very first track with thelowest channel number. Unfortunatelly I can't seem to get a consistent thing for this.
I tested this by creating a new device and removing all visible controls. First I thought it was channel 1, but then I tried switching the same track to channel 15 and so CC7 and CC10 were sent on channel 2. etc. Then I tried reproducing and it was just channel 1.

Also this is very inconsistent. I tested with creating a new file and even with the default General Midi device which does have controllers no CCs are sent.

I'm a bit puzzled.

Completely deleting the controller from the device seems to not send anything. But then it means you don't have that controller available any more, in particular in the rulers in matrix and notation.

[Lorenzo]

I think after some testing this might be simpler... Seems RG (even with deleting the controllers from the position menu with 'not showing' will send CC10 and CC7 IF the segment is at bar 1.
I casually incurred into this by shifting the start of piece to bar 2 for recording purpouses and sending CCs disappeared? Maybe someone could cross-test this?
Unfortunately even this seems to be somewhat random :-|

[Lorenzo]

Update: CC7 and CC10 are also sent if playback is started at the same time as the segment starts. Example the segment starts at bar 2, you position the playhead at bar 2, stat playback then CC10 and CC7 are sent

Hopefully this can help hunt the unwanted behaviour

[Ted Felix]

Sounds like this is working as designed. If playback starts within a Segment, a search is performed to find out what the CCs should be at that point in time and those CCs are sent to make sure synths are up-to-date with what is currently going on at this point in the Segment. The beginning of the Segment is considered "within" the Segment for this purpose and (I think) that's why you are seeing these.

Sounds like what you want is finer grain control of the various features. Not a problem if we can come up with a set of features that works for you. Here's a proposal. Might not quite match what you need, but should be a complete enough list to start the discussion:

1. CCs at file load. I assume you have no need for these.
2. Ability to tweak CCs from the Instrument Parameters (MIPP). No need for this as it simply drives the automatic sending of CCs at file load and temporary sending of CCs during playback.
3. CCs sent at playback. No need for those. Note that this means that playback from the middle of a Segment could end up a mess. But I guess if you never start play in the middle of a Segment, it's not an issue.
4. CCs in the Segment sent as usual. This is pretty much a given. Nowhere do we prevent these.
5. Matrix and Notation Rulers. Enabled always for editing of CCs within the Segments.
6. Ability to use the MIDI Mixer Window. This is the same as the MIPP, so it should probably also be disabled.

Am I missing anything here?

[Lorenzo]

I'm not sure I get you: we are talking about sending CC10 and CC7 which were removed from the panel, so in theory they should "never" be sent, even if playback is tarted at segment start?

The most straigthforward IMHO would be:

ALWAYS send CCs upon playback/stop (depending on CC):

• they are in the segment - meaning as events (e.g. drawn in the matrix edior, input in event editor, embedded in an imported midi file, recorded (e.g. a CC7 volume slider the user moved when recording)
• on stop send CC123 and CC64 to avoid note hangs etc.

Send CCs in both MIPP and Mixer window (saame) ONLY if they have a position and therefore show in MIPP and therefore Mixer (from Manage Controllers window)

Makes sense?

[Ted Felix]

I think I get it now. Since the knob isn't visible, why should it still have an effect on anything?

As I'm thinking this through, there are some subtle problems that might creep up in certain situations. (The search for the previous CC value comes to mind.) I need to spend some time looking more closely at how this works, and put together some examples and test plans to illustrate the issues and then hopefully we can mitigate the problems and refine the requirements.

[Ted Felix]

Seems like compositions created with 19.06 and before, that are then loaded into the current svn, have problems similar to what you describe. I'm not seeing CCs going out at playback, but I am definitely seeing them go out at file load. So, something is wrong.

It's probably yet another case I hadn't considered when getting rid of the pan and volume attributes in the file format. More digging needed...

[Ted Felix]

I suspect there may be a workaround...

• Load up the file that is causing trouble.
• Re-add the knobs for the CCs that are being sent out (e.g. volume and pan, give them IPB position numbers).
• Delete those knobs (<not showing>).
• Save the file.
• File > New.
• Now load the file you just saved.

This should be the end of CCs going out.

Just a theory. I was able to make this happen with my test compositions. Let me know how it goes.

I'm looking into a less irritating solution right now.

[Ted Felix]

Unexpected CCs problem should be fixed in [r15961]. Please test and let me know how it goes.

[Lorenzo]

Hi Ted, thanks for this! I'm a bit limited in time bandwidth at the moment, will try to test asap!.
Lorenzo