Trill features have no playback

• Jun 15, 2015 - 23:22

I tried to use the trill features, they do not play back. Also, that wavy line that exists in all of music with the trill, the trill doesn't have that/ It just shows tr.


Comments

The trill with the wavy line you're referring to exists in the program.The trill ornament without the wavy line can be found in the "Articulations and Ornaments" palette. This one is used on notes where is would be superfluous to add a line (for example, on short quarter notes). The trill with the wavy line can be found in the Advanced palette, under the "Lines" menu. This is used on longer notes and passages, if necessary.

I don't know why the program doesn't play back trills, however. It probably has to do with the fact that this is more of a notation based program than a playback based one.

In reply to by MasterFrank

Actually, in the upcoming 2.0.2 release, the version of the trill from Articulations & Ornaments will affect the playback, along with the various turns and things from the same palette. I'm hoping that the same thing will be implemented for the corresponding Lines in time, too, but that may have to wait for later releases. You can download a sneak preview and check the new playback out: https://musescore.org/en/download#Nightly-versions

What is the plan with compatibility when 2.0.2 goes public? What happens when older scores in which there were trills that never articulated are played with 2.0.2? What happens when scores made with 2.0.2 in which trills are articulated are played by older versions? Can they be, or does upgrade to 2.0.2 shut out play by older versions? What version will the website player use?

In reply to by [DELETED] 1831606

Just to be certain I understand what you're saying: You'd like it if, when dealing with a score containing trills that was created in a version of MuseScore where trills did not play back, that score's trills would still not play back when loaded into a version of MuseScore that does play back trills?

In reply to by Jojo-Schmitz

That's absolutely needed (per trill) in any case, but I'm trying to imagine-through several scenarios. The most important is the web site (or any body of old scores) -- there are thousands of scores with ornaments written "for looks", perhaps even some of them with manually-executed trills in auxiliary voices or staves, but many (I've penned several) with trills "for looks" (appearance) with no intent of them being heard until they can be debugged. So you need (at least) a per-system switch that says, "don't articulate trills in older (pre-change) scores." You can't have a per-score switch, because the instant you save out the score, it is no longer a "pre-change score", and you are responsible for all the trills. You don't have to save it out if you don't want to work on it. But you might want a per-score switch (in new scores) disabling all trills to get the old behavior if, perhaps, you are upgrading a score, and don't want to deal with the trills yet, but this last feature is not really necessary.

In reply to by [DELETED] 1831606

I think *most* people would *want* existing scores affected. Only a relatively few would be unpleasantly surprised by the change. I'm not sure it makes sense to have the default favor the few over the many. Although I can see arugments both ways for sure. So I have no strong opinion on this.

Anyhow, the problem with bumping the version number number is that it is all or nothing: once we decide that 2.0.2 has a different version number for its generated files, that means older versions of MureScore will refuse to load the score. That's not an option.

What *is* an option is to have the default for the "Play" property be "off" across the board, but have the *palettes* in 2.0.2 explicitly set it to on. So while the default would technically be off, and existing markings in existing scores would use that default, and newly added markings would be set to "on".

In reply to by Marc Sabatella

Now, that is an interesting idea. On the other hand, I think it would probably be a very pleasant surprise for most people to have these kinds of things play back in their old scores—at least, for example, I loved hearing the trumpet glissandos in this pre-2.0 score play back in a nightly build: https://musescore.com/user/13522/scores/117784 And while it would take time and work to turn "Play" either on or off for all such elements in existing scores, if the default is off then people may not even realize they have the option.

EDIT: The only downside would be (though this seems counterintuitive at first) that there are some people who would really, really like the hear their trills played back—and those people might have manually created trill effects in hidden staves to accompany a trill symbol on a note, as BSG pointed out. Having the two "trills" playing simultaneously might not be a very pleasant experience. Adyson's Epic Genius Medley (which anybody who was a beta tester of MuseScore 2 will probably be familiar with) uses "glissandos" in bright blue (https://musescore.com/user/110286/scores/185645). I haven't tried playing it in a nightly yet.

In reply to by Marc Sabatella

There is a lot of assumptions in this thread. So let me put it right.

First, the scores on MuseScore.com are rendered once and for all, except if the user edit the score via the "edit the score" form or via the "Save online" feature in MuseScore.
Second, we are all working hard to make MuseScore better at every version and so we all want all MuseScore users to use the best we have to offer, which means the latest greatest.

1/ Score uploaded (or updated) on MuseScore.com before the release of 2.0.2, and made with MuseScore 2.0.x, will not play the trills, bends, glissando etc...
2/ Score uploaded (or updated) after the release with MuseScore 2.0.x will play trills etc... It means that a composer using 2.0.1 and uploading on MuseScore.com will hear a different playback. I believe it's a good thing, this composer needs to upgrade to 2.0.2 so it enjoys the new features and the bugfixes. We might even warn him on MuseScore.com that the new version is out.
3/ Scores uploaded with 1.3 (hopefully less and less) are rendered with MuseScore 1.3 in the backend. So they will not play trills etc... This will change in the future, meaning we will first display a warning and then switch to render them with the latest MuseScore 2.0.x by default.

4/the case where people went to the trouble of creating their own hidden notes for playback
I believe these users are somehow hackers and they are a minority. If they hacked, they know the risk. I wouldn't hurt the majority because of few hackers. Also, as explained it will not impact the existing scores on the musescore.com website.

The other part of the equation is the mobile apps. In the apps, the scores are rendered on the device using the latest greatest version. The playback and layouting of all scores is done with the latest 2.0.x (of course there is a delay between the release of MuseScore 2.0.x and the update of the app and the website, we don't have the bandwith to do it all in one day). So apps will play trills, etc... for all scores. If a user used hidden notes, they the playback will be bad... too bad...

In reply to by [DELETED] 5

I'm confused here. A "hacker" now is a malicious softwarist. "Rendering ornaments in hidden voices and staves" isn't patching the assembly-language code, but the officially recommended, only way to execute ornaments and not visually damage the score. I and others who try to produce high-quality performances and scores with MuseScore until now have had no other way. It's not like this is this was some sneaky kludge which was frowned upon and discouraged; it is something which was recommended, and if the new ornaments don't fill every exact need (how could they?), it will still be necessary.

Fortunately, every time I (at least) do this, I silence the unexpanded note (carrying the written ornament), so I surmise it will continue to work as I upgrade the scores. Maybe others do the same. That has to continue to work.

The argument about the snapshotted rendering does address the major concern, though.

In reply to by Jojo-Schmitz

I came from the MIT computer culture, and I know firsthand what "hacker" meant 30-40 years ago. It no longer means that: it now means "cybercriminal", and to "hack" is the criminal offense of breaking into a computer system, not to "work arduously and competently." Jargon ("programmer_subculture") dictionaries of 40 years ago are no longer relevant to today's headlines. If you meant "people who work arduously and competently at preparing exacting MuseScore scores", then that is surely no argument for not supporting our work!

Yes, it was a workaround. And it is still a workaround for ornamentation not fully expressible in whatever paradigm is offered. It does seem wrong to break the work of sincere, rule-abiding users who did the only thing possible (but it may or may not, depending if they silenced their visible part).

Any time a newcomer would complain, "uhh,, trills don't seem to work", the answer would be posted, "MuseScore is first and foremost a notation program, not a performance program. If you need exacting (i.e., as written) performance, use some other program to postprocess the output, or make a second track or voice with your intended execution. We will get to ornamentation and other execution issues behind all score issues."

In reply to by [DELETED] 1831606

It was a workaround and is no longer needed, that's all. And I'm sure lasconic did not mean 'hacker' to be a cybercriminal.
If you had silenced the visible notes, that score would still playback the same way (play the hidden ones, not the visible ones, hence not there articulation), I think. When in doubt, try with a recent nightly build

In reply to by Jojo-Schmitz

Valiant attempts to shore up a word which has already gone bad in the larger social/linguistic context. I myself still say things like "JSB remains the greatest counterpoint hacker of all time!", but anyone except computerists who have been around a long time will scratch their heads.

There is a fuzzy boundary of interest where "hacker tools" such as assemblers and low-level debuggers may face the same future as lock-picks. But this is hardly the proper forum for this discussion.

What is the ETA of 2.0.2?

Do you still have an unanswered question? Please log in first to post your question.