Enhanced staff properties
I imported the MIDI file of around 7-8 instruments (that was originally exported from a Sibelius file). The result of the MuseScore conversion was a score of no-name instruments, all staves playing piano. (To make it more of a mystery, the only line that was not a piano channel was the celesta line that played flute....)
What I can do at present is:
Create a trumpet line,
Copy the (originally trumpet) line that was translated to piano to this new trumpet line
Delete the (old 'trumpet') staff
Would it not be possible to associate any staff (Staff properties dialog) to a selectable MIDI instrument? The same (or, perhaps a 128 GM instruments-only) roll-down box could be used as offered in Create Instruments. After all, I assume, the same association is made there (albeit to an empty staff).
Comments
You can change the "playback instrument" for a staff in Display -> Mixer
In reply to You can change the "playback by [DELETED] 5
I tried your suggestion - it worked, served the purpose somewhat - (and I had a few unexplained phenomena - to which I will return when I have the answer....), but it is not the point I raised.
To my understanding, MuseScore is a Music composition and notation software. Thus it can be expected that in all its capabilities only uses (as an analogy) paper, pen, scissors, and glue. The sounds (produced by MIDI) are only thrown in as a bonus from up-to-date technology.
Let's say, I come to have a MIDI file of a symphony: MuseScore converts it into a multi-staff score without indication, which line is what instrument. I can quickly define the names of the instruments staff by staff - in the Staff Properties dialog - which is excellent as it is. I only raised, whether it would be possible to associate the midi program with the satff I am actually editing. That would be followable for a musician.
It is, indeed, possible to to set instruments in the mixer - but it is impractical for the purpose outlined. A musician trying to produce written music is lost in the small window crammed with potmeters, He is unsure, whether he sees the Eb Clarinet line or the 2nd Bb line. The mixer is for 'sound engineers' who are not concerned, whether the three oboes play chords or a three-part counterpoint (that is why I never expected Cakewalk to notate music properly).
I hope it is clearer now what I wanted to raise.
Actually, changing an instrument is often as simple as unpacking the *.mscz, opening the resulting *.mscx file in a text editor and replacing the value for trackName¹. It would be still very nice to have a GUI option in MuseScore for this task. Sort of must-have for editing orchestra scores.
¹) This won't change the playback instrument, but the latter is not the main concern in this RFE, if I got the point.
In reply to Assigning a different instrument to an existing staff by Ilja Sekler
Ilja, you got it absolutely right! The problem is that I don't know, how to unpack and edit an *.mscz file, You can change the name of an instrument easily, but it is not associated with a MIDI program number. I only assumed that if in MuseScore you can change the replay mode at any point of a staff full of music (for instance from arco to pizzicato) there is no reason why you could not change it at the beginning from piano to French horn.
In reply to Ilja, you got it absolutely by drikanb
I'm not following I guess.
1) To change the name of a staff, right click on the staff -> Staff Properties -> Edit long and short name. This text should appear at the beginning of the staff.
2)To change the playback instrument for a staff, go to the mixer.
Of course, if the midi file do content the name (1) and the midi program (2) it should be imported.
In reply to I'm not following I guess. 1) by [DELETED] 5
The name of a staff gets modified, but this RFE is about a semantically correct replacement of an instrument assigned to a staff with another instrument. (1) doesn't do this.
In reply to I'm not following I guess. 1) by [DELETED] 5
lasconic, your guess is right. It may be that my wording is convoluted or that you did not read my comment. Otherwise you would not advise me in your points 1) and 2). (as my comment went into much deeper details of the concept of those very points one by one).
I only suggested a slight change that would combine two features that are already present in the software into its logical notation editing place: into staff property. I beleive, that would enhance the user-friendlieness for people seeking software that uses its facilities consistently within the terms of the original purpose of the software (namely notation that emulates paper, pen, scissors and glue).
I beleive, a point of request may be worth thinking over, perhaps even be answered in its own terms, not brushed aside, that it can already be done, albeit based on fundamentally different concepts.
In reply to lasconic, your guess is by drikanb
I only suggested a slight change that would combine two features that are already present in the software into its logical notation editing place: into staff property.
Please allow me to disagree. The basic feature to replace one logical instrument with another for an already existing staff is not available in MuseScore yet, at least not in the GUI. So there is nothing to combine yet and the coding effort may be quite significant.
If you don't bother which logical instrument is assigned to a staff and speak only about "cosmetics" like playback instrument and the displayed instrument name, I have definitely misunderstood you and messed up your RFE, sorry for that.
In reply to Lacking feature by Ilja Sekler
Ilja, the features are both already available in MuseScore:
The instrument names can already be set (in staff properties) to anything - even to fictive names. A very commandable feature! It allows the use of exotic instruments (only relevant in live performance) - the sound of which can, if at all, only be approximated by one of the preset 128 MIDI sounds.
The other existing feature of MuseScore is the possibility to change a string instrument from arco to pizzicato - or a trumpet from senza sord to con sord, at any point of their existing staff. The mechanism there, as far as I understand is, during playback, at the given particular point a channel/program number change message is sent to the MIDI player. Since the sent channel and program numbers are arbitrary - there is no reason why this facility could only be applied to certain instruments. The GUI program module dealing with sending this MIDI message should be available for calling from other interfaces, eg. from "staff properties" too.
You did, definitely, understood my point - it's not a matter of cosmetics, it is an issue of fundamental functional concept. Before I opened the topic, I had imported an earlier score from a MIDI file, and tested under both Windows and Linux. Using the Mixer, I spent nearly an hour on identifying the instrument's line with the channel - I had to start and count every single line from the top and/or the bottom several times before setting. Even so, I mis-set a few lines, the only way I could check the setting was that I had to replay it and identify by ear whether instead of plucked violin a trumpet played. The file was a score for a chamber orchestra, the traditional 5 strings, 3 brass 2 woodwind and xylophone. And within the short piece I had to change the strings from pizz to arco and back several times - which I could do this easily within the appropriate staff using an available GUI facility of MuseScore. And, the fact, that I could do this latter quite easily, prompted this RFE.
In reply to Ilja, the features are both by drikanb
The instrument names can already be set (in staff properties) to anything - even to fictive names.
This changes only the displayed names, not the logical assignment of instruments to a staff. You can easily verify this by Create => Instruments => Oboe (e.g.), changing 'Oboe' in the staff properties to 'Violin' and then revisiting the 'Create Instruments' dialog again. It still shows 'Oboe'. To change this to 'Violin' you have to edit the *.mscx file directly.
Moving the assignment of MIDI instruments to logical instruments from Mixer (which doesn't assign MIDI instruments to displayed instrument names, only to logical instruments) to the staff properties dialog would be another useful enhancement.
In reply to Logical instrument name != displayed instrument name by Ilja Sekler
Closing of the circle
Of course, the logical (or displayed) name fulfills the exact purpose of a notation program. The software is designed to produce (e.g extraxt and print) the appropriate part for the musician who plays the instrument that is known as the logical or displayed name. MIDI does not come into this process at all, whether exists or not.
Moving the assignment of MIDI instruments to logical instruments from Mixer (which doesn't assign MIDI instruments to displayed instrument names, only to logical instruments) to the staff properties dialog would be another useful enhancement
Just as if it were a quote from my initial RFE....
Although I want to make clear, I suggested the MIDI assignment as another new device, independent from the existing naming device but in the same 'staff properties' dialog panel. Thus I could call a line "oboe" and assign a clarinet sound in MIDI. (As Mozart's Symphony in g minor is often performed).
Perhaps, I would use a MIDI combo-box-type device rather than the tedious rolldown used in the Mixer. It can be expected from a user, that he/she is able to type the first few letters of the desired instrument. And, since the device sending MIDI message assopciated with a channel (staff) is already available....
In reply to Ilja, you got it absolutely by drikanb
These files are just ZIP archives, every archiver which can handle ZIP archives can unpack *.mscz files. To edit the *.mscx file in the archive, use a text editor which preserves unix style line endings and UTF-8 encoding. Open the modified *.mscx file from the uncompressed archive with MuseScore and save the score as *.mscz again. Don't use modern zip utilities to repack *.mscz: the unpack code in MuseScore (OSDaB ZIP) doesn't accept archives with version higher than 2.7.
In reply to Unpacking *.mscz files by Ilja Sekler
Ilja, thanks for the advice - I didn't think the .mscz files can be read (thus edited). I shall definitely have a look at it (in the past, I failed to 'crack' Sibelius and Finale files).
Your idea of editing the .mscz files, of course, opens new avenues, only the sky is the limit: I could change notes, write a text-base application that could send note-sequences, formatting information into the appropriate segments of the .mscz file. Who knows, one day I could even write a GUI front-end....
But, why on Earth, should I? MuseScore already exists - to my belief, exactly in order to save me all the above editing tasks!
In reply to Ilja, thanks for the advice - by drikanb
But, why on Earth, should I? MuseScore already exists - to my belief, exactly in order to save me all the above editing tasks!
MuseScore is already a fantastic application, but since there is no way to accomplish this task with MuseScore yet, you have for now the choice to do this by editing *.mscx files directly or not to do this at all, unfortunately.
In reply to No way to do this with MuseScore yet by Ilja Sekler
Or add the feature yourself ! The code is available and you can find how to compile MuseScore on your platfform in the developer handbook
Patches are very welcome!
In reply to Add the feature! by [DELETED] 5
add the feature yourself ! [...] Patches are very welcome!
Needless to say, if I could code, I would have filed a bug with a patch attached instead of bothering with feature requests. As tester I can only try to make the task as clear and attractive for active developers as possible.
In reply to Contributions to MuseScore project by Ilja Sekler
Sure, thanks. I was talking to drikanb
In reply to ok by [DELETED] 5
lasconic, you expect too much from me, my expertise lays with music - and I only have some amateur programming experience.
However, I am prepared to look into the coding too, because I'd find it a challenge. Having followed the developers pages, I haven't found (in terms that I understand) how I am expected to proceed. Or, what help can I expect from the other developers in learning the code and the testing process (obviously, I don't expect a complete Qt tutorial from you, but some examples on how certain sections of the code work, how a change made to it could be tested, or, how can I ensure that my bit would not collide with others' coding in progress)?
Without an answer to these questions, I'm afraid, I have to conclude that I only have a right to suggest features that might enhance the software from the aspect of a musician user if I am an accomplished programmer. And I think, MuseScore was conceived with the intention of serving musicians.
In reply to lasconic, you expect too much by drikanb
Below are a few tips that I've found helpful:
If you see a bug fix that you are particularly interested in look of the revision number referenced in the bug report. You can look at all the files that were changed by going to the following URL (replace the last four digits with the revision number you are interested in)
http://mscore.svn.sourceforge.net/viewvc/mscore?view=rev&revision=2732
I like to think of the revision changes as hundreds of mini tutorials guiding you through the code base.
Another trick I've found particularly helpful is to search the text of the code base for particular key words. I often use grepWin to search the files because I found the Windows XP built-in search too slow, and often inaccurate.
To test your code start with small changes first (nothing more than a line or two) and compile using the instructions provided in the developer's handbook .
To avoid problems with your code colliding with others in process use SVN. I used the GUI version of SVN to begin with (TortoiseSVN) and still needed to read the manual. However once I understood the basic concepts it was very useful.
In reply to Below are a few tips that by David Bolton
Thank you for your comment.
Premise: I raised a simple RFE, regarding the enhancement of staff properties with the additional incorporation of another existing device.
Up to now only one comment (Ilja's) agreed with the desirability of such enhancement. Neither of the others reflected on the desirabilty or non-desirability of the requested feature, Having run out of (non-)arguments, I was advised (assuming that it was so important for me) that I should code the facility.
Argument: Since I was very interested in the enhancement of MuseScore and mildly interested in the challenge of writing the assumedly simple code, I asked back, where and what help I could expect from the developers. I assume, your comment intended to respond with giving me a kick-start.
Regarding the first paragraph, it is clear that it has nothing to do with my RFE.
Regarding the second paragraph, you assume I have the time and a sustained interest for reading through hundreds of mini tutorials. Only in the hope that some of those (if I'm lucky) may have indirect reference to incorporating devices and calling associated routines in a dialog.
Regarding your third and fourth paragraphs, you give me further homework, again, assuming my insatiable hunger for further information.
Regarding your last paragraph, I'm afraid, I'm a little beyond the fascination of compiling the "Hm...then... good bye world!" stage. Especially considering the roughly one-hour compilation time referred to in the developers handbook. (I did some hand-disassembling in the past, hence I know exactly what would be involved in following through the program flow of MuseScore).
Conclusion:What makes you think, I have not lost motivation as a result?
In reply to Thank you for your by drikanb
Especially considering the roughly one-hour compilation time referred to in the developers handbook.
The most time is spent building static QtScript bindings. On Linux, you can install libqtscript4-core, libqtscript4-gui, libqtscript4-network, libqtscript4-uitools and libqtscript4-xml from repositories and scratch "scriptgen" from the subdirs array presently at line 219 of mscore/CMakeLists.txt. This reduces the compilation time to less than 10 minutes on a dualcore machine with "make -j2" (which is done automatically in the Makefile if you don't build the officially debianised source).
I have no idea, why MuseScore official debian packages are built with static QtScript bindings. It would be great to know the reason.
In reply to Compilation time by Ilja Sekler
Thanks, Ilja but the second paragraph is in Chinese for me. Obviously, if I had the motivation, I could get through it all.
But I don't (If I remember right, it was you a few comments back, who explained why you wouldn't undertake coding).
In reply to Compilation time by Ilja Sekler
I have no idea, why MuseScore official debian packages are built with static QtScript bindings. It would be great to know the reason.
I think (but I don't use debian) that this is to prevent a MuseScore crash when someone was to upgrade QtScript to newer (but incompatible) version. Otherwise, every time a QtScript is upgraded, the MuseScore should be recompiled (but at that time it could be incompatible with newer version) , repackaged and reinstalled. So more work for the maintainer.
Just a guess.
Regards,
miko
In reply to Thank you for your by drikanb
Neither of the others reflected on the desirabilty or non-desirability of the requested feature, Having run out of (non-)arguments, I was advised (assuming that it was so important for me) that I should code the facility.
While I have no opinion on the subject (I am a MuseScore user for just a few days, still learing, noexperience), I think the plugin API would be ideal for this task. Programming in javascript is way easier and faster than in C/Qt, and no SDK is needed. The only question is if the plugin API allows all needed operations (finding the instrument names, changing MIDI channels etc.) - sorry, I have not checked it out. After all, the plugins are exactly for that: if there is no requested functionality, and no one else needs it, it should be relatively easy for me to make it by myself, if all the building blocks are available.
In reply to Write a plugin? by miko_
miko, the most important part of designing an application is to define the concepts. If there is a basic facility that sets up the properties of a staff, sticking to the concept of consistency, all the related features should come under it.
From a composer's point of view, I could even argue, whether the best avenue is to set up your score line-by line in "create instruments". I would rather use "create ensemble" that could be edited later by adding or deleting lines (and change the added staff's property - both in terms of displayed name and MIDI program name/number). Using an analogy, assume, I want to compose a piano sextet. First I would go to a stationery shop where there is no preprinted sheet with my six instruments. But they have manuscript paper preprinted with the template of a piano quintet (piano+string quartet).I could buy it and use it by adding the sixth line (for the clarinet or Double Bass, or whatever) by hand.
Plugins are pre-set shortcuts that combine several editing steps - in order to save time and effort for the user that would be required for repetitive tasks. The task being the object of the topic could, indeed, be solved by a plugin, by first selecting a staff, the calling the plugin that would take the selected staff as one of its parameters and change a property of it. But it would be a tedious 'long-cut' calling all the elements that could be called more efficiently as a relevant menu item. (In fact, I raised another question namely the facility of 'macro's - in line with my views on strict distinction of functions within an application. A macro - as opposed to a plugin, is a temporary customised recording of a particular sequence of instructions for use on the spot.)
But, fortunately, according to lasconic's comment, the feature is already implemented. I am definitely looking forward to seeing it in the next buid.
In reply to miko, the most important part by drikanb
miko, the most important part of designing an application is to define the concepts. If there is a basic facility that sets up the properties of a staff, sticking to the concept of consistency, all the related features should come under it.
I totally agree. MuseScore is an opensource project, and is released as a beta software, so this is why there is some functionality/concepts lacking. On the other hand, you can use it today ("release often") instead of waiting next few years for a stable, full-featured product. The authors have some use cases and concepts in their heads, but obviously not all of them. So it is good that you are bringing up some issues, that way we all can look at the problem from the other point of view.
But then again, plugins would help in any "short term" solution - you could have it in days or weeks, instead of waiting for developers (possibly a few years) to implement it in the core. And this is where MuseScore differs from other commerials products.
The ideal situation, of course, would be if all the concepts/use cases were implemented in the core (which takes lots of time, thinking and discussions). So lets enjoy what we can use today, and hope for even better possibilities tomorrow.
Regards,
miko
In reply to Thank you for your by drikanb
"Regarding the first paragraph, it is clear that it has nothing to do with my RFE."
I was speaking in a broad sense about ways that I've found helpful as an amateur coder. If you are not interested or don't find it helpful then by all means ignore the suggestion.
"Regarding the second paragraph, you assume I have the time and a sustained interest for reading through hundreds of mini tutorials. Only in the hope that some of those (if I'm lucky) may have indirect reference to incorporating devices and calling associated routines in a dialog."
Just because there are hundreds (actually thousands) of revisions doesn't mean you should read through them. I specifically said, if you come across a bug fix that interested you.
"Regarding your third and fourth paragraphs, you give me further homework, again, assuming my insatiable hunger for further information."
It was information that I have found valuable when working on MuseScore. Most of my code contributions (and many bug fixes) affect no more than a line or two. These are not meaningless homework assignments they really improve MuseScore. Regarding your interest, I only assumed you were interested because in an earlier post you asked about help from "other developers in learning the code and the testing process". If you're not interested then don't ask.
"Especially considering the roughly one-hour compilation time referred to in the developers handbook."
FYI: The first compilation takes between one to three hours depending on the speed of your computer. If you don't delete all the build files subsequent builds take about 10-20 minutes.
In reply to "Regarding the first by David Bolton
David, I was asking for specific advice, not something in a broad sense
My RFE (you see, I can learn quickly, and can use expressions unintelligible for the non-initiated) was to add an existing device into an existing dialog box. I can hardly expect that there was such a bug in the past, that resulted in the unintentional appearance/disappearance of a particular device in a dialog. However helpful it could be, the likelyhood of finding a fix to such a bug is ....
As far as I know - Werner has already included the midi staff assignment facility in the staff property box - thus the request could not require such a huge coding effort (even assuming that Werner is extremely familiar with the program).
I don't understand your last paragraph (even ignoring that I haven't got the foggiest, what FYI stands for) - what 'build files should I not delete', when and from where, and what would make me otherwise beleive that I'd need to delete those.
I know the answer: I should look into...
In reply to David, I was asking for by drikanb
For Your Information.
In reply to "Regarding the first by David Bolton
FYI: The first compilation takes between one to three hours depending on the speed of your computer. If you don't delete all the build files subsequent builds take about 10-20 minutes.
Looking into the top-level Makefile let me think that deleting the build directory were mandatory. Good to know that it is not. I've attached a new private patch to http://musescore.org/node/4427.
(OT: The design of this forum is highly unusable for long threads, unfortunately, because it doesn't display references clearly.)
In reply to Below are a few tips that by David Bolton
For navigating around the code on windows, I use two tools.
PsPad : You can search/grep into a directory and display the files in the same tool. C++ coloration column selection etc...
QtCreator : It comes along with Qt SDK on Windows. The compilation instruction on Windows explains how to set it up. Search throught the code is included and if you Ctrl + Click on a function, it sends you to the declaration or implementation.
@drikanb: Regarding the subject of this thread, Werner has implemented something in the staff properties box to change the instrument.
In reply to For navigating around the by [DELETED] 5
lasconic, I am glad, if the change of instrument is a MIDI assignment, as it would also allow such mid-staff facilities as, for instance, changing the 3rd flute to piccolo ...
If this is the case, The issue of the RFE was worth raising. Just as a matter of interest, how come that 'Werner has implemented something in the staff properties box to change the instrument ', and how is it consistent with all the comments above?
In reply to lasconic, I am glad, if the by drikanb
how is it consistent with all the comments above?
drikanb, with revision 2726 you got 100% what you asked for in the original RFE. My objection was not taken into consideration.
The implementation is not perfect (the text style for "Long Instrument Name" and "Short Instrument Name" respects neither the default style for these elements nor the previous hard formatting), but this is of course a big step forward anyway. Thanks a lot!
if the change of instrument is a MIDI assignment, as it would also allow such mid-staff facilities as, for instance, changing the 3rd flute to piccolo ...
No, this wasn't implemented.
I still insist, that changing a MIDI instrument and leaving the logical instrument stored as trackName in the XML unchanged is wrong. You will realize this when generating parts from a score at the latest ;-)
In reply to Select MIDI instrument in staff properties by Ilja Sekler
Ilja, I'm glad that we agree on a lot. Regarding paragraph 5 (second from the bottom) however , I beg to disagree. Although it is not a feature of setting the whole staff in staff properties, the mechanism for mid-staff change of an instrument is there ('Create-Text-Staff Text') - it should only be extended. After all, the sending of a mid-staff change MIDI message from 'viola' to 'pizzicato ensemble' does not differ from the sending of a mid-staff change from 'flute' to 'piccolo'.
Regarding your last paragraph, I don't understand your far too technical wording (I do not know what you mean by logical name in this context as opposed to what kind of name, where is the XML file that stores the track names - that may be logical but may be other...).
I still maintain that the displayed name is a matter of notation (enabling a real or virtual copyist to extract the instrumental part and print the 'displayed' instrument name on part's title page that, in turn, would allow a real or virtual instrumentalist to read and play the part on his instrument - bearing the 'displayed name'. And I also maintain, that the MIDI 'track' or 'instrument' or 'program' name/number should not necessarily be bound to the displayed name, only to the appropriate staff. If this is what you insist on, we are in complete agreement.
In reply to Ilja, I'm glad that we agree by drikanb
I do not know what you mean by logical name in this context
I already tried to explain this in http://musescore.org/node/4569#comment-11992. When you add instruments to a score ('Create' => 'Instruments') and choose an instrument (e.g. 'Oboe'), you give the staff his logical name - the music in this staff is meant to be the oboe part. The staff gets automatically "Oboe" as 'Long Instrument Name' (this is the displayed name) and the MIDI instrument 'Oboe' assigned.
But when you decide later to give this staff e.g. to a violin, you can change the displayed name and the MIDI instrument - but you have no way, absolutely no way to change the once chosen logical name in MuseScore. When you try to generate parts, MuseScore will always call this staff "Oboe", even if is labeled "Violin" and sounds like a violin.
I think that meaning should determine the appearance, not other way around. So said, the new enhanced staff properties dialog should first change the meaning of the staff (set a new logical name). The secondary attributes like displayed instrument name and the MIDI instrument should automatically follow.
For seldom cases when you want to play with timbres without assigning the staff to another instrument, the Mixer GUI does already a pretty good job.
I still maintain that the displayed name is a matter of notation
When the score leaves a computer and becomes ink on paper, I agree. But as bits and bytes, a strict structuring of all elements should be the rule.
And I also maintain, that the MIDI 'track' or 'instrument' or 'program' name/number should not necessarily be bound to the displayed name, only to the appropriate staff.
They are in fact independent, but if I decide to give a part from oboe to violin, I expect the staff to be renamed to violin too, not just the displayed instrument name.
In reply to Appearance vs. Structure by Ilja Sekler
Ilja, I hope you don't mind that we are going into the field of philosophy - but clarifying such issues will hopefully lead to a better understanding of each other, and perhaps, even to some solution for preventing any misunderstanding in the future.
You very clearly laid down that there were three 'labels' (Up to your last comment I was only aware of two). It is new to me, that the 'logical' name, the initial one (the one you give the staff at the time of creation) is a 'global constant' the value of which is an instrument name. (The second one, the displayed - instrument - name is a local variable. And the third, the actual MIDI program name is also an - instrument-like named - local variable).
I think you shed light on the root of the confusion - namely the use of the same terminology to express three different 'concepts'.
I think, we both accept the logic that a notation program should display the classic instrument names ('When the score leaves a computer and becomes ink on paper, I agree').
In the case of sound the MIDI track-, channel- and program numbers are not necessarily bound to actual staff (lines of the score); for instance, 'pizzicato ensemble' could cover the entire string section. Therefore, I would, for the sake of argument, refer to the MIDI staff-assignment as 'numeric local variables' associated with a set of mnemonics that are similar to instrument names.
I now understand what you meant by 'if I decide to give a part from oboe to violin, I expect the staff to be renamed to violin too, not just the displayed instrument name'. In computer logic, distinguishing global and local names can be very confusing sometimes, especially, when the variable and constant names use the same sets of expressions (eg. instrument names). The easiest way to prevent this confusion that the initial logical name should be 'something completely different' from instrument names (either the boring staff a, b, c, d or, something more imaginative) - after all, they are only mnemonics!.
Let me give you an example on using mnemonics with a clear purpose (of preventing confusion). The 3 patitions of my present hard drive are called Wanda, Linda and Sharon. (No prize is given, but which one do you think is the Linux partition?). Sometimes I put in my old archives (with 4 partitions: D'Artagnan, Athos, Porthos, Aramis) to the rack. I am never confused by the drive letters, no matter how hard Windows tries to rename them.
In reply to Ilja, I hope you don't mind by drikanb
Ilja, since I understood the nature and the depth of your concern (even your 'objection having been ignored'), I searched the structure a bit further. I created 2 files:
a) imported a midi file (and saved it as a.mscz);
b) imported another midi file, named the instruments in staff property - some of them deliberately with phantasy names for identification purposes (and saved it as b.mscz);
Having followed your advice I unzipped the two files and compared the bits of them I thought were relevant to the 'logical name'. There were 2 differences I could notice:
In 'b.mscz' there was an extra section between'< /Staff> and Instrument>': from'< name to /name>'. That section listed the 'display names (including the phantasy-names)
In both a.mscz and b. mscz there was a 'program value=nn' with the appropriate MIDI program value - but with no literal 'logical name'. Although I don't know, what actually happens in mid-staff program value change (c.sord, or pizz.) - I assume this initial MIDI assignment cannot be a global constant.
Therefore, I beleive your worries are unfounded, I could not find anything that would indicate a 'logical name' constant.
(In fac - but I might be wrong - the only property that may substitute a staff identification constant is the order of the 'parts' as they are listed - and appear in the score, from top to bottom).
But, looking at the bright side, I have another idea - that, hopefully will stir up some thoughts again.
In reply to Ilja, since I understood the by drikanb
In MuseScore if you change the instrumentLong name ("display name") and then go to Create > Instruments you see that the instrument name there is not changed ("logical name").
FYI: If you want to look at the contents of a score using a text editor you can skip the unzip step by saving as Uncompressed MuseScore File (.mscx).
In reply to In MuseScore if you change by David Bolton
David, it may be the case - regarding Create instruments dialog box. But if you look at the mscx (thanks for the advice), the story is different.
In the above comment to Ilja, I described my experiments with two files; neither files had instruments set up in 'Create Instrument' and I added instrument names (in 'staff properties') in the second ('b.mscz)';
in both 'a...' and 'b...', the only indication for the actual MIDI program was the 'program value=...';
in 'b...' there was an extra section ' that included the 'displayed name' added in 'staff properties'.
in response to your comment, I made a 3rd experiment: 'c.mscx' with an extra instrument set up (in 'create instruments') and an instrument name change in 'staff properties'. There, indeed, was a constant 'track name' that was what you referred to as the 'logical name' - and a separate blocks for the properties of the displayed name and actual MIDI association..
However, we know, that in MIDI, you can call the track anything you like. You can see from my comment to Ilja, that using the same set of expressions (instrument names) for track name (global constant) as for the 'printing local variable' and, even for the 'sound local variable' is an unfortunate similarity causing confusion, it seems, even amongst experts. An easy solution would be to dispense with the 'track name' altogether - as the program seems functioning without it, or setting up a different set of mnemonics in order to prevent the confusion caused by conflicting labelling names.
In reply to Ilja, since I understood the by drikanb
Therefore, I beleive your worries are unfounded, I could not find anything that would indicate a 'logical name' constant.
In my first reply in this thread - http://musescore.org/node/4569#comment-11947 - I already mentioned where the "logical name" is saved. But I've just found that it may be completely omitted. The handling of trackName is broken in r2737 anyway:
1) create a score, add a couple of instruments
2) save and close the score
3) reopen the score
Actual results: these "logical names" / trackNames are not displayed in the 'add instruments' dialog anymore. The error in the terminal:
the only property that may substitute a staff identification constant is the order of the 'parts' as they are listed - and appear in the score, from top to bottom
I assume that it works exactly in this way at the present.
I'll file a couple of bugs for the handling of trackName and the new 'Change Instrument' feature soon.
In reply to "logical name" is trackName by Ilja Sekler
Ilja, We are getting there!
As I already wrote it to David (the comment above), I did a third experiment; namely set an extra instrument to 'Low Bb Horn' in 'Create-Instruments - to the previous file. I changed it to 'Oboe' in staff properties and I also changed the instrument to piccolo in the Mixer. The results were predictable: Track name=Low Horn; the variable '(part)name=...."Oboe'; 'program value=72'
Closing and reopening the file resulted in exactly as you described: the 'Low...Horn" was listed in 'Create...' and the display and replay were the same as before.
Then I created 'd.mscx' by editing 'c.mscx'.- I changed track name = "Low Horn" to "Medium rare"; I saved it and opened it in MuseScore. The Create Instrument showed track name="Medium rare" - (the other two variables were obviously unchanged). Then I played it back and not only did the score displayed "Oboe" correctly, but the MIDI was playing 'piccolo' correctly too (well, I had to make it jump up three octaves to be better audible).
All this means that originally,
1. there is no need to Create actual instrument (though the facility may be used) - only empty staves at the outset.
2. When the instrument receives a name (from staff preperties) this name can be copied to "track name=....."
3. After that, the MIDI assignment can be changed at any point (including the start) to any "program value=...."
In this way, your concern may also be solved - as at least two of the three parameters are consistently identical.