bugDenemo - Bugs: bug #27004, Non-printing rests don't follow...

 
 

bug #27004: Non-printing rests don't follow the Time Signature changes in additional voices

Submitter:  Pietro Battiston <toobaz>
Submitted:  Fri 10 Jul 2009 02:54:29 PM UTC
   
 
Category:  None
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 29 Jan 2014 04:47:58 PM UTC, comment #5: 

There is now a new structured staff command that clones time signatures.

Richard Shann <rshann>
Group administrator
Thu 03 Sep 2009 09:57:15 AM UTC, comment #4: 

Yes, indeed I meant time signature, and I think your solution makes sense.

Pietro Battiston <toobaz>
Thu 03 Sep 2009 09:27:00 AM UTC, comment #3: 

this bug refers to "tempo changes"
I think time-signature changes is meant?
I think it would be quite possible to script a solution - e.g. adding a staff and stepping through the original staff copying and pasting any timesignature changes found.

Richard Shann <rshann>
Group administrator
Fri 10 Jul 2009 03:06:38 PM UTC, comment #2: 

(in the second paragraph of my last comment, 's/new note/new voice' )

Pietro Battiston <toobaz>
Fri 10 Jul 2009 02:59:05 PM UTC, comment #1: 

Mmmh... truth is the issue is more basic, and doesn't have to do with rests in particular (though it is more annoying when in the new voice you have to wirte just a measure, after tens of empty ones).

To reproduce, just type some notes with a tempo change in the middle, then add a new note, start from the beginning and at the tempo change you will see the new voice doesn't conform to the tempo for the stave.

This means the "just calculate true lenght of non-printing rests at export time" is not a good enough solution.

Pietro Battiston <toobaz>
Fri 10 Jul 2009 02:54:29 PM UTC, original submission:  

(denemo 0.8.6 and git)

When a new voice is created in a staff with time changes, the time changes aren't inherited by it.

To reproduce, open the attached .denemo file and export to pdf: it will look like the attached pdf file, while it shouldn't.


The workaround is to redefine, in the second voice, all the tempo changes, but it's not nice, because:
1) the "official" method to insert single-staff polyphony (possibly for a measure only!) is to add a voice, and that way it's a pain if there were many tempo changes before
2) anyway, there is a discrepancy between Denemo's visual output and the generated lilypond and pdf
3) moreover, if I add a tempo change in a voice, the notation of the (same) tempo change in the other voice disappears, as if Denemo was in fact partially aware that those tempo changes are cross-voices

Notice that clicking "Join voices" doesn't seem to have any influence on the issue.

Probably the solution would be to establish that when a new voice is created, it inherits all the tempo changes of the other voice of the staff. There is obviously some arbitrariety if the voices of the staff are more than one, but if I understood correctly denemo's logic, it's not a problem, since they will (by induction!) have all the same tempo.

Alternatively, this inheriting could happen at the moment of creating the lilypond file.


A cleaner solution would be to distinguish, in the internal logic, "all staves" tempo changes from the ones regarding only one stave, and make voices and new staves inherit only the "all staves" ones... but I think that not much people have different tempos on different staves, so if they had to manually add some tempo changes, it would be a minor issue.

Pietro Battiston <toobaz>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #18404:  repr.denemo added by toobaz (926B - application/octet-stream - A file exposing the bug and the pdf it produces.)
file #18405:  repr.pdf added by toobaz (21KiB - application/pdf - A file exposing the bug and the pdf it produces.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rshann (Posted a comment)
  • -email is unavailable- added by toobaz (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-29 rshann StatusPostponed Fixed
        Open/ClosedOpen Closed
    2009-09-03 rshann StatusNone Postponed
    2009-07-10 toobaz Attached File- Added repr.denemo, #18404
        Attached File- Added repr.pdf, #18405

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code