FizzBuzz in Powerchords

Did you post this to deliberately nerdsnipe folks for your amusement? If so, I hope you are adequately amused.

At first glance, the choice of mm:ss timestamps glared at me as decidedly non-musical. You clearly stated it was 4/4 and the tempo is defined as 120bpm, so why not use measures and beats? Additionally, even if we stick to mm:ss notation, your resolution of 1s causes your instructions to execute at 1/2 the system's capability (essentially you are limited to playing at half speed, 60bpm but there's no way to tell what the note duration is supposed to be in musical notation from this; that is, if those are 8th notes, for instance, at 120bpm, your execution is even slower.)

So we'd want to, at the least given this one example, increase the resolution to support half-seconds, so mm:ss.d. But this requires someone to do the math from the tempo to the current time, and it isn't very musical. So, to fix this, I suggest a "measure.beat" notation, that is:

    1.1 ...
    1.2 ...
    1.3 ...
    1.4 ...
    2.1 ...
    ...
    2.4 ...
    3.1 ...
    ...

So let's add to your __init__():

        ...
        self.current_measure = 1
        self.current_beat = 1

and change your _generate_timing() to:

    def _generate_timing(self) -> str:
        """Generate timestamp in measure.beat format"""
        return f"{self.current_measure}.{self.current_beat}"

and in _add_instruction, change your current_time incrementor to:

        self.current_beat += 1
        if self.current_beat > 4:  # In 4/4 time
            self.current_beat = 1
            self.current_measure += 1

But... then the "we're not monsters" 4/4 constraint nagged at me.

Some of us are monsters:

    ...
    beats_per_measure, beat_value = self.time_signature
    # and other such updates
    ...

all together, gives us output like this:

    // Guitar Code Translation
    // Time signature: 4/4
    // Tempo: 120 BPM
    // Standard tuning
    
    1.1 - Palm mute E5                   // Read input
    1.2 - Palm mute E5                   // Read condition       
    1.3 - Palm mute E5                   // Read input
    1.4 - A5 [sustain]                   // Write output and return
    2.1 - Palm mute E5                   // Read input
    2.2 - Palm mute E5                   // Read condition       
    2.3 - G5 -> D5 [sustain]             // Evaluate condition   
    2.4 - Palm mute E5                   // Read input
    3.1 - A5 [sustain]                   // Write output and return
    3.2 - Palm mute E5                   // Read input
    3.3 - Palm mute E5                   // Read condition       
    3.4 - G5 -> D5 [sustain]             // Evaluate condition   
    4.1 - Palm mute E5                   // Read input
    4.2 - A5 [sustain]                   // Write output and return
    4.3 - Palm mute E5                   // Read input
    4.4 - A5 [sustain]                   // Write output and return
    

or, monstrously, this:

    // Guitar Code Translation
    // Time signature: 7/8
    // Tempo: 90 BPM
    // Standard tuning
    
    1.1 - Palm mute E5                   // Read input
    1.2 - Palm mute E5                   // Read condition       
    1.3 - Palm mute E5                   // Read input
    1.4 - A5 [sustain]                   // Write output and return
    1.5 - Palm mute E5                   // Read input
    1.6 - Palm mute E5                   // Read condition       
    1.7 - G5 -> D5 [sustain]             // Evaluate condition   
    2.1 - Palm mute E5                   // Read input
    2.2 - A5 [sustain]                   // Write output and return
    2.3 - Palm mute E5                   // Read input
    2.4 - Palm mute E5                   // Read condition       
    2.5 - G5 -> D5 [sustain]             // Evaluate condition   
    2.6 - Palm mute E5                   // Read input
    2.7 - A5 [sustain]                   // Write output and return
    3.1 - Palm mute E5                   // Read input
    3.2 - A5 [sustain]                   // Write output and return
    

Of course, this brings to mind the topic of clock cycles per opcode, etc. Actually, it brings to mind all sorts of nerdsnipe-y things.

To the main point of Turing completeness: I'm not an expert in this area, but I think aside from the finite fretboard length (and maybe this is a semantic issue or a philosophical one but...) your implementation, even assuming an infinite fretboard length leaves me feeling funny wrt "memory".. it feels more like a translation or log stream of execution of the AST and not an actual way to store or manipulate data. I don't have a solution yet, but a capo keeps popping into my head as wanting to fit in somewhere.

Thanks (both honestly and sarcastically) for the diversion/snipe. I have forked the repo and the above suggestions are reflected in my fork. I can send a PR. ;-) https://github.com/scottvr/turing_complete_guitar (Also, I was tempted to rename my fork "tuning_complete_guitar)

Hopefully I'll stop here, but that capo in my head keeps pestering me to carry on.

Also, that hardcoded "Standard tuning" is asking me to investigate what could be added with alternate tunings. Ugh.. sniped!