First simple approach to CC11

Posted 4 years ago

Hello everyone,
first of all thank you for your helpful comments and thanks for all the help and patience from MuseScore people on IRC! You guys rock!

I got a little update on the CC11 (de)crescendo. I thought writing some code would help and will bring me to the actual problems - and so it did. First things first - here is my branch in which I'm working on CC11.

What does CC11 do in SF?

The main "problem" is that CC11 (like CC7 and velocity) are "just" modifying the attenuation generator according to the sf spec. So all we got is attenuation. That makes decrescendos pretty easy (does it? - see more down below) - since CC11, CC7 and Velocity work in the same matter in SF - so they are interchangeable. All we need to do is lower the CC11 in the same fashion as we would do with velocity. That works - at least for a start ;)

But how do we do crescendo if all we can do is make things quieter? I came up with the solution that I simply change the velocity of the chord/note to what is shall be at the end, and then lower it to what it should be at start via CC11 and than pump CC11 all the way up to 127.

Not that simple...

But sadly everything is not that simple. Since attenuation is curved it doesn't add up that nicely. It works for a start but probably there has do be some more exploration if we can do better!

When to go back to normal?

Another thing is when we're going out of CC11 changing and back to what it should be? In my first naive and simple approach we reach CC11 changing end at chord end minus two ticks and change back to value 127 (no attenuation) at chord end minus one tick. That leads up to jumps in CC11 that might not be that nice. I think when I investigate in how to better add up the values I might have a look into that. A simple solution might be just doing CC11 with value 127 on every note that isn't a crescendo at the beginning. But that is stupid - maybe something better comes up! Also I'm assuming that the note is as long as its value - that is very unlikely the case. So gate should be acknowledged in the future.

Code organization

Currently the code rests in its in its own method and looks for hairpins. A better and more general approach would be to put it inside the same method that puts in midi notes and check whether start and end have a different velocity and put in CC11 according to that.


I think the whole concave thing with attenuation becomes pretty easy if I would just set every note to velocity=127 and then just use CC11 for setting the actual attenuation during (de)crescendo.

Maybe you could set C11 to 63 (half of 127) and then you can increase or decrease it as required?

Or maybe you could set the velocity to a fixed value for all notes and implement dynamics entirely through C11?

Edit: Our posts crossed - it looks like you had the same thought! Maybe set the velocity to 63 rather than 127 so that the user can override it with something bigger via the inspector (unless you would prefer override to affect C11 rather than velocity).

In reply to by shoogle

if you use half as a start you cannot modulate the whole spectrum what would be possible - also the two values add up in a curved way (as I described above). CC11 to 63 means about 12dB quieter than normal - which is nor desirable if that would be the default.

I try to work out some code and hopefully some sound examples.

It would be very wasteful to add CC11 for every note.
Setting velocity to appropriate level at each dynamics marker, using CC11 only during (de)crescendos, changing velocity at start of crescendo and at end of diminuendo sounds best. Step changes one tick before end may be indistinguishable or may be an acceptable side effect. (Playout is not the prime consideration of MS!)
You also need to consider instruments that do not change volume between notes, e.g. piano. Each part should have a setting to decide if volume changes between notes. This should ideally be automatic, based on instrument but user may override if required.

In reply to by riban

Thank you for your comment! I think most of it has already been considered. I'm about to write a bigger technical post about what it is in Fluidsynth and what I think might be good options.

I think I should also have a look at some other synth and see how they treat CC11.

Another thought: If you reset CC11 at end of (de)crescendo, it will affect the volume of the release of the note which may be significant. It would be better to reset CC11 just before the next note which might not be for several bars. The calculation for this would best be done at play time rather than compose time. To do so at compose time requires checks to be made after each change to the score whereas computing at play time allows the CC11 track to be calculated once, just before playback. It is better to introduce any delay / latency at pre-playback rather than at each score edit.
Also, rather than change CC11 before the note, can it be done on the same tick as the note but prioritising CC11 so that it is sent before the note on event. I know this seems bad, pushing the important "note on" event but it may prove appropriate.

How can I help testing and become a Beta tester if its possible? I use the program everyday and know C++ a little bit as well

In reply to by hpfmn

well right now I will have to read some more on C++ because Im not that good yet but I believe I will be ready in a few weeks. about the beta Im currently downloading the nigh version and should I send you the comments on what works and not?