Tab input via keyboard in non-standard tuning (bug?)
Musescore 2.1.0 AppImage downloaded a few minutes ago, Linux Mint 17.1, 32-bit
Tablature input via keyboard does not work as intended, I am unable to enter "a" or "b" on the lowest string.
I am transcribing "lyra-way" music for viol, and have just started working on pieces where the viol tuning is non-standard. In this case, the two lowest strings are tuned a fifth apart (kind of like drop D tuning a guitar).
I have edited the string data in staff properties to reflect this. (I started from scratch with a completely new score, with no "parts" involved at all, as I know these can cause mischief, and I edited the staff properties before I did any music entry at all, because this has caused me mischief on previous occasions.)
So, yesterday, note entry via the keyboard was working as expected, and today it has reverted to a familiar problem. I am unable to enter "a" or "b" on the lowest string. Whichever letter I key in, Musescore translates two letters up. (If I key "a", a "c" appears, if I key "d", an "f" appears, and so on.)
It is as though Musescore is reading each letter I type as the note it would have been on a standard-tuned instrument, if that makes sense.
Anyway, I am attaching a file for anyone who cares to to experiment with.
Open the file, go to note input, move the input cursor to the lowest string, key the letter "a" and tell me what happens! (On all other strings, behaviour is as expected.)
Again; I swear on my mother's grave that yesterday this worked, and today it doesn't
Thanks in advance.
Piers.
| Attachment | Size |
|---|---|
| TabIssue.mscz | 19.52 KB |
Comments
Serious? 2.1.0??? 2.3.2 is the last 2.x, 3.6 (!) is the currently latest available one.
Don't use utterly outdated stuff, please.
Same goes for a 32-bit Linux (and to slightly a lesser extent for a 32bit Windows)
In reply to Serious? 2.1.0??? 2.3.2 is… by Jojo-Schmitz
When I build another computer, I'll probably have to go 64-bit architecture, but while my present sixteen-year old computer continues to work, I'll continue to use it. It works perfectly.
The Musescore developers offer a 32-bit program, that's the one I'm using because it is the most recent 32-bit version available.
I've just been playing an 1869 violin in my music room, a cellar which is known to date back to before the arrival of William the Conqueror.
Sorry if this offends you.
If you are able to help, your help would be welcome.
In reply to When I build another… by pierssnell
The MuseScore developers stopped providing MuseScore versions for 32bit Linux long ago. And indeed 2.1 is the last one that is provided. It is almost 3 years oly by now.
The only 32-bit version that still is being provided is for Windows.
Old is not the same as outdated. You violin and cellar are old, your PC, Linux- and MuseScore versions are just outdated, Computers and their software don't get better by getting older and they do age must faster. But I'd bet your violin and cellar got some maintainance in the past decades and centuries (you're surely not using the original strigs on the violin anymore, nor the exact same bow), as did MuseScore, by updates.
Anyway: I've opened your score in MuseScore 2.3.2 (reveals that the score is even older, from MuseScore 2.0.3). Looking at the staff properties shows that it is for a 7-string Viola da Gamba (?), the lowest string being an A1 (?!), the tablature only has 6 strings though (!?)
The title claims this to an an FFEFH tuning, the string data though claims it to be D4, A3, E3, C3, G2, D2, A1
I must say, this all confuses my quite a bit?
In reply to The MuseScore developers… by Jojo-Schmitz
Yes, that is ffefh tuning, with a redundant string, which happens not to be used in this repertoire, therefore the string data is irrelevant. The instrument has seven strings, the repertoire doesn't.
But I am interested in which string data claims tuning to be D4, A3, E3, C3, G2, D2 and A1. Where did you get that from? When I go to Stave Properties > Edit string data, the 6th string shows as C2, which is what I set it to. The desired tuning is also reflected in play-back, by the way, and if I copy and paste the music onto a 5-line standard staff, the desired tuning is correctly reflected.
It is only the input of tab letters that is the problem.
Brer Fox has confirmed that the same behaviour is observed in 3.5.2.31, so we know that the problem isn't with my computer, but with the program.
(Again, if you are able to help with my problem, your help would be very much welcomed. I don't need your help with my life choices, thanks.)
In reply to Yes, that is ffefh tuning,… by pierssnell
right-click into the staff, staff properties, string data. I don't see a C2 there, but D2
Edit: in 3.5.2 and 3.6 that is. In 2.3.2 I do see a C2, this is getting stranger and stranger...
Yes, there might be an issue with the program (and, by the currently looks, even 2 at least), but only if it is a problem with the latest version it stands a chance of getting fixed. And that fix then won't help you, as it won't be made available as a 32bit Linux AppImage. So if indeed there is a bug in the program, you got to live with it until it got fixed and you updated your outdated hard- and software...
In reply to right-click into the staff,… by Jojo-Schmitz
Thanks. I take the point about not hoping for a bug fix.
But my motivation wasn't in fact to report a bug, it was to solve a problem. If there's a bug, someone else can report it!
My best hope will be that a fellow user might be familiar with this issue, and have found a way of changing settings in such a way that they actually stick.
After all, I do know that the "Edit string data" mechanism does in fact work, for me, on this machine. It worked on Thursday, it just didn't work on Friday.
For the time being, I have a work around. I'll do my note entry one piece at a time in a separate file, and then copy and paste into the file that actually contains my "publication".
I tried opening your score in MS 3.5.2.31 and found the same behaviour. There are plenty of "a"s showing and playing correctly on the bottom string but when I tried to add another it came up as "c". I could only correct it by using the down arrow.
I am also transcribing some lyra viol music at the moment and on Windows 10 (64-bit) the current version 3.5 works as it should.
In reply to I tried opening your score… by Brer Fox
Thanks Brer Fox... I think I'm probably stuck with it.
Glad that your current W10 3.5 works as it should, at least at the moment... but just be aware, if you happen to have some non-standard tunings in future pieces, that you might encounter the same issue. Your version might work today, and not work tomorrow. (Mine was working just fine for me when I transcribed that first page, it only stopped working on the second page!)
Good luck with your transcriptions!
In reply to Thanks Brer Fox... I think I… by pierssnell
I don't know what exactly you wanted to do, but the numbers 1 and 2 (at the beginning of the first page, and at the beginning of the second) appear as Instrument Change - image below.
Delete them and the input will return to normal. See: TabI.mscz
(If desired, instead, you can add simple text, in bold, if you perhaps wanted to indicate a highly visible page number in this place ? )
In reply to I don't know what exactly… by cadiz1
Outch, that mega-hertz...
In reply to I don't know what exactly… by cadiz1
cadiz1, I am hugely indebted to you! You are a genius. Thank you so much for spotting this.
I haven't tested this in depth at this stage, but I can very easily believe that this is what has been causing the problem, and therefore have confidence that using an alternative text style will solve the problem.
It must have been a very long time ago, in my early days with the program, that I happened to pick on using this text style for this particular purpose -- it was just a text style with the right characteristics, and it has simply "stuck", because I recycle templates across different projects.
I see absolutely no good reason, in terms of program design, why the presence of an instrument change instruction should "corrupt" the staff settings in this fashion -- in some versions of the program but not in others... but we have to accept that it does. It's just bad design.
You have (I believe) solved my problem. Thank you.
In reply to cadiz1, I am hugely indebted… by pierssnell
You'd change the instrument and so also the tuning. Explains why I saw a different one, I was just looking at a measure after that instrument change
In reply to You'd change the instrument… by Jojo-Schmitz
Yes, I can see where the mischief was created.
I still can't see why examining the staff properties should present misleading information in the way they do, or why the software should jump to the conclusion that just because you've picked up a different instrument, you now require different staff properties -- and staff properties that make it impossible to enter notes within the parameters of those self-same properties.
Anyway... I'm cool. The problem is solved.
In reply to Yes, I can see where the… by pierssnell
Because a full drumset and a triangle have different staff properties to take one example.
In reply to Because a full drumset and a… by jeetee
Yes.
But you SHOULD be able to rely on the information you are given about the staff properties of the staff on which you right-click. Otherwise, what is the point of right-clicking on a bar so that you can see the properties of that staff, at that bar?
Really, there's no excuse.
But I am entirely happy to hear, via Mr Sabatella, that the instrument change feature is now better designed. Rant over, as they say.
In reply to Yes, I can see where the… by pierssnell
In current versions of MuseScore, you wouldn't be as likely to make this mistake, since adding the instrument change will immediately prompt you to choose the new instrument, thus making the actual purpose clear. So yes, the design in the version you are using had room for improvement, and it's now improved.
In reply to In current versions of… by Marc Sabatella
Yes... that is indeed a healthy sign.
In case of doubt, I am absolutely absolutely not "down" on MuseScore. As far as it goes, it does its job astonishingly well, and I'm not paying for it. Win win. If anything I have said makes me sound ungrateful, scrub it from your memory... I like this program, I like it a lot.
In reply to Thanks Brer Fox... I think I… by pierssnell
EDIT: Just seen cadiz1's post above which solves the problem. Use Ctrl+T to add staff text to number your pieces.
I've never heard of a 7-string lyra viol - have you?!
In reply to I still have Musescore 2.2.1… by Brer Fox
See above, it seems those (most probably inadvertant and well hidden) Instrument changes are the culprit
In reply to I still have Musescore 2.2.1… by Brer Fox
No -- but I have an idea that there might be one or two historical sources which were originally published as intended for lutenists or viol-players as alternatives, since so many C17 musicians would "double" on both. Don't quote me on that, but e.g. Ford Musicke of Sundrie Kindes includes some material which is clearly for lutenists, and some for lyra-way gambists.
I think this is a little beyond the scope of a Musescore help forum, and in any case, again, please don't quote me on that!
Linux Mint 17.1 is equivalent to *buntu trusty (14.04) which is… pretty old.
You can probably install the latest 2.3.2 from the PPA: https://launchpad.net/~mscore-ubuntu/+archive/ubuntu/mscore-stable
Unfortunately, it’s not possible to compile MuseScore 3 for such an old distribution. I suggest installing Debian, which continues to support 32-bit systems. (I fully agree with you, by the way; I don’t own any 64-bit-capable hardware, although I have a laptop from work which is 64-bit and this is what I mostly use MuseScore on, because my Linux laptop is an EeePC and this is slow and lacks enough RAM.)
Please ignore the vocal voices telling you to throw money at new computers. New computers suck more.
In reply to Linux Mint 17.1 is… by mirabilos
Good thoughts there, thank you!
I have no plans to upgrade to MuseScore 3 until I am really forced to. If only because I can't do so without a major hardware upgrade.
Upgrades break things. Everybody knows that.
Among other things, I do have worries about how well my "legacy" software can be supported on a system that is wholeheartedly designed for 64-bit. I may be worrying unduly... but when I actually want to turn out something to the very highest standards, my weapon of choice is MS-DOS Score, which has simply never been equalled for power and flexibility. My version 3.11 dates back to the early 90's, and is simply unbeatable when I want to produce results over which I have total control. It's never been usefully updated or maintained since then, and is an absolute bitch to use, with huge limitations -- but those are limitations which I learned how to work around many years ago. I just don't want to invest in a hardware upgrade which will cripple the most powerful software I own.
In reply to Good thoughts there, thank… by pierssnell
Getting to the latest 2.x, 2.3.2, would be an improvement already, without breaking things. @mirabilos told you how to do that.
In reply to Good thoughts there, thank… by pierssnell
Ironic you mention Score in this context - updating to MuseScore 3.6 is actually the best thing you can do if you want your scores created in MuseScore to resemble those created in Score. See https://www.youtube.com/watch?v=XGo4PJd1lng
In reply to Ironic you mention Score in… by Marc Sabatella
I heard there is a new font which emulates many of Leland's ideals.
But if I want Score quality, I'll use Score quality -- which is not just about the font. Using MuseScore with this font plugged in doesn't give you Score output, or Score power and flexibility.
(I've already got Leland's "original" font of course, built in to the program I already own, as well as font "libraries" with some handy tweaks made by third parties.)
When I want to do really serious work, I have available to me not just Score on its own, but a powerful set of tools developed by third parties, which offer incredible flexibility and user-control over spacing and justification algorithms.
My present project isn't really serious, in that it is not intended for publication, and MuseScore's output is easily good enough for present purposes. In terms of ease of use, for this particular type of notation, MuseScore gives Score a kicking, a really good kicking!
In reply to Good thoughts there, thank… by pierssnell
You can easily get 3.x on 32-bit Linux, just not on one that’s seven years old and severely outdated and riddled with security issues and bugs.
Please consider installing Debian bullseye (11) alongside your Linux-Mint. It’s not yet released but as good as done, and I’ll provide MuseScore 3.6+ for it once it’s left banana software status, and for now you get a 3.2.3 with over hundred bugfixes and backports from newer MuseScore versions from it. It’ll also allow you to run a 32-bit AppImage, although these have their own share of problems.
In reply to You can easily get 3.x on 32… by mirabilos
You're very kind, but I don't need MuseScore 3.6. My needs are basic, and the program I already have does everything I want it to.
By the way -- I can't immediately see what the routine is for editing the thread topic to include a [SOLVED] ... can someone give me a tip on how that's done here?
In reply to By the way -- I can't… by pierssnell
Might be to late to edit the initial post, 24h have passed
In reply to Might be to late to edit the… by Jojo-Schmitz
Wow.
That's a wacky way to run a problem-solving forum. When I'm looking for an answer to a problem, the threads that say [SOLVED] on them are the ones I know are the ones I should read first. And, astonishingly, some issues aren't [solved] within 24 hours.
Oh well, each to his own way of doing things.
Thanks for your input anyway!