Finale Forum

Is it a bug or a feature that Finale seems to handle the Retranscribe function differently when applied to multiple measures compared to single measures?
Here is a very short screencam video of what I did:
https://www.youtube.com/watch?v=1kyX9Un95sI
When I select the full piece and apply Retranscribe the first triplet in the last measure gets messed up (the other measures are ok).
When I just select the last measure, the triplet doesn't get messed up.
(The notes are an excerpt from a larger project where this weird behaviour occurs several times on tuplets).

My workaround was to develop a JW Lua script which applys the Retranscribe function to each measure individually instead of all measures at the same time. It works perfect. But why?

This definitely qualifies as a bug.

If I am not mistaken, a quarter triplet at the beginning of a measure gets “messed up” by the Retranscribe function, only when also at least four measures before the triplet measure are selected.

In Other Words:
Select any (quarter) triplet measure, and the three measures before that measure, and Retranscribe does not mess up the triplet.
Select any (quarter) triplet measure, and at least four measures before that measure, and Retranscribe messes up the triplet.

NB:
The quarter triplet must begin the measure.
A quarter triplet that ends a measure does not get messed up.

The bug seems to be isolated to a time signature of 4/4.
I have not been able to reproduce the bug in other time signatures.

elbsound, I recommend that you send the Finale document to MakeMusic, so that the bug can be documented and registered.

Thanks, Peter, for your response. I have now opened a support case at MM.

If there is a rest before the measure with the quarter triplets, the bug is not triggered. Even a small rest at the end of the measure.

I am going to guess that this is quite directly linked to the bug involving entering triplets at the end of a measure. The results look quite similar, if not the same.

Zuill

Also, after retranscribing all the measures, if you find any measure messed up, apply retranscribe to just that measure, and it should return to its normal state. In my test, that is true. I can't speak for your file.

Zuill

Thanks, Zuill. Indeed if I do Retranscribe a second time on the messed up measure, it looks fine again.
The problem is: there are lots of measures that are messed up in the score.
So the JW Lua script seems to be the more elegant solution.

Another observation. This seems to occur with a pattern. Counting from the first bar selected, this occurs in a measure starting with a tuplet in the 5th bar, then every 4 bars from then on. But only bars starting with a tuplet are affected.

Zuill

P.S.: You might try the LUA script doing 4 measures at a time. That may speed things up.

To do a quick test, fill a document with quarter or 8th triplets and see the bug in bars 5, 9, 13, 17, etc. I tested this in 2011 and get exactly the same behavior. I will guess it has always been this way.

Because of the precise, reproducible results, it should be easier for the programmers to correct (one would hope).

Zuill

Thanks, Zuill, for breaking down this bug.
I have uploaded a new video that demonstrates your description to MM.
https://youtu.be/zTRVVwZzXAo
Will let you know when I get a response.

Jan
https://elbsound.studio

Now I have a response from MM.
First they supposed to change the quantization settings to smallest note value quarter notes ... no comment on that (everything became quarter notes!).
Then they supposed to change the quantization settings to eighth notes ... still no good idea ... all triplets disappear.
But they confirmed it is indeed a bug.

Jan

I already tried different quantization settings, with equally bad results. I'm surprised they didn't test things before making suggestions.

Thanks for reporting.

Zuill