Skip to main content ↑ ↓
Topic: NoteWorthy Composer 2.1 Beta 16 (Read 256505 times) previous topic - next topic

Re: NoteWorthy Composer 2.1 Beta 9

Reply #50 –
Quote from: NoteWorthy Online –
I'll look into that and the ACCESS_VIOLTION.
I defined a Backup folder and the problem went away. I then removed the definition and the problem reappeared. I also lost the ability to redefine a Backup folder. Then I reinstalled and got the ability back.

Simple fix would be to disable File->Open Backups... until a backup folder was defined, but if the user decided to keep the old backup system it would be nice if File->Open Backups... worked like  File->Open, but defaulted to *.bak
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 9

Reply #51 –
Yes, I understand it - I just don't like it - and think it is likely to be confusing.

I would rather have the latest as a completely different name convention and then the others as numerical in order.

So the latest is always - say - Filename.rec.bak  (rec for recent) and then the older versions 1 through what ever number defined.
So as soon as a file gets saved, rec.bak goes to last numberused+1 and this then would keep the numbers in order until an overwrite is needed. The latest copy is always plain to see and understand and the numerics wouldn't be confused in time.

Rich.

Re: NoteWorthy Composer 2.1 Beta 9

Reply #52 –
Have had the same problems that others have reported. I got the access violation warning repeatedly on trying to open backups until I assigned a backup folder in the options dialog; then everything worked fine (except, of course, that it still says beta 8 in the title bar).

I agree with Rich's and Lawrie's comments re numbering. I think it would be better if (a) the numbering was consistent, whether or not the number of backups was assigned, and if (b) the numbers remained in chronological order. Since keeping the numbers in chronological order with the current backup being no. 1 would require renaming every backup file at each save, why not allow the most recent backup to have the highest number? I don't think that would confuse anyone. I would also propose that, if the number of backups has not yet been assigned, the backup carry the designation file#.0.nwc.bak. That way it won't have to be renumbered if the user later decides to go to multiple backups.

But I like the multiple backups idea very much. Among other things, it allows me to open two identical copies of the same file, something that has taken a bit of maneuvering before. Now all I have to do is save and then open the latest backup.

Cheers,

Bill

Re: NoteWorthy Composer 2.1 Beta 9

Reply #53 –
Quote from: Rick G. –
if the user decided to keep the old backup system it would be nice if File->Open Backups... worked like  File->Open, but defaulted to *.bak

That is exactly what it does (or in this case, should do). Still looking.

Re: NoteWorthy Composer 2.1 Beta 9

Reply #54 –
Quote from: Richard Woodroffe –
So the latest is always - say - Filename.rec.bak  (rec for recent) and then the older versions 1 through what ever number defined.
So as soon as a file gets saved, rec.bak goes to last numberused+1 and this then would keep the numbers in order until an overwrite is needed. The latest copy is always plain to see and understand and the numerics wouldn't be confused in time.

The problem is that the Filename.rec.bak would appear below the other backup files in a default, name based sort order.

Re: NoteWorthy Composer 2.1 Beta 9

Reply #55 –
But the problem at the moment is that sequential numbers are not time sequenced. and this could be confusing. It has to be far better to differentiate between the most recent file and any other files.

I'm sure there must be a way that a default recent name can be thought of such that it will allow a single most recent file to come first in a list whilst allowing a series of other files to come later. Even if it means filename.latest.bak followed by filename.old01.bak .... filename.oldnn.bak 
Rich.

Re: NoteWorthy Composer 2.1 Beta 9

Reply #56 –
As previously noted, I don't think there's a problem with having the latest backup at the bottom of the list instead of the top. Any user who did have a problem with that, of course, could always reverse the sort.

Anyway....forgot to mention in my previous post that I also agree that users should be able to create a backups folder from within the program. That's a problem that could give non-power-users a bit of a setback.

Bill

Re: NoteWorthy Composer 2.1 Beta 10

Reply #57 –
Beta 10 fixes the access violation and the title bar designation. It also changes the backup filename convention such that the single version backups still use the 1 designation in the backup name, such as Filename.1.nwc.bak.

The other thoughts regarding the naming convention and folder creation will be given additional consideration.

Re: NoteWorthy Composer 2.1 Beta 11

Reply #58 –
Quote from: NoteWorthy Online –
The other thoughts regarding the naming convention and folder creation will be given additional consideration.

Beta 11 adds support for creating a folder from Tools, Options, Folders.

Beta 11 also changes the approach used for creating backup files. As of beta 11, when backups are enabled, the most recent backup file will always be named Filename.nwc.bak. You can configure an additional older version queue from the new "Queue size..." option in Tools, Options, Files. When a queue is configured, additional older backups will be stored in a circular queue of the size that you specify. Each backup file in the circular queue will be named Filename.q#.nwc.bak, where # represents an available slot in the queue for this filename.

Re: NoteWorthy Composer 2.1 Beta 9

Reply #59 –
Quote from: Rick G. –
if the user decided to keep the old backup system it would be nice if File->Open Backups... worked like  File->Open, but defaulted to *.bak
It looks as though this was implemented in NWC2 2.1 Beta 11
As an added bonus, opening a backup file does not add it to History.
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 11

Reply #60 –
Works much better now.

I suggest a wording change in the backup failed warning box, however. I get this warning when my designated backup folder has been removed. It currently reads Unable to create a backup for this file. Unless there are other circumstances that trigger this warning, it would be more helpful to specify Backup folder <foldername> doesn't exist.

Bill

Re: NoteWorthy Composer 2.1 Beta 11

Reply #61 –
As an additional note, I think "Queue size for old versions" might be a bit misleading as it is currently set. I suspect users are going to assume that the "old version" queue includes the most recent backup, and that therefore, if they have turned automatic backups on at all, the queue size should be 1. The most elegant fix for this, I think, would be simply to make the lowest q# q2 instead of q1 - and then include the latest backup (which has no number) in the count. Additional possibilities are to always designate the latest backup as q0, or to change the wording to read "Queue size for additional backups" (which is still a bit misleading, but better than the current version).

Bill

Re: NoteWorthy Composer 2.1 Beta 11

Reply #62 –
Quote
Each backup file in the circular queue will be named Filename.q#.nwc.bak, where # represents an available slot in the queue for this filename

I haven't downloaded or tried the more recent beta updates, but the discussion re the new backup file naming system suggests a lot of potential confusion.

I wonder if the name could incorporate a time stamp , like so:

filename.20100106-2245-05.nwc.bak

That way the user can always identify the backup wanted and the order they were created.  I doubt if people are going to create a backup more than once a second. 

This presupposes it would be possible to have NWC read the computer's clock when the bak is created...



Re: NoteWorthy Composer 2.1 Beta 11

Reply #63 –
I think the backup functionality is much better now, and clearer.  A nice addition and a good protection against loosing precious work.

David - I'm sure it would be possible to have NWC read the computer clock at the time of the save BUT you automatically have a date and time file stamp with the folder field called "date modified". So all you have to do is to click on it and it will give you the files in date and time order.

Rich.

Re: NoteWorthy Composer 2.1 Beta 11

Reply #64 –
I really wish I had this functionality years ago.It is so good to have an automatic backup (ie version control). This had to be done manually before for those that wanted backup versions.

I have one further issue that has leapt to the fore.

If you have saved such that the latest backup is the default name and you have several other version preceeding that, if you open up a numbered backup file, it is fairly clear that it is just that. The window naming has filename.qn, the window menu dropdown has filename.qn.  This is good.

However, if you open the most recent backup when you alrady have open the file that it came from, then it is impossible by those methods to tell which file is which. Both your current file and the most recent backup file have the same names on the window and on the window dropdown menu.

Unless you happen to know the order you loaded the files or you happen to remember the change you made and can find it, then the only other way is to do a "file" "save as" without necessarily saving. This will then show you the folder that the music comes from and you will then know which is which.  So..  I would request an additional bit of functionality on the window and on the window dropdown menu, which will make it clear which is the recent backup file.
 
Rich.

Re: NoteWorthy Composer 2.1 Beta 11

Reply #65 –
Rich is right. It's important to be able to tell which file is which by looking at the title bar, and beta 11's title bar doesn't discriminate between the working file and the latest backup.

The filename.q0 convention I suggested in my last post would fix that. So would filename.latest. Filename.nwc will not work, because it's still too easy to confuse that with the name of the current working file....unless the .bak extension is also included in the title bar. Which is, of course, another possibility.

Bill

Re: NoteWorthy Composer 2.1 Beta 11

Reply #66 –
Quote from: William Ashworth –
The filename.q0 convention I suggested in my last post would fix that.
Might I suggest filename.q00 ?  It would sort better.
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 11

Reply #67 –
- - -

...  Not wanting to interrupt the current threads in any way ... I don't know where else to post this question.

- - -

Where in the forum should we discuss other 'wish list' items for NWC 2.1+?   When would it be appropriate to do so?

How about desired new items for NW Player?

- - -

I know the backup filenaming convention thread is important.  When it's resolved, will there be another place for other Beta topics, or is this forum the proper spot when the time is right?

Joe



Re: NoteWorthy Composer 2.1 Beta 11

Reply #68 –
You probably should post your wishes to the wishlist, http://www.noteworthysoftware.com/composer/support.htm, although only Eric will ever see those or decide which ones to action.  

If you want to begin a discussion of wishes specific to any topic, just start a new message in the forum, just start at the beginning of this forum https://forum.noteworthycomposer.com/ and give it a descriptive title.  If Eric wants to move it to a special part of the forum, he will let everyone know.

NWC 2.1 Beta 12 Now Available

Reply #69 –
Beta 12 is now available from the start of this topic. It includes:

  • A file changed indicator appears in the editor window's title bar and Window menu selector. When a file needs to be saved, it is marked with an asterisk after its name in the Window menu and in the title bar.
  • An origin indicator appears in the editor window's title bar and Window menu selector. It is shown for unsaved editor windows from imported or backup sources. Backup files are marked as "(bak)," MIDI files are marked as "(mid)," and imported NWC Text files are marked as "(nwctxt)."
  • The undo facility now recognizes when the editor matches the originally opened version of your work, and properly considers the work as unchanged.
  • Fixed the "Backup files during save" checkbox in Tools->Options, File (it was broken in Beta 11).
  • Subtle rewording for backup queue size in Tools->Options, File.
  • Removed the "Print Preview Copy" folder from Tools->Options, Folders. It now uses the same mechanism as standard File->Save As.

Re: NoteWorthy Composer 2.1 Beta 12

Reply #70 –
Thanks, Eric. I think this takes care of my remaining issues with the new backup system. And the rewording of the backup queue message in tools/options is a definite improvement.

Is there any chance that 2.1 will give us the ability to designate a bottom orchestral staff, so we can bracket the separate instrument choirs in orchestral scores? Just a wish....

Bill

Re: NoteWorthy Composer 2.1 Beta 12

Reply #71 –
Bug report:

I have two active staffs set to Orchestral.  The upper one has a few bars of rests.  The lower one has notes.  In the editor, the bar lines connect the two staffs but in Print Preview, there are no bar lines for several bars on the top staff.  The printed output (at least the PDF file) seems ok.

Windows XPPro, NOC 17" flat panel monitor.

Re: NoteWorthy Composer 2.1 Beta 12

Reply #72 –
David,

I think this is the same as Bills problem (and mine) reported by bill here .

Have a look and see if you think it is the same.

It would also be interesting to know if a muted headless whole note grace note fixes your problem too.
Rich.

Re: NoteWorthy Composer 2.1 Beta 12

Reply #73 –
Yes, Rich, it's the same problem, and zooming cures it.  I don't have time just now to experiment, because I need to print the part and take it my rehearsal in a couple of hours. 

As I mentioned, it's only happening in Preview, not Print, so I'm not too worried at the moment.  It also isn't consistent; not all the connecting bar lines from rest staffs to note staffs disappear, and when I added a couple of forced system breaks earlier in the piece, different bar lines disappeared.  I suspect it's just a matter of forcing the vertical bar line to move over half a pixel or so.

Re: NoteWorthy Composer 2.1 Beta 12

Reply #74 –
Excellent changes in beta 12.
Very pleased to see the asterisk indicating a save is needed.

The duplicate names re the backup file in beta 11 are no longer a problem.

I like the wording change for backup queue size.



Rich.

Re: NoteWorthy Composer 2.1 Beta 12

Reply #75 –
David's and Rich's recent posts point to the fact that there is still a problem with barlines, and that the problem seems to be related to orchestral staves. Put that together with my last post, and I sense an opportunity....

(No, David and I didn't plan this.)

Cheers,

Bill

Re: NoteWorthy Composer 2.1 Beta 12

Reply #76 –
Another minor glitch in Preview.  In the treble clef, I had a triplet of quarter rest and two quarter notes.  I moved the rest down a couple of steps so the triplet bracket would be horizontal, and it seemed to make the quarter rest smaller by about half a space.  

Re: NoteWorthy Composer 2.1 Beta 13

Reply #77 –
Beta 13 is now available from the start of this topic. It includes:

  • True notehead colors
    Each notehead can now indicate its own color. When you select a color from the palette, it will apply to the notehead of any new notes that you add. The palette is applied to other added items just as it did in the prior beta releases. When you select a block of notation in the editor, the color palette is used only to change the color assignment from the Visibility tab of Edit->Properties. There is a new Notehead Color in the Notes tab where you can replace existing notehead color assignments in a selection.

  • Improved bar line drawing in Print Preview
    Bar lines should now show up better in Print Preview.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #78 –
G'day Eric,
Barline fix
Works for me - tried scaling from as small as I could see to full screen and never lost sight of 'em at all.

Notehead colours
I can imagine times when I would like the current (beta 13) functionality and times when I'd like the older beta functionalty when entering single notes using the colour palette.  What I mean is, with the new functionality if I pick a colour and place a note, the head is coloured and the stem, flag and beam is not.  

This is fine, and I reckon most times I'd prefer this, but I can also imagine times when I'd want the colour palette to affect the whole note, head, stem, flag and beam (I note the beam is not coloured when I use the highlight colour from the note properties dialogue anyhow).  Perhaps a toggle option so I can choose whichever functionality I need at the time?

I'm not sure about the beam but I think having the beam in the highlight colour is desireable - anyone else have thoughts on this?  I realise this would be inconsistent with current NWC2.0 functionality.  How hard would it be to code a test for this so we can try it and see?

Gettin' late here (after 1 AM) so I'm goin' to bed, see ya.
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #79 –
Barline

Yup - All solved for me.  Even tried Rick's sliding scale and all was Ok.

Notehead colour

All worked fine and I like this facility.

I think the only thing I would comment on (but at this point, I'm not sure if I have a problem with it or not) is:

Note head colour x
Stem colour y
attribute colour = stem
Tie colour = head
Slur colour  = neither
dotted colour = note
accidental colour = note
triplet = neither

I have a feeling that all these things should standardise on the colour of the notehead (or the starting notehead in the case of triplet,slur and tie.

Any other thoughts ?
Rich.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #80 –
Haven't lost track of a single barline since installing beta 13. Thanks, Eric.

Re the function of the color palette: I use different colors in the score mostly to designate separate voices. For that, I want the entire note (head, stem, beam, and any associated ties, slurs, and attributes) to be colored. So the best functionality, for me, is to have the color palette choose the color of the following entire notes, not just their heads. The ability to change only the notehead color is welcome but, I think, not the right choice for the default action.

And while we're on color - it would also be useful to be able to change just the attribute color, so that - for example - one could color an accent red to call attention to it, or color it white so it wouldn't show on the page but would still affect the playback. Just a thought....

Bill

Re: NoteWorthy Composer 2.1 Beta 13

Reply #81 –
But 'White' is non-standard (and wouldn't 'transparent' be a better colour for this purpose?) But I agree that colouring the accents is a desirable feature.

It would be nice to have a palette stored with each file so that files can be ditributed properly.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #82 –
Quote from: William Ashworth –
I want the entire note (head, stem, beam, and any associated ties, slurs, and attributes) to be colored. So the best functionality, for me, is to have the color palette choose the color of the following entire notes, not just their heads.

The best way to do highlight coloring for notes is to place the note, then select it and choose a color for it, either via the backslash key, or by using Edit->Properties (this classic approach supported in earlier releases is unchanged).

Re: NoteWorthy Composer 2.1 Beta 13

Reply #83 –
Quote from: Richard Woodroffe –
Notehead colour

I think the only thing I would comment on (but at this point, I'm not sure if I have a problem with it or not) is:

Note head colour x
Stem colour y
attribute colour = stem
Tie colour = head
Slur colour  = neither
dotted colour = note
accidental colour = note
triplet = neither

I have a feeling that all these things should standardise on the colour of the notehead (or the starting notehead in the case of triplet,slur and tie.

Any other thoughts ?


Been thinkin' 'bout this...  And I'm good with them. 

The only change I'd make is not mentioned above and that is beams should be attibute colour - might make things interesting when beamed notes are different colours though...  I'm not sure which I'd prefer, beam the same as the first note colour or change beam colour at or perhaps between each note.

I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #84 –
Quote from: Richard Woodroffe –
Any other thoughts ?
Accidental, Tie, Dot(s) = head color
Articulation(s) = object (stem) color
Beam, Hairpin, Triplet bracket, 3 = first object color
Slur = staff color
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 13

Reply #85 –
If I play the highlighted notes(only notehead), the "Play Highlight" doesn't appear.

<Image Link>


And in beams(included triplet), if I change "Item Color" in Notation Properties, only the stem changes.

<Image Link>
NWC User since 2008

Re: NoteWorthy Composer 2.1 Beta 13

Reply #86 –
Quote from: Sesirine –
If I play the highlighted notes(only notehead), the "Play Highlight" doesn't appear.

This appears to be an issue.

Quote from: Sesirine –
And in beams(included triplet), if I change "Item Color" in Notation Properties, only the stem changes.

This is as expected. The notehead has its own color spec, in the Notes tab.
 

Re: NoteWorthy Composer 2.1 Beta 13

Reply #87 –
Quote from: NoteWorthy Online –
The notehead has its own color spec, in the Notes tab.
Yuk. What's next, an accidental and notehead spec in the Notes tab?

I was about to compliment you an how notehead color was added without complicating the property page ... until Beta 13.
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 13

Reply #88 –
Quote from: NoteWorthy Online –
The best way to do highlight coloring for notes is to place the note, then select it and choose a color for it, either via the backslash key, or by using Edit->Properties (this classic approach supported in earlier releases is unchanged).

Well, uh....that's exactly the problem. Two problems, actually. The first is that it takes three steps for each note (place the note; highlight the note; change the color of the note). The second is that this process changes the entire chord. In the situation I was describing - defining a second voice by using notes of a different color from the first voice - I only want to change part of the chord. I do, however, want to change the color attribute of the entire note, not just the notehead. I am now back to having to do that by layers. That's a step backward.

Quote from: Rick G. –
I was about to compliment you an how notehead color was added without complicating the property page ... until Beta 13.

I see your point, Rick, but I think the notehead color belongs where Eric put it, on the notes tab of the properties page. It is, in fact, a property of the note. I suppose it could go on the visibility tab, but that wouldn't be the first place I would look for it.

Cheers,

Bill

Re: NoteWorthy Composer 2.1 Beta 13

Reply #89 –
G'day Bill,
I'm not sure I follow...  Why are you back to layers?

If you want the stem to be the same colour as the note, then place the note, highlight and select colour, then for the next note in the chord unhighlight, select colour, position cursor and <Ctrl-Enter>.

If you want the stem to be coloured, but not the same as any head then select colour, place note, highlight note, select stem colour, then for the next note in the chord, unhighlight note, select next colour, position cursor and <Ctrl-Enter>.
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #90 –
Quote from: William Ashworth –
I see your point, Rick, but I think the notehead color belongs where Eric put it, on the notes tab of the properties page.
I think you missed my point, which was that the option should not be on any property page.

Quote from: William Ashworth –
It is, in fact, a property of the note.
No, it [the notehead color] is a property of the note head, just as accidental, tie, head glyph, and vertical position are. None of these are on either the Note or Visibility Tab. They are all selected with a toolbar button and if a chord member is inserted incorrectly, it must be removed and the correct member inserted.

If a note object is entered with the wrong notehead color, it is a simple matter to remove that note object and insert a one with the proper notehead color. That seems to be a change in the way the user interface operates and may cause confusion. In the past, all aspects of note objects could be changed after entry.

Quote from: William Ashworth –
I do, however, want to change the color attribute of the entire note, not just the notehead. I am now back to having to do that by layers.
Can you post an example of a head/stem color combination that requires a layer?
Note: comments above refer to NWC 2.1 Beta 13
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 13

Reply #91 –
Hi Rick and Lawrie -

OK - here's the example. I'm not sure what's not clear.

You should, of course, use beta 13 to view this. Then try to duplicate it on a single staff. You'll find, I think, that every single-staff method of approaching it either colors just the upper noteheads (I want the stems colored as well) or colors all stems (I only want the top stem of each dyad colored).

If (for example) you try to do this by entering the upper note in the dyad, selecting it, changing its color to red via the "visibility" tab, deselecting, and then entering the lower note, you'll find the lower note comes out red, too. If you try the same technique, but use the color buttons or the "color" item on the notes menu instead of the visibility tab color command, you get the same result. If you enter the top note, change its color to red, choose black as the next note color via the color buttons or the notes menu, and enter the note, you will get a note with a black head and a red stem. There may be some way other than those I just listed to choose item color, but if so, I haven't found it.

Re the location of the notehead color command: I got your point, Rick, I just didn't agree with it. I see the note holistically - the head, the stem, the flag or beam, and any dots, ties, accidentals, etc., are all part of the entity called "the note." Hence, an attribute of the notehead is an attribute of the note. I don't see any difference between determining notehead color on the notes tab and determining slur direction on the notes tab: each is an attribute of the note. Yes, it would be better if the tabs were less cluttered. But since the color buttons currently act differently when an item is selected (change the color of the selected item) and when no item is selected (determine the color of the following item, or in the case of a note, just the color of the head), something other than the color buttons is needed to change the notehead color after entry. Hence the new command on the notes tab. Another, possibly better, approach might have been to create a button or a menu command that toggled the color buttons between choosing notehead color and choosing the color of the entire note. I would prefer that: it would once again make layers unncessary for the attached example. But that's not the way Eric went.

Cheers,

Bill

Re: NoteWorthy Composer 2.1 Beta 13

Reply #92 –
Quote from: William Ashworth –
You'll find, I think, that every single-staff method of approaching it either colors just the upper noteheads (I want the stems colored as well) or colors all stems (I only want the top stem of each dyad colored).
AFAIK, in every version of NWC that supports color, the color of all stems is the object color. There is no version of NWC2 that I am aware of that has any support in its cliptext format that distinguishes between the color of UpStems and DownStems in a single object. I reinstalled 'NWC 2.1 Beta 8' just to check.

IMO, the kind of independent control that you seek is why layering was added.

I guess we look at these objects differently. I need to analyze them the way that they are presented to a User Tool or in nwctxt.
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 13

Reply #93 –
G'day Bill,
yes, in this case, I see why you wouild need layers - did any of the previous beta's do what you wanted in this example?
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #94 –
Hi Lawrie -

I don't have any of the earlier betas still installed, of course, so I can't tell; but I was under the impression that the stem color changed along with the notehead up to beta 13. As I read back, I see only notehead color mentioned in the announcements, so perhaps that was a false memory. At any rate, this is the functionality I thought we were getting, and the one that I would prefer to have. To me - again, it's that holistic thing - the head and the stem should always be the same color, except under extraordinary circumstances (most of them pedagogical). As should the beam, which has never been the case, but which I see as just a flag that happens to be connected to the next note....so having one of them take the stem color and the other one not take it makes no sense to me at all. And flags have always been the same color as the stem.

What do others use colored noteheads for, by the way? Why, other than granting the ability to identify separate voices, are they something to get excited about? Just curious....

Bill

Re: NoteWorthy Composer 2.1 Beta 13

Reply #95 –
Quote from: William Ashworth –
What do others use colored noteheads for, by the way? Why, other than granting the ability to identify separate voices, are they something to get excited about? Just curious....
In a message directed at a small audience, Eric described this as: "Handbell Targetted NWC2 for Color Coding Chord members". More info <here>.

So far, I am underwhelmed. I can be handle all this better with layering.
IMO, the time could have been better spent by modifying NWC2 so that the systemic bar line could be suppressed.

OTOH, if these changes make NWC2 the "premiere software for Bell Choirs everywhere", I will have been wrong. Won't be the 1st or last time.
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 13

Reply #96 –
Thanks for the link, Rick. I had no idea.

Bill

Re: NoteWorthy Composer 2.1 Beta 13

Reply #97 –
The correction to notehead alignments seems to have put the slur placement awry.

Quote
!NoteWorthyComposerClip(2.0,Single)
|Clef|Type:Treble
|Chord|Dur:8th,Slur|Pos:0!1,1!6,3!2|Opts:Stem=Down,Beam=First
|Chord|Dur:8th|Pos:0!1,1!6,3!2|Opts:Stem=Down,Beam=End
|Chord|Dur:8th,Dotted,Slur|Pos:0!1,1!6,3!2|Opts:Stem=Down,Slur=Downward,Beam=First
|Chord|Dur:8th,Dotted|Pos:0!1,1!6,3!2|Opts:Stem=Down,Beam=End
!NoteWorthyComposerClip-End

and those paired dots in the same staff space are just not right. It would be better to leave one of them out, but since the program evidently recognizes this situation why not put the dot for the space note where it should be and the dot for the line note one space away. At worst this second dot would only duplicate a dot already there from another note in a very clustered chord.

Re: NoteWorthy Composer 2.1 Beta 13

Reply #98 –
Quote from: Peter Edwards –
The correction to notehead alignments seems to have put the slur placement awry.
and those paired dots in the same staff space are just not right.
Neither represent a change from NWC 2.0
Registered user since 1996

Re: NoteWorthy Composer 2.1 Beta 14

Reply #99 –
Beta 14 is now available from the start of this topic. It includes:

  • New multiple document selector in the status bar
    Open documents are now shown in the status bar. You can activate any of your open documents from this new selector.