One interesting thing is, to me at least - a musician, is that the Spectrums are not necessarily in tune; the first one playing the melody seems sharper than all the others. I wonder if the devs were aware of this, and tried fixing it?..
(On the other hand - since the BEEP routine was being called from BASIC, adding in a pitch adjustment calculation may well have slowed things down enough to throw the timing off again :-) )
Are the internals of the project documented anywhere? I'd love to see how you did the synchronisation (and why you had to use that interloping Acornesque Pi instead of another Spectrum as conductor - was it a file server as well?) and see some code...
A purist would doubtless sigh after a Spectrum only network using Interface 1's ZX Net and Microdrives, but (a) life is too short (b) I doubt anyone else would care and (c) I am not that man. :)
The Spectrum's crystal was chosen for low price, not for closely matching performance (even day-to-day on the same host), so matching would require finding the hosts' CPU frequencies at that moment and compensating for the differences. Possible using the Spectronet, hardly easy.
The Spectrum was a great machine. The kind where the only way to get amazing results was amazing programming. There was no hardware to help the CPU — if you wanted to so something, you had to write code. But that's about the only nice thing I can say about the Spectrum. Build quality, suitability as musical instrument, and so on and so forth... nah.
A restart was always a button-press away if you messed something up. (At least the Spectrum+ had a hard reset button on the side). Not to forget that the OS and BASIC environment were in ROM and took a fraction of a second to boot.
And, eventually, the jack would wear out for those of us who wound up with more bugs than was good for the power jack. Some people actually had to replace the power jack because of this. You can still get those as spare parts, btw. http://www.dataserve-retro.co.uk/contents/en-uk/d7.html
Also it has a real actual genuine soul connected to a higher plane of existence that you communed with every time you used it.
For instance, the Z80's fastest instructions took four cycles, where the 6502's fastest instructions took two cycles.
The Z80's slowest instructions took 23 cycles, and the 6502's slowest took seven cycles.
And even that comparison is over simplified.
(I don't know if there was a 7MHz clock that was divided by 2, or what, or if the thing could genuinely produce 2 pixels per cycle.)
4MHz was somewhat high compared to the 6502-based systems that made up some of its competition, but for many operations the Z80 doesn't run terribly efficiently. Opcode fetch takes 4 cycles and memory read/write takes 3 cycles, making the memory bandwidth of a 4MHz Z80 about that of a slighty-more-than-1MHz 6502. (The 6502 would read or write 1 byte every cycle.) This downplays the value of the Z80's register set and 16-bit operations, though; 6502 zero page is a bit of a poor substitute in many cases, because you lose a cycle from having to read the address byte.
(Compare INC $xx - 5 x 6502 cycles, 2 x opcode, 1 x read, 1 x dummy, 1 x write - with - with INC r - 4 x Z80 cycles, all opcode fetch and then it's done. On the other hand, ADC A,n takes the Z80 8 cycles, because it has to read 2 opcode bytes - something the 6502 will get through in 2.)
I've spent a lot more time using the 6502, but I like both. They are represent two very different styles. The Z80 is a lot more practical in many respects, with its 16-bit registers and relocatable stack pointer. Some 6502-style register-indexed indirect addressing modes wouldn't have gone amiss, though...