Olá, Brian!
Muito legal que você já tenha começado a fuçar o material do site!!
Muito chato que tão rápido você tenha esbarrado em um erro do Farnell!! 
Não se preocupe, não é culpa sua... vou explicar o que aconteceu e tentar me fazer entender... para quem ainda não começou a mexer com o Pd talvez o melhor seja pular esta mensagem e pensar nessas coisas apenas quando a dúvida efetivamente aparecer.
O problema está na saída do objeto "f 0", que é aquela variável usada como contador. Jamais num programa bem escrito ele deveria ter duas saídas... nesse patch, ele tem uma saída que vai para o incrementador "+ 1" e outra que vai para o "select". Nesses casos, a linguagem define que os fluxos de informação devem ser processados na ordem em que foram criados, que não por acaso é a ordem em que as conexões aparecem no arquivo .pd. Ao copiar o patch do livro, você conectou primeiro a corda que ia para o "select" e depois a que ia para o "+ 1", o que faz o mecanismo de reset do contador parar de funcionar! Mas repito, a culpa não é sua, é do Farnell... 
Para ilustrar este ponto, coloquei em anexo o seu patch, sendo que apaguei apenas aquelas duas conexões e as recriei na ordem em que elas deveriam ser acionadas (primeiro "+ 1", depois "select"). Note que agora o patch funciona. É interessante pensar em porque a outra ordem não funcionava: o valor do contador ia primeiro pro "select", que quando recebe "3" redireciona o fluxo para o "reset" que armazena "0" na variável, e *depois* disso chega (atrasada) aquela mensagem com valor "3" no objeto "+ 1", que manda "4" para a variável que armazena o contador, desfazendo o mecanismo de reset.
E por que eu insisto que a culpa é do Farnell? Porque a versão correta e a versão errada são visualmente idênticas! Para resolver esse tipo de ambiguidade, existe um objeto chamado "trigger", que força uma determinada serialização quando um objeto se conecta a vários outros. No mesmo patch eu coloquei a versão com trigger. A convenção é que o trigger "dispara" as cópias da direita para a esquerda, então primeiro o número é incrementado, e só depois ele vai para o select e eventualmente dispara o mecanismo de reset.
Talvez eu tenha sido meio "caxias" quando disse que jamais um programa deveria ter duas cordinhas saindo de uma mesma caixinha. Várias vezes isso é totalmente inofensivo, particularmente em situações que não envolvem loops ou retro-alimentações. Mas usar "trigger" é sempre o melhor meio de não gerar patches visualmente ambíguos, e ter que ficar caçando bugs que não parecem fazer sentido nenhum.
Abraço,
Marcelo