IMO, NoteWorthy would be improved if it allowed more range and granularity in its numeric operations.
Many quantities are stored as bytes which made sense in 1994 when the typical environment was Windows 3.x In the current millennium, 32bit integers are processed as quickly as bytes; memory and persistent storage have increased exponentially. In many areas, it makes little sense to continue with byte sized numbers.
NWC 2.5 has set the stage for the future. The new Boundary and Spacer objects resolve to the nearest hundredth of a note width:
!NoteWorthyComposerClip(2.5,Single)
|Spacer|Width:100
|Boundary|Style:Gap|Width:200
!NoteWorthyComposerClip-End
In the UI (User Interface), the spinboxes allow for 2 digits after a fixed decimal point.
Moving forward, I think that all the values for x that appear in the following code after a colon or equals sign ought to be replaced by x * 100
Spinboxes for these items should allow for 2 digits after a fixed decimal point.
!NoteWorthyComposer(2.5)
|StaffProperties|BoundaryTop:12|BoundaryBottom:12
|Lyrics|Offset:2
|Note|Opts:StemLength=7,XAccSpace=1,XNoteSpace=1
|Rest|Opts:VertOffset=1
|Chord|Pos:|Opts:Stem=Down,StemLength=7,XAccSpace=1,XNoteSpace=1|Pos2:
|RestChord|Opts:Stem=Down,StemLength=7,XAccSpace=1,XNoteSpace=1,VertOffset=2|Pos2:
|Boundary|Style:NewSize|Upper:8|Lower:8
|Dynamic|Style:mp|Pos:1
|DynamicVariance|Style:Crescendo|Pos:2
|Flow|Style:Coda|Pos:1
|PerformanceStyle|Style:Tenuto|Pos:1
|Ending|BracketHeight:5|VertOffset:1
|SustainPedal|Pos:1
|Tempo|Tempo:120|Pos:1
|TempoVariance|Style:Caesura|Pos:2
|Text|Text:"x"|Pos:1
|Instrument|Pos:1
|MPC|Controller:pan|Pt1:1|Pos:1,0
!NoteWorthyComposer-End
(In the above, "Style:" should be interpreted as any supported style. For some reason, nwctxt requires a valid style where the Style tag is allowed)
Once this groundwork is laid, NoteWorthy would have the data it needs to resolve MIDI (playback) quantities, and EMF (screen, printer) coordinates, to the full granularity allowed by the MIDI and EMF specifications. Support could be added at a leisurely pace without the need for changes to the file layout.
These items ought to be changed to allow negative quantities:- Spacer Width
- Extra Accidental Spacing
I don't see why the full signed 32bit range in nwctxt should not be allowed. The nwctxt parser could simply use the closest allowed value when converting to NWC's binary format.
Topic: Better range and granularity needed in nwctxt (Read 3519 times)
previous topic - next topic
