I can't make UDP discovery work reliably over wifi (Ivan), even on a local machine. Instead of using UDP discovery it would probably be better to simply use a separate server as a discovery service, I think.
UDP vs TCP
The rate will likely be around 60 frames per second, in a local network, in the worst case. For our use case this means around 324Kb/s, which can be safely implemented as a TCP connection with a reliable protocol. If the latency proves to be problematic, we could use PUB/SUB from nanomsg, which still drops packets, instead of resending them.
Reliable vs unreliable protocol
If we use a reliable protocol we can implement extra commands for the server such as, shift colors, update, etc. That takes few bytes of instructions and could "update 1000" (limited by update rate of the pi) times per second to make use of all the pixels on the screen.
If we use unreliable protocols, we have to always output the whole screen to the server.
Client side or server side?
Should we have the processing that controls the iron curtain on the client side, server side, or have the option to choose?
Having the processing be in the client side looks like it would make the development faster.
Having the processing on the server would allow people to control it through cellphones, which is pretty neat.
Is there anything better than jackd for audio redirecting that is multiplatform?
Doesn't matter what we use, we should be able to use mock audio for this if needed, such as choose an audio file to use as audio input, or choose a constant beat for this, or simply a microphone.
Vamp plugins seem to be pretty useful for this. Also, an abstraction such as milibeats, as implemented by Tetazoo's beat-of seems extremely useful.
If we want to be able to combine patterns, probably the best way is to implement patterns in a way that they don't have an internal state, and only depend on the audio and on the previous