NoteWorthy Composer Forum

The nwc-conv.exe command line tool is no longer included with the program.
The program now handles this task on its own.

-convert: This option can be used to convert a file from one format to another.
Usage: nwc2.exe -convert "[input-file]" "[output-file]"
Both files are required on the command line and the file extension determines the conversion.
Supported conversions include:
.nwc    -> .nwctxt, .mid, or .info
.nwctxt -> .nwc, .mid, or .info
Conversions to .mid support a "-0" option for type 0 files.

You can invoke the NWC Lua interpreter by adding a -nwcut switch on the command line:
nwc2 -nwcut [YOURTOOL] < nwcfile.nwctxt > outfile.txt 2> errfile.txt
You must provide the redirects, as the program instance will not automatically attach to your current console session.

The only minor issue is that the path to the files generated in NWC Bottles is very long:
/home/<username>/.var/app/com.usebottles.bottles/data/bottles/bottles/nwc.exe/drive_c/users/steamuser/Documents/NoteWorthy Composer/,

Any takers?

They could be put on a separate layered staff with hidden rests (or stemless mute blank noteheads :-) ).

And a user tool could probably be written that converts the lyrics into ChordPlay objects.

Quote

Changed 0 couplets

I know I could highlight and use Global Mod to make these changes after the fact

there is any way to shorten the length of the slash and reposition it to reflect more of what one would see in a jazz chart?

Quite often I need to enter comping marks - these are really just a slash in place of a crotchet (quarter note) rest.

then I move the rest off the page with Global_mod.  The rest must be moved instead of being made invisible or it won't take up the necessary horizontal space.  Perhaps you could modify this tool to automate that process too (it would need to move the rest).

I am curious whether you also saw this review, and whether it was the motivation for creating this user tool.

So I would say they do work together.

I put the barcounter.nw at the very beginning and then barcounter.hmm where I wanted the change.  Just like PageTxt and PageTxtMaestro.

I should have named the other object Rehearsal Mark.ms; it is probably a more accurate name for it. That would avoid some confusion.

I guess yukulele has version 2.8 beta 1 and Flurmy has version 2.751

In the new beta, the |Text:*| property and User object properties are now stored as strings (replaces the nwcOptText object).

In the current general release, text properties use a nwcOptText class for storage. This is a heavy operation that requires an additional allocated table just to store the encoded string.
In this same release, user object properties are all stored as raw, encoded strings. This creates a complicated approach to handling the text properties.

In the new beta, all of these text properties are maintained as simple decoded strings. All simple strings are passed through an encoding filter before writing them back into a nwctxt file stream, which strives to make scripting changes to these properties much simpler.
It does create an issue for current tools.

As it currently stands, changes will be required in tool code when accessing these text properties. Perhaps the easiest way to handle this is by two utility functions:

Code: [Select · Download]

local function GetTextProp(item,lbl)
  local t = item.Opts[lbl]
  return (t and t.Text) and t.Text or t
end

Code: [Select · Download]

local function SetTextProp(item,lbl,txt)
  item:Provide(lbl,'')

  if item.Opts[lbl].Text then
    item.Opts[lbl].Text = txt
  else
    item.Opts[lbl] = txt
  end
end

Quite different! Why?

But I don't know why the behaviour is different on my side.

you could specifically check for these problems during conversion and either delete or replace them with a flag - maybe "BLANK"?

"   &quot;
'   &apos;
<   &lt;
>   &gt;
&   &amp;

The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they MUST be escaped using either numeric character references or the strings "&amp;" and "&lt;" respectively.
The right angle bracket (>) may be represented using the string "&gt;", and MUST, for compatibility, be escaped using either "&gt;" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.

So: if Musescore can't create a correct a correct coda-working musicxml file, why should I bother?

Boy, the segnos and coda symbols in Musescore are TINY