I'd like to address the topic of delay and synchronization during internet jams. I feel that the very approach of trying to accomplish audio synch in the current medium of audio over the internet is somewhat inappropriate. In a way it's kind of like trying to get flute sounds out of a guitar. Maybe it's possible, but it's really not in the nature of the beast. To be sure there will come a day when the lag monster is largely defeated and we can jam with simultaneous artists, but that day is not today. I remember the frustration expressed by my fellow grad students whose simulators kept their workstations or even supercomputer accounts busy for long periods of time. I had no such problems as I had chosen to restrict my simulation constraints such that compute times were short. Looking back, this was appropriate as I was matching what I wanted to accomplish to what I had as a resource. In a similar way, perhaps we should not be attempting to defeat the lag monster, but rather to create novel musical jamming techniques that operate within the timing constraints of the web. Now, that's easy for me to say and do because via the power of ChucK and my amateur musician status I can do just about whatever I want, and others may not have that luxury for various reasons. So please accept my apologies if you are limited in this way creatively beyond your control, however I do maintain that we should be doing what we can do, not what we want to do. Back when I constrained my simulator complexity within the available compute constraints, I suffered the consequences of riling up anger and derision from those without that freedom or that choice. I hope that will not be the case with this message. Rather, I wonder if we can discuss ways to create music that fits the web rather than discuss programming that accomplishes synchronization over a web that denies it. I welcome your comments on this topic and I apologize in advance if I have offended anyone. Just my two cents, eh? Les
hi
On Wed, May 18, 2011 at 7:09 AM, Les Hall
In a similar way, perhaps we should not be attempting to defeat the lag monster, but rather to create novel musical jamming techniques that operate within the timing constraints of the web.
yes, i think this is a much better kind of approach. it's like in a mario game when he is swimming- the controls do not respond so rapidly, and there is the notion of momentum too. even though [up until this point] improvising musicians have been all walking that ultra-present wire, maybe interesting music can be made where there is a delay between doing something and having it affect the flow of music. keep on doing! -- \js : "verbing weirds language." -calvin [http://or8.net/~johns/]
How about you receive what your friend is doing after a predictable delay,
so like it's buffered, and you're in sync with them in a quarter note sense
but hearing what they did a bar earlier... So say it's in 4/4 time,
everything will still sound okay, but to each user you're hearing what the
other guy did a bar ago... make sense?
On Thu, May 19, 2011 at 12:53 AM, john saylor
hi
On Wed, May 18, 2011 at 7:09 AM, Les Hall
wrote: In a similar way, perhaps we should not be attempting to defeat the lag monster, but rather to create novel musical jamming techniques that operate within the timing constraints of the web.
yes, i think this is a much better kind of approach.
it's like in a mario game when he is swimming- the controls do not respond so rapidly, and there is the notion of momentum too. even though [up until this point] improvising musicians have been all walking that ultra-present wire, maybe interesting music can be made where there is a delay between doing something and having it affect the flow of music.
keep on doing!
-- \js : "verbing weirds language." -calvin [http://or8.net/~johns/] _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
hola
2011/5/18 Matt B.
How about you receive what your friend is doing after a predictable delay, so like it's buffered, and you're in sync with them in a quarter note sense but hearing what they did a bar earlier... So say it's in 4/4 time, everything will still sound okay, but to each user you're hearing what the other guy did a bar ago... make sense?
well, i'm not coding it, but i think a more free form approach [without barlines] is what i was imagining. also, network latency will not often match up with beats. if that kind of rhythmic precision is important, perhaps ChucK could do the quantizing itself. i was thinking more or non metered music- collections of sounds. [ambient, "field recordings", and the like] -- \js : "verbing weirds language." -calvin [http://or8.net/~johns/]
On May 18, 2011, at 11:53 AM, john saylor wrote:
hola
2011/5/18 Matt B.
: How about you receive what your friend is doing after a predictable delay, so like it's buffered, and you're in sync with them in a quarter note sense but hearing what they did a bar earlier... So say it's in 4/4 time, everything will still sound okay, but to each user you're hearing what the other guy did a bar ago... make sense?
well, i'm not coding it, but i think a more free form approach [without barlines] is what i was imagining. also, network latency will not often match up with beats. if that kind of rhythmic precision is important, perhaps ChucK could do the quantizing itself.
i was thinking more or non metered music- collections of sounds. [ambient, "field recordings", and the like]
I had thought of that, Matt, but did not describe it in my post. I am sure the experts who are working on this have as well, and I think it is one of the excellent approaches to the delay issue. For my personal use, I'm thinking closer to John's approach, mainl because of the long delay that I am dealing with. The streaming delays seem to vary but typically are about 20 seconds in length, round trip. This is bad for simultaneity, but good for looping because in looping you generally want that kind of delay, 20 seconds or more. Yet a third approach might be if you generated music with ChucK and simply sent music commands over the web. Those could travel much faster than the audio signal so we get back to Matt's idea. Obviously there are many possibilities and they probably will exist in categories one day if not already! Les
My senior thesis focused on measuring/alleviating synchronization issues over local-area networks (like a laptop orchestra in the same room on a single router): http://lorknet.cs.princeton.edu/ and my junior paper (pdf hidden in here: http://www.markcerqueira.com/projects/jp/Final%20Report.pdf ) focused on similar issues of synchronization over networks. The background sections of those documents covers a lot on past projects regarding issues with live music performance over wide area networks and the issues with such undertakings. That said, it has been done. The GIGAPOP Ritual was a concert between McGill University in Canada and Princeton University in the US. There was also a concert the SoundWire group at Stanford put on between Stanford and Beijing that relied on setting the tempo of the piece to be the average round-trip time between the two locations. There is more stuff buried in those documents. Probably the most useful code I wrote out of there for your specific case would be TOSC (Timed OSC) code from my junior paper. It relies on the forward synchronization principal - you use the NTP code in there (it's crude) to synchronize everyone's notion of time and then schedule packets to be opened in the future rather than immediately. Jascha, a music graduate student at Princeton, has ported it over to SuperCollider too I believe! mc On May 18, 2011, at 4:09 AM, Les Hall wrote:
I'd like to address the topic of delay and synchronization during internet jams. I feel that the very approach of trying to accomplish audio synch in the current medium of audio over the internet is somewhat inappropriate. In a way it's kind of like trying to get flute sounds out of a guitar. Maybe it's possible, but it's really not in the nature of the beast.
To be sure there will come a day when the lag monster is largely defeated and we can jam with simultaneous artists, but that day is not today. I remember the frustration expressed by my fellow grad students whose simulators kept their workstations or even supercomputer accounts busy for long periods of time. I had no such problems as I had chosen to restrict my simulation constraints such that compute times were short. Looking back, this was appropriate as I was matching what I wanted to accomplish to what I had as a resource.
In a similar way, perhaps we should not be attempting to defeat the lag monster, but rather to create novel musical jamming techniques that operate within the timing constraints of the web. Now, that's easy for me to say and do because via the power of ChucK and my amateur musician status I can do just about whatever I want, and others may not have that luxury for various reasons. So please accept my apologies if you are limited in this way creatively beyond your control, however I do maintain that we should be doing what we can do, not what we want to do.
Back when I constrained my simulator complexity within the available compute constraints, I suffered the consequences of riling up anger and derision from those without that freedom or that choice. I hope that will not be the case with this message. Rather, I wonder if we can discuss ways to create music that fits the web rather than discuss programming that accomplishes synchronization over a web that denies it.
I welcome your comments on this topic and I apologize in advance if I have offended anyone. Just my two cents, eh?
Les
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On May 18, 2011, at 5:40 PM, Mark wrote:
There was also a concert the SoundWire group at Stanford put on between Stanford and Beijing that relied on setting the tempo of the piece to be the average round-trip time between the two locations.
That's awesome, exactly what I was hoping to learn! In this case the musicians have modified their music piece to accommodate the net delays, very interesting... Les
On Wed, May 18, 2011 at 3:03 PM, Les Hall
On May 18, 2011, at 5:40 PM, Mark wrote:
There was also a concert the SoundWire group at Stanford put on between Stanford and Beijing that relied on setting the tempo of the piece to be the average round-trip time between the two locations.
That's awesome, exactly what I was hoping to learn! In this case the musicians have modified their music piece to accommodate the net delays, very interesting...
it was a performance of "In C", if I remember correctly; ha, yes, it was: https://ccrma.stanford.edu/groups/soundwire/publications/papers/caceres-2008...
On 18 May 2011, at 13:09, Les Hall wrote:
I'd like to address the topic of delay and synchronization during internet jams. I feel that the very approach of trying to accomplish audio synch in the current medium of audio over the internet is somewhat inappropriate. In a way it's kind of like trying to get flute sounds out of a guitar. Maybe it's possible, but it's really not in the nature of the beast.
There is (or was) a system for musicians jamming together over the Internet with acoustic instruments. I think it works so that all data is sent to a central server which mixes it together and broadcasts it back to the musicians, which use headsets when playing. They experience a delay, but can learn to cope with it. Many musical instruments have a natural delay (like pipe organs), so this is just one variation. Hans
participants (6)
-
Hans Aberg
-
Joe McMahon
-
john saylor
-
Les Hall
-
Mark
-
Matt B.