> I thought of exactly the solution you already programmed, it seems: > if the delay is extended to exactly the length of a loop, we do not > answer correctly to the immediate playing but at least build on the > loop together. Yes, in practice it seemed to work pretty well. The biggest problems are usually just getting things set up (a phone call in parallel with the network connection helps a lot), and making sure that the sounds are the same on both sides (for which General MIDI synth patches help). A "shared drum pattern editor" is another style of interface for networked music creation, but using live MIDI input is a fair bit more challenging/interesting. > But how do you detect the correct delay correction > since the delay over the net is not constant? It's not delay correction as much as re-sychronization. The information sent across the wire is time-tagged data in the time-frame of the sender. The receiver takes this, adds an amount of time that is (in normal situations) greater than the greatest possible network delay, and then re-synchronizes the start time of the phrase to the clock of the receiver. One key to making this work with a minimum of total delay is to process the data in small chunks (say, one or two beats). You need to be reading MIDI input, playing MIDI output, reading TCP/IP input, and writing TCP/IP output, all in parallel. Some languages make that easier than others :-). > So maybe the first net-concert that will groove well will be a > loopers meeting? :-) A few years ago, I started a small mailing list (radiated-music) of people interested in this type of thing, but due to the limited response and prerequisites for using my application, I lost interest after my initial demonstration and network jam with a friend. If anyone encounters a situation where demonstrating this kind of networked music would be appropriate (e.g. a looping event at which a network would be available), I'd be interested to hear about it. ...Tim...