Trill features have no playback
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.
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.
Do you still have an unanswered question? Please log in first to post your question.
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 The trill with the wavy line 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 What is the plan with by [DELETED] 1831606
Trills simply won't playback in 2.0.1 and earlier, and will in 2.0.2, using the default settings when coming from 2.0.1 earlier. Same for bends.
In reply to Trills simply won't playback by Jojo-Schmitz
In essence, scores will be compatible in both directions, they'll just play back differently. But the website player is a very good question. I've actually been wondering something similar about #58796: Bracket and instrument name misaligned to one-line staff.
In reply to In essence, scores will be by Isaac Weiss
I would think right an approach where, somehow, the playback of pre-change scores would not be affected, the original authors having had no opportunity to debug or silence the new articulations. The compatibility strategy, then, must provide for such an option.
In reply to I would think right an 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 Just to be certain I by Isaac Weiss
I would like that to be the default, with an option (per system, since by definition it can't be per score) to make it not be so, so that authors could adapt to the new trills at will. You certainly need the former for the website.
In reply to I would like that to be the by [DELETED] 1831606
Why per system or per score? Currently the default for trills etc. are to play, and with Ornament Style Default, and it is per trill
In reply to Why per system or per score? 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 That's absolutely needed (per by [DELETED] 1831606
As the file format version didn't change, there is really no way to detect whether it is an old score or not
In reply to As the file format version by Jojo-Schmitz
Are you telling me there's no "generated by version" in the file format!? Then can't we put one in before it goes public? That would suffice.
In reply to Are you telling me there's no by [DELETED] 1831606
There is programVersion and programRevision in the file, but I don't think it is used anywhere in MiseScore, only musescroe version ="2.06", the former two will change for 2.0.2, the latter won't
In reply to There is programVersion and by Jojo-Schmitz
Do you agree that not enabling trills on older scores on the website is a worthy goal?
In reply to I would think right an 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 I think *most* people would 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 Now, that is an interesting by Isaac Weiss
Yes, the case where people went to the trouble of creating their own hidden notes for playback is the one argument I can think of for default to off in existing markings.
In reply to Yes, the case where people 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 There is a lot of assumptions 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 I'm confused here. A by [DELETED] 1831606
that's a cracker, not a hacker, see https://en.wikipedia.org/wiki/Hacker_(programmer_subculture)
I don't think this has ever been officially recommended. It would have been mentioned as a workaround to circumvent a limitation of MuseScore at the time.
In reply to that's a cracker, not a 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 I came from the MIT computer 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 It was a workaround and is no by Jojo-Schmitz
Will do.
In reply to It was a workaround and is no by Jojo-Schmitz
Yes, I know he didn't mean it as "cybercriminal"! He said so! So that's why I told him that all other meanings of it have withered.
In reply to I came from the MIT computer by [DELETED] 1831606
Actually, the more innocuous meanings of "hack" contonue to thrive in the software world. As it happens, this very moment in Barcelona a "Music Hack Day" is taking place - see https://www.hackerleague.org/hackathons/music-hack-day-barcelona-2015 - and I believe members of the MuseScore team are present...
In reply to Actually, the more innocuous by Marc Sabatella
Indeed, lasconic and Thomas are there...
And to get even more musical: hammer dulcimer is Hackbrett (Hacking board) in german ;-)
In reply to Indeed, lasconic and Thomas 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?
In reply to I'm confused here. A by [DELETED] 1831606
Upon slight experimentation, it seems to me that even if the "unexpanded note" is not silenced, usually they don't clash but more or less blend, especially in the case of trills.