Latest version of Antescofo, on macOS Ventura, Max 8.6.2
I have a score which includes some tempo changes. When I ‘play’ from the start, it follows the tempi given by BPM markings. But if ‘playfrom’ a label mid-score, it seems to adopt the first-stated tempo in the score but ignore subsequent changes. A bug?
Thanks, Neal
Hello Nealfarwell.
I observe the expected behavior with version 1.0-598. For example, with the following program
BPM 60
NOTE A4 1
NOTE B4 1
NOTE C4 1
BPM 30
NOTE A4 1
NOTE B4 1
NOTE C4 1
BPM 120
NOTE A4 1
NOTE B4 1 start
NOTE C4 1
loop 1
{
print tic at $NOW
}
if I playfrom start, I have the following trace on the Max console:
print: tic at 10.5
print: tic at 11.
print: tic at 11.5
print: tic at 12.
print: tic at 12.5
print: tic at 13.
print: tic at 13.5
print: tic at 14.
print: tic at 14.5
print: tic at 15.
print: tic at 15.5
print: tic at 16.
print: tic at 16.5
as expected. Can you put some trace to check the tempo after the label and if it does not work, can you send me your program ?
Thanks,
Jl.
Hi Jean-Louis,
Thanks for this. Here’s what I’ve found in the attached examples.
score: TempoTest
‘play’ displays (and sounds) expected durations, including new tempo from measure 100
‘playfrom measure99’ ignores the tempo change in measure 100, continuing with the earlier tempo to the end
score: TempoTest-CUT-DOWN
‘play’ displays (and sounds) expected durations, including new tempo from measure 100
‘playfrom measure99’ ignores the tempo change in measure 100, continuing with the earlier tempo for that measure; then changes to the new tempo in measure 101
I’ve just sent you the simple ‘TempoTest’ scores.
In my actual score, between the start and the tempo change there are many measures. In this case, ‘playfrom’ just before the tempo change ignores it. But, if I delete all the intervening measures, then there is a kind of rit over several beats, after the stated tempo change (from 96 to 72, which are the two stated BPM).
Thanks for further insights or a fix!
Neal
AntescofoPlayfromProblemPatcher.txt (10.6 KB)
TempoTest.asco.txt (1.6 KB)
TempoTest-CUT-DOWN.asco.txt (1.1 KB)
In my experience playfrom kind of ignores the event it is starting from: in other words, if it is supposed to start from event index N, it will actually from N+1!
May be a hint… .
Hmm, that’s strange! Is there a logic to it, or just a legacy behaviour?
I found ‘playfrom’ was sending the action immediately attached to the labelled event, which suggests N not N+1.
But anyway, in my example, I’m telling ‘playfrom’ to start several events before the tempo change, and it’s still treating that tempo oddly / ignoring it.
Hello Neal (and hello Arshia).
This is definitively a bug. The bug relates solely to the duration of events. My example program exhibits the right behavior : the timing of the action (here a loop) takes correctly into account the tempo change in the score, but the tempo changes are not always taken into account when computing the duration of an event in play mode, as showed by the Neal example.
The correction is done but we’ll have to wait a little while before I can publish the corrected version. It’s a public holiday in France on 8 May and I won’t be able to compile all the versions until Friday at the earliest (if you use the x86 version, I can send it now).
In the meantime, for not being stuck, what you can do is to “normalize” the score by using always the same BPM and adjusting the duration of the notes. I agree: it is an heavy task and it is not convenient.
Hi Jean-Louis,
Many thanks for your lightning investigation and correction! (On a holiday too.) No worries if it’s a few days to recompile — I can continue building my score and system knowing the corrected version is on the way. The score has lots of time-signature changes, and actions offset by fractions of a beat, so I really don’t want to take the ‘normalize’ route!
I’ve got another question on a related topic, but for list-hygiene I’ll start a separate thread (or check for related threads first).
Thanks again,
Neal