Crescendo/decrescendo playback

I think it is important to better define what you mean by [de]crescendo. There are 2 ways to realise one. The first is to change the volume of a note over time. This is the way wind instruments do it. The second is to change the attack velocity of each note when it is first sounded. This is the way percussive instruments such as piano do it.
The second is probably much easier to do and I think museScore probably already has the capability. All that is needed is a GUI to make it easier to do so, rather than manipulating the velocity of each note individually. I vote for coding in the program, but a plug-in could probably work too.
As for the first method, not knowing all the ins and outs of it, I see several problems. There are several MIDI controll changes that would do the job--namely "Chanel volume", "Expression Controller", and "polyphonic key pressure (aftertouch)". The last one seems the most flexable and best suited to the job, but I don't know if most computer sound-cards support it. Does anyone with more expertise know?
The first one could probablly also work, and I think it might be better supported on sound cards, but all notes on the entire channel would be affected, which may or may not be what you want in a given circumstance (eg. it would not be possible to change the ballance between divisi instruments.
This is purely speculation, but I see piano-type crescendos coming pretty soon, but wind-type crescendos taking much longer--on the order of several releases.

You might be interested to read this: http://musescore.org/node/4588 . It looks like dynamic and tempo changes are a focus for this summer. Yay! I know I've been continually frustrated by the inability to save more than one tempo in a measure, too. (it works fine until you close and reopen).

For the record, MDMilford was talking about this bug : #3750: Mid-measure tempo changes not saved correctly

@Tato Please keep on the discussion about velocity and plugins here : #4983: Add read/write access to note velocity in plugin framework

Any news about crescendo playback?

-

+1 for Crescendo/Diminuendo playback. In the mean time I may attempt to write a plugin for this, not sure if I can, but I'll try.

OK, never mind, I was looking through the plugin development page, and I do not see any kind of objects for the lines, meaning there's no way to write a plugin that could find crescendos or diminuendos and edit the note velocities accordingly. If I'm missing something please point it out. This is ridiculous, I mean, I love this program, it is amazing, but this is one big annoyance, it seems like a pretty necessary feature to me. Please either implement playback, or give us more plugin objects so we can write plugins ourself. There should be objects to edit everything on the score, lines, dynamics like pianizzimo and forte, all that stuff.

@KoRnKloWn If you wish to encourage the MuseScore developers to further improve the plugin framework, this is not the way to do it. You are talking to people here, not to robots. So please consider your tone.

Yes, any object and attribute should exposed through the plugin framework. That's a no-brainer. However, it would be a waste of resources currently to extend the plugin framework while the internal MuseScore model is still heavily developed. For more than a year now, the MuseScore trunk has been in flux to make it ready for professional typesetting work and extend if to support tablature notation and more. Only when this effort has come to an end with the release of MuseScore 2.0, focus can shift again to improve the plugin framework. I hope this can shed some light in what phase MuseScore currently is.

Btw, there are a number of playback improvememts already in 2.0, but I don't remember if crescendo is one of them.

While the plugin framework doesn't allow you to find crescendos, you could still write a plugin that operated on a selection. Select a region, runthe plugin, up comes a dialog saying what the starting and ending dynamic should be be, and then adjuet the velocities of the notes within the selection. You can't crescendo within a single note that way, though.

Meanwhile, just be aware that the main focus has been on notation, with playback features lagging behind a bit. I'd expect to see continued improvement in both areas, but, as should be the case, deficiencies in nptation will generally take precendence.

That's actually a good idea, I think I'll try something like that, it's at least a quick fix, and I'm also going to try to write a plugin for generating Creative Commons license for you score. And sorry if I gave off the wrong tone, it makes sense that they have priorities, I was just irritated a little because I'm converting all my scores from Sibelius, which in itself is no fun task, I had to look everywhere to get a free version of the MusicXML exporter (they want $200 for it), and the free one really doesn't work that well, so I had to fix everything, including the crescendos and diminuendos. And the reason I need playback is because I export my songs as midi, and I use to import those into FL Studio, but now I'm switching to LMMS with free sound fonts and VSTi, so I need to be able to have the crescendos in midi, or it just won't sound right. Anyways, thanks for the reply, I don't know why I didn't think of that workaround, I'm going to see if I can write it (the plugins don't look to difficult to write).

FWIW, it looks like the most recent version of Sibelius just released last week has MusicXML support built in. Assuming it works better than the free tool you are using, that might help, and the upgrade might be cheaper than buying the official MusicXML export facility.

Well it's about time they added the support! Thanks for the info, but I'm not going to purchase something I'll only use a few times, I've already gone through the trouble of converting most of my scores.

The only real problem I'm having is midi support or playback of the crescendo and diminuendo. But I'm writing a plugin for it right now, it's my first plugin though, so it's taking me a while to get it to work correctly. Basicaly what it will do, is you select the area for the dynamic and you must either have a dynamic marking like pianissimo or forte at the beginning and end of the selection, or change the first and last note values yourself, and it picks up the first and last velocities, finds the difference, then divides by the number of notes/chords, and increments up or down accordingly.

The plugin I'm writing is coming along, however I'm running into a problem where the note.velocity will not return an integer, not sure why.

Just wanted everyone on this thread to know I just finished my plugin and it seems to work great, I just used it on one of my scores, I fixed all the bugs I could find, and if you want to downloaded just head over to the plugins, you'll see it under Set Crescendo or Diminuendo, and there's instructions on how to use it.

Direct link : http://musescore.org/en/project/crescendoanddiminuendoplayback

OK time to put in my threepennorth :)

Further up the screen someone commented that there are three ways to implement Crescendo and Diminuendo in MIDI:-

Changing Note velocities for which I believe we have a plugin
Volume Controller
Expression Controller.

In a past existence as a backing track programmer I was using first Cakewalk ProAudio adn then Sonar 3 for the production of backing tracks, and I'd just like to pass on some MIDI programming conventions to you.

1. As previously stated wind instruments do not use velocity values for expression - on a suitably sophisticated Soundfont it would be used for triggering the particular attack sample before the note settles into its sustain phase, and in some MIDI implementations (XG for example) you have control over Attack, Decay and Release phases of the particular sound you are using, which makes it possible to emulate the different attack a brass instrument has when blown hard rather than softly.

This is obviously currently beyond the scope of MuseScore as it requires MIDI programming at the Event Level.

2. The MIDI Volume Controller is usualy used to set the balance between the voices, as the Mixer window does in MuseScore. This should not be changed.

3. The way to perform dynamic changes on wind instruments is to use the MIDI Expression controller which IIRC is Controller 11, as it works within the level set by the Channel Volume controller.

Of course you are at liberty to use the Channel Volume controller for dynamics, however this will completely screw up any levels set in the Mixer window.

These comments about the Expression Controller also apply to strings, which also can change attack with the application of a different Velocity.

I suggest therefore that at some future point MuseScore develops compatibility with the Expression Controller, and enables the user to select which kind of crescendo they want, possibly in a dialogue box attached to the (de)crescendo sign.

Incidentally I am very experienced with MIDI, particularly the XG flavour - I wrote a controller program for the Archimedes series of computers which allowed you to manipulate the DB50XG daughterboard card called ArmEdXG. If you need advice or information on anything MIDI related I would be only too happy to help - unfortunately I can't help with the programming side as I never got round to learning C and my fluent programming language disappeared with the Archimedes when Acorn went into liquidation in the mid 90's.

Regards
Michael

Excellent information. I'd forgotten about the controllers.

Thanks.

Forgot one thing.

The aftertouch controller is also mentioned.

This is usually used for stuff like vibrato and changes to the release envelope etc.

I suggest that certainly at the moment these are beyond the scope of MuseScore, although when it becomes time to implement playback of glissandi, the Portamento controller is the way to go, not pitchbend which affects the whole channel.

Regards
Michael

Is this implemented yet in development version of MuseScore? Otherwise +1 for this.

@subha yes, it's implemented for 2.0. For 1.x, you can use a plugin: http://musescore.org/en/project/crescendoanddiminuendoplayback

Just thought I'd chime in with a possible (easy?) implementation I thought of. What if there was a layer of abstraction on the Mixer's volume control? Instead of it controlling the channel volume directly, it changed a parameter in the resultant channel volume, which would be the product of notated volume and Mixer volume. That way, when a dynamic change is reached, the notated volume could change the channel volume, without changing the user-specified Mixer controls.

There are a couple of implications for this. Note velocities should remain constant. Wind and bowed instruments would sound great. Piano and guitar could sound weird, since a sounding note could get louder during a crescendo. This could be fixed with an instrument parameter, whether to linearly interpolate over time, or change when the note changes. However, in the later case, when notes are sustained through a dynamic change, they would suddenly change in volume while ringing - this is where note-level velocities are useful.

Perhaps a combined solution would be better. For wind instruments, use the channel volume change method; for pianos etc., change note velocities.

This seems to have been partially / mostly implemented - and the Inspector shows relevant settings - but currently seems to not work at all.

Fixed in 835bb05dab

Hmm, I can make the crescendo work now by entering values into the Inspector, but any dynamic at the end of the crescendo now seems to be ignored?

1) open attached score
2) play

Result: fff is ignored

After discussion on IRC, I think I understand the behavior better now, but I think it's the wrong default, and I have a proposal or two on how to improve it.

Currently, the default delta value for crescendo is 10, which is very subtle. That's not ideal, but would be OK if adding a crescendo didn't cause the next dynamic marking to be completely ignored, if it occurs on the note following the crescendo (which is the propert place for it). The crescendo can be calculated with a delta value of 10 if the Inspector says to do so, and that's fine, but then there should still be a jump to the specified value at the end of the crescendo. The end dynamic shouldn't be ignored just because it occurs on the next note after the crescendo. That much to me is a bug and should be fixed.

However, a more interesting question is what should the default delta value be for a hairpin in the first place. I think it should be calculated automatically based on the dynamic just before the hairpin and the next dynamic value encountered afterwards. It turns out that this is already supported - if you enter "0" as the value in Inspector. So that's my next suggestion: make "0" the default. Then it has the right effect automatically, if you place a dynamic marking after the hairpin (which is always a good idea for human performers as well).

The only downside of this is that currently, the code for handling a delta value of "0" looks for the next dynamic marking *anywhere* after the hairpin. It could be many measures later, and have nothing to do with the hairpin. Realistically, you can't count on the following dynamic to be on the very next note - it's not uncommon to place it a note or two later for spacing reasons. And I'm not sure it makes sense to invent some arbitrary rule like "only look for next dynamic marking within the current or next measure". I'd actually be OK with the current behavior of "0" - even with respect to it using a dynamic that occurs many measure later - if we made one small tweak to the algorithm. Right now, if your score looks like this:

f < ............................................................................. p

where the dots indicate a whole bunch of unrelated stuff after the crescendo, the current behavior of "0" is to make the crescendo after the "f" play "backwards" - it will decrescendo to "p", since that's the next dynamic. So I'd like the automatic handling of "0" to detect "backwards" crescendos and simply revert to doing nothing. Then the user can enter an appropriate value for himself, or enter a dynamic after crescendo (a good idea anyhow).

So, those are the changes i recommend:

1) fix the bug where an ending dynamic on the note after the hairpin gets ignore
2) change the default for hairpin to "0" so we get the automatic behavior
3) detect "backwards" hairpins when processing "0" and revert to actually using a delta of 0

Currently, the default delta value for crescendo is 10, which is very subtle.

Agree. It's barely audible. Something between 15 and 25 may be more appropriate as a default value.

Are you using the latest build? This was fixed a day or two ago I believe. The default is now "0", which automatically calculates the values from the actual dynamics in the score. Works great for me.

Check and mark this "Fixed" if so, otherwise, post the specific score you are having problems with and steps to reproduce. You will have to delete and re-add any crescendos created in earlier builds.

Using the latest commit, the default velocity is still 10, so dynamics are not included in the calculation. Steps:

With MuseScore e9f40af on Xubuntu 14.10, I create a new piano score from scratch (see the attached file), and put some notes and dynamics (from pp to ff and from ff to pp). When I add a crescendo or a decrescendo, the default value for the field Velocity change is 10. During playback, the crescendo and the decrescendo are barely audible. It's like if it plays directly from pp to ff, and from ff to pp.

Are you *sure* that's the commit you are actually running, and that you don't have an older build lying around getting in the way? The fix was just made yesterday. When I open your score, I can see that indeed the velocity is set to 10, but if I delete the hairpin and add it again - using either keyboard or palette - it gets added as 0.

Also, how are you adding the hairpin? If you are using the palette, I suppose a reset to factory settings couldn't hurt, although I don't think it should be necessary either.

Yes, I'm sure I'm using the latest commit. But your comment about palettes helped me to find the problem. I add hairpins from the palette. The problem comes from my new workspace. So when I change the workspace to "Advanced", the default velocity is 0. I didn't realize that all default palettes were copied (even if they're not edited) in a new workspace, and so would not be updated if default values are changed. Thanks.

Automatically closed -- issue fixed for 2 weeks with no activity.