I’m not sure if this can actually be classified as a bug, since I’ve been tweaking a library function (at my own risk) to see what it would do. I’m reporting it anyway, because - who knows? - it may be hinting at a bug at a more fundamental level.
The TRACK block from the Tunescope library
This is the original block:
I thought its code was rather much for what it’s apparently trying to achieve, and (partly for fun, partly to understand what it does) I made a rewrite:
And why not make it even simpler? (these might one day become famous last words )
The third version doesn’t play
I tried to play each version, like this example with the original version of the TRACK block:
The original and version (2) play without any problem, but version (3) does nothing.
All of them report the same result (even with case sensitivity on):
Now isn’t that weird?
From a functional (or user) perspective each implementation reports the same result, but when fed to the PLAY TRACK block, the result of version (3) is apparently not up to par.
Unfortunately Tunescope isn’t very communicative about why it will not digest input.
So what is happening here?
The original TRACK block reports a list that is internally represented by a dynamic array. This is tested with the hidden LINKED? block from the List utilities library. So does version (2), whereas version (3) is diagnosed as a linked list. If original and version (2) are LINKed (another hidden block), they will not play anymore. Conversely, if version (3) is UNLINKed - I made that block myself - it WILL play.
This links to the code, so you can see for yourself.
I found the issue with processing linked lists even to exist within a chord. If a chord is internally represented as a linked list instead of a dynamic array.
The result of the above block looks (and, from a functional perspective, is) exactly the same as:
... but the latter is played, while the first is ignored.