Post Edited (Jari Williamsson) : 3/5/2012 1:45:25 PM (GMT-6)

1. Select all of the music with the selection tool.
2. open JWChange/Rests/Beaming and select "Break Beam After Entry" as the beaming mode. (I'm not even sure what this is supposed to do. I think it's meant to break the beam on an entry [note or rest] that appears after a rest [since we're in the Rests container]...? Can you clarify?).
3. Click Apply and see that the beam in m.3 has extended itself rather than being broken in any way. (Same thing happens with "Break Beam Before Entry" as the beaming mode.)

1. Select all of the music with the selection tool.
2. open JWChange/Rests/Beaming and select "Beam to Previous" as the beaming mode. (I think this is suppose to beam any 1/8 or shorter rests to any 1/8 or shorter note that preceeds it).
3. Click Apply and see that the beams in m.1 and m.3 have been broken!

When Display half-stem for beamed rests is check in Doc Opts. the only way to hide a select group of these half stems is to assign a blank custom stem to them (at least that's the only way I can think of right now). Do you think it would be worth it to add a function for this under Stems or Rests (e.g., "Visibility [half-stems]"). Currently, the "Stems Visibility" command doesn't work on half-stem rests.

Ken
I don't think I'd have much use for this but I'm just playing around with the plugin now and some else may find half-stems on some rest more readable in some cases but not in others - in which case this plugin with its filters may be very helpful.

I'm getting some surprising behaviour with Rests/Beaming where Beam to Previous breaks some beams and Break Beam After Entry actually extends some beams. Is there some functionality that hasn't been hooked up yet that I should know about or would you like me to send specifics now?

Ken
My Doc Opts are Extend Beam Over Rests and Extend Secondary Beam Over Rests are both checked.

I don't know how easy it is to add fonts to the font lists in the plugin (e.g., noteheads/fonts, articulations/fonts, etc.) but here are a few that I've found useful over the years.

MetTimes, MetHelvetica (not show but by the same vendor), Metronome, DVMarticulations, Kidnotes

CrescendoFLF, GraceNotesFLF

Ken
PS Why are MaestroWide, EngraverFontExtr, Maestro Percussion in the lists?

1. I have a measure with an upstem 1/8  note and a downstem 1/8 note.
2. The 1st note has a staccato under it and the 2nd has an accent over it.
3. I run Articulations/Horizontal Position with "50" input in the box. Everything moves to the right as expected.
4. I run Articulations/Vertical Position with "50" input in the box. The staccato moves down and the accent moves up. I suppose this makes sense as the number increases the distance the articulation is away from the notehead (of course a large negative number would do the same in the opposite direction). However, you may want to clarify the movement in this command's description. Someone could easily think that inputting "50" should move everything in one direction - up 50EVPUs - and -50 would move everything down.
5. I run Articulations/Clear Position. The articulations don't go back to their "original" positions - the positions they were in before I moved them with the other commands. It appears that this command is equivalent to setting the vertical and horizontal positions to "0" which is, apparently, different from their defaults. This is not intuitive and it looks like a bug. To get them back to their default position I have to select the articulations and hit the BACKSPACE key. I would expect the "Clear Position" command to be equivalent to hitting the BACKSPACE key (i.e., removing manual or plugin enacted positioning). "Clear Position" certainly doesn't "Reset manual positioning of the articulation" as its description says - it actual "sets" it to 0. (The "re" implies a return to a previous setting.)

Ken

1. A user opening the Change plugin is looking to do something specific. If they want to move rests up/down they could think of a number of titles to look for including "Placement, Vertical Placement, Position, Vertical Position, Move Vertically, Move Up/Down, Transpose, etc." Of course we've already been through this.  However, if they see "Horizontal Position" under this element or other elements I believe it is nature for a user to then look for "Vertical Position" if he wants to move something...well...vertically. As a user, it would never occur to me that the name would be something else simply because it uses a different unit of measurement!  In fact, I wouldn't even remember that vertical rest movement only uses one unit of measurement until after I stumbled on the right title - but by then I've already looked for the logical counterpart to Horizontal Position (Vertical Position), not found it and poked my way through "Placement Style" and "Placement" reading the description of each just to see if I'm using the right thing. Units of measurement is something a user deals with/thinks about when they're about to input the numbers, not when they're trying to trying to find the right command. Your naming convention presupposes an understanding that I don't think users will have.
2. Vertical Position tells the user with more specificity what the function does, especially since Placement Style is already in use and a user can easily get confused with Placement vs Placement Style (Yes, users should investigate all commands they see and RTFM but my point is that the more intuitive title from the user's perspective is usually the best.). What is more important to the user's ability to find what they need when they open the plugin? - a title that distinguishes the actual function of one command from another or a title that simply distinguishs what unit of measurement a command's unclarified function may or may not use?
3. Why wait until MM adds vertical EVPU adjustment of rests to use the most natural title? When/if MM does that will you then change the title of the command - which will further confuse people who have gotten used to the old name. If MM ever does add that functionality perhaps you could allow users to change the unit of measurement from within the command's options (ratios or dropdown box) rather than having two separate places (e.g., Rests/Placement for spaces, Rests/Vertical Position for EVPUs) and rather than confusing people by renaming Placement. In fact, you may not even need to add anything. Currently, parts of your plugin allow users to switch units of measurement on the fly by typing the letter after the number they input (e.g., With Noteheads/Vertical Position typing 2e will move the notehead up 2 EVPUs, 2i will move it up 2 inches, 2s will move it up 2 spaces, etc.). Why not setup Rests with "Vertical Position" now so that if MM adds that functionality there wouldn't need to be an interface change that the user has to deal with? The fact that a user would go into Rest/Vertical Position now and would only be able to move them by spaces won't bother a user (at least the name wouldn't) - we've been adjusting the vertical position of rests using spaces for a long time and only expect movement by spaces.

Ken

Post Edited (Jari Williamsson) : 2/11/2012 4:31:55 AM (GMT-6)

Is there a logic to the order the main elements are listed (i.e., Notes, Noteheads, Rests, Stems, etc.). Most popular elements to be edited first maybe?
With 11 elements already list and hopefully more to come (Ties, Clefs, Chords, Textboxes, Lyrics ) it would be helpful simply to do aphabetical order - like the document options DBX. (Although the dropdowns in the Doc/Opt DBX is still a mess - Doc/Opt/Fonts/Noteheads, in particular).

Ken
BTW Why aren't Ties included in this plugin?