Skip to main content ↑ ↓
Topic: BarLabel.ms (1.2) (Read 12519 times) previous topic - next topic

BarLabel.ms (1.2)

This object creates bar labels for a score, similar to those created with the BoxMarks fonts. The font can be any of the available NWC font classes, and the size of the box and text can be scaled. The text can either be user specified, or if left blank, the measure number of the prior or next bar will be used.

Paste the following snippet into NWC 2.75, then go to Tools > Manage Objects to install the object.

Code: (nwc) [Select · Download]
!NoteWorthyComposerClip(2.75,Single)
|Clef|Type:Treble
|TimeSig|Signature:4/4
|Rest|Dur:Whole
|Bar
|User|BarLabel.ms|Pos:8|Which:prior
|Rest|Dur:Whole
|User|BarLabel.ms|Pos:8
|Bar
|Rest|Dur:Whole
|Bar
|Rest|Dur:Whole
|User|BarLabel.ms|Pos:8|Text:A
|Bar
|Rest|Dur:Whole
!NoteWorthyComposerClip-End
For details on the object's parameters, refer to the context-sensitive help on object's properties page.

Re: BarLabel.ms (1.0)

Reply #1 –
Excellent object addition...well suited for rehearsal marks.

Re: BarLabel.ms (1.0)

Reply #2 –
That's very useful, especially for those of us that prepare choral rehearsal files.
Thanks Mike.
Rich.

Re: BarLabel.ms (1.0)

Reply #4 –
Thanks to everyone for their kind words and "likes". I have recently begun creating practice scores for our choir, and the first piece of music I am transcribing has rehearsal marks containing measure numbers. So I created this object as a time-saver for myself, and of course I would share it with the rest of the community here. As always, I appreciate the feedback and comments.

Thanks again,
Mike

Re: BarLabel.ms (1.0)

Reply #5 –
Hi Mike,
I haven't always commented, but I am finding your submissions either actually or potentially very helpful.  Which just depends on my immediate needs when they appear :)

Please keep up the good work!
I plays 'Bones, crumpets, coronets, floosgals, youfonymums 'n tubies.

Re: BarLabel.ms (1.1)

Reply #6 –
The BarLabel.ms object has been updated, with the following changes:

  • Parameter added to allow label to use prior or next bar number.

Please refer to the parent post for additional information.

Re: BarLabel.ms (1.1)

Reply #7 –
Hi Mike

I use the bar label constantly for my scores, so I add my gratitude for your generosity in sharing it with the NWC community. I have a  question: is it possible to add a "preserve width" box? Sometimes I need to add text close by and instead of using insert to add spaces (which sometimes does strange things to other things, such as the crescendo or decrescendo hairpins -- another topic which I will want to explore), or having to move the label up above the text, maybe preserving the width would be better? If it already has this capability, then I have missed it.

Thanks again for your help!

Re: BarLabel.ms (1.1)

Reply #8 –
I doubt if this is possible ten years after the last update (and the five-year-old request not fulfilled) but I would like to see an additional option on the "Reference Which Bar" property: "Default".  This would look immediately to the left and right of the object, and, if there were any type of bar immediately adjacent to the object, set the bar number to the number of that bar.

Re: BarLabel.ms (1.1)

Reply #9 –
Just to make sure I understand your request, relative to how the object currently works: With the new value of "default", if the user object immediately follows a barline, then you want it to display that barline's number (i.e. what "prior" would do), and if it immediately precedes a barline, then it should display the following barline's number (i.e. "next"). But what behavior should the object have if the object is somewhere in the middle of the measure?

I think I could accommodate your new behavior by adding another property, let's call it "Auto-select", as a checkbox. If the box is unchecked, then the behavior is as the object currently works. If it is checked, then it will choose the prior or next barline's number if it is adjacent to the prior or next barline. And if it is in the middle of the measure, then it will use the "Reference Which Bar" property to determine which value to display.

EDIT: After experimenting with the code, I think I found a better solution that is closer to your original request. I can add a new value for "Reference Which Bar" that is "auto". Whichever bar is closer to the object will be the one whose bar number is used. If the distance to either bar is the same, it will use the next bar.  Does that sound like a workable solution?

Re: BarLabel.ms (1.1)

Reply #10 –
Thanks for the quick reply.
 
Quote from: Mike Shawaluk –
Just to make sure I understand your request, relative to how the object currently works: With the new value of "default", if the user object immediately follows a barline, then you want it to display that barline's number (i.e. what "prior" would do), and if it immediately precedes a barline, then it should display the following barline's number (i.e. "next").
Exactly. If object is not immediately adjacent to a bar, it could default to the closest one, but I'm not sure that calculation is worth the trouble. Also, if it is in the first measure of a line, it should use that measure number unless there is a bar immediately after.
I wanted it because I had a few "next" which ended at the end if a line. When I moved them after the bar, I had to change the reference. The more I think about it, I'm not sure it's worth the trouble.

Re: BarLabel.ms (1.1)

Reply #11 –
That does sound like a good solution. I posted my prior reply before I saw yours. But your solution sounds like a good one if you feel like changing it. I assume users of the old version would not be impacted.

Re: BarLabel.ms (1.2)

Reply #12 –
The BarLabel.ms object has been updated, with the following changes:

  • Parameter "Reference Which Bar" has new option 'auto' to choose nearest barline (thanks to @fathafluff for the suggestion)

Please refer to the parent post for additional information.
 

Re: BarLabel.ms (1.1)

Reply #13 –
Quote from: fathafluff –
I assume users of the old version would not be impacted.
I always try to update objects so they will be backward compatible. Because of that, I needed to keep the default value of that parameter as "next", although "auto" might have been a better default.