Probably more an undocumented (as far as I know) or unexpected behaviour / feature, rather than a bug, but in case it is a bug, I'm posting it in the bug forum. This is something that people who are constructing long audio strings (>31 or 32 notes) with P8SCII should be aware of.

The point at which characters begin to be printed seems to vary; for me it's somewhere around the 40th character, which is likely around the 32nd of the notes in the string. (I feel it should be consistent in this - that always after the 32nd note plays it should drop back to printing text, but unless my tests or count are off this doesn't seem to be the case.)

The behaviour likely exists because the sfx playback is written for 32 note sfx lengths. For those who haven't read about the audio P8SCII: "If an sfx index is not specified, a non-active sfx between 60..63 is selected automatically. To fill the SFX with data before playback, the following commands can then be appended." Pico-8 manual

Examples of the feature

At command line (the last "a" will print):

?"\aspv1c0eac1eac2eac3eac4eac5eac6eac7eaeaeaeaea"

Or:

?"\aspv1c0eac1eac2eac3eac4eac5eac6eac7eaeaeaeaehello world!"

Or in a cart:

function _init()
cls()
?"\aspv1c0eac1eac2eac3eac4eac5eac6eac7eaeaeaeaehello world!"
end

function _update()
end

function _draw()
end

As a feature, I don't know that it gets you anything more than printing text before the audio command, e.g.:

?"hello\as9v1c2egcegc3"

Which as expected will print "hello" and make the specified sound.

I'm running pico-8 0.2.4, on a Windows 10 machine.

A single P8SCII audio pattern is limited to 32 notes. The notes are written to a SFX slot then played, and a slot can only hold 32 notes.

Only octaves 1-4 are officially supported. From experimentation, it looks like octave 5 will support notes C, D, and E, and notes above that are treated as E5. Octave numbers 6 and 7 are not recognized as octave numbers. So in your example you're actually getting 32 notes, but many of them are treated as C5 and E5.

Audio string characters that appear where a note or control code is expected but are not a valid note or code are treated as C. They can even be followed by an octave number: ?"\as9c1def@2def" This is what happens when trying to set the octave to 6 or 7: these characters are treated as C notes.

A space character terminates the pattern, and is consumed and not printed: ?"\acdef hello" For a 32-note pattern, the next character after note 32 is consumed and not printed no matter what it is. It seems like it'd be slightly more intuitive if it only consumes the next character if it's a space, so it's easier to see the 32-note break point when troubleshooting over-long patterns.

I think that's a complete explanation for what you're seeing. Let me know if you're seeing something else.

?"\aspv1c0eac1eac2eac3eac4eac5eac6eac7eaeaeaeaea"
        0 000 000 001 111 111 1112222222222333DT
        1 234 567 890 123 456 7890123456789012

32 notes:
* 1-17 are as expected
* 18, 22, 25-32 = E5
* 19, 20, 24 = C5

D = delimiter
T = printed text                       

The invalid character behaviors seem worth documenting so I added it to the Wiki section on audio strings.

@dddaaannn

The 6 and 7 being invalid and being counted as notes, and the space as the terminating character, explains the erratic end points I saw.

Thank you for explaining this, for the clear code-style representation at the end, and for the very thorough answer.

Thank you also for creating and maintaining the wiki. It's invaluable.

& Merry Christmas!

Thank you for posting the issue! I hadn't looked into this before, glad to have it documented.