Live Jamming

[Michael]

hello
does anyone know of a live jamming program over the internet?

thanks

[dt king]

"Michael" > wrote in message
om...
> hello
> does anyone know of a live jamming program over the internet?

Latency makes actual live jamming difficult. There was a subscription
service supporting realtime colaboration --Rocket something -- but they went
out of business. Some users split off with similar technology to try to
support it on their own; I haven't been keeping track of how they've done.

dtk

[Scott Dorsey]

dt king > wrote:
>"Michael" > wrote in message
om...
>> hello
>> does anyone know of a live jamming program over the internet?
>
>Latency makes actual live jamming difficult. There was a subscription
>service supporting realtime colaboration --Rocket something -- but they went
>out of business. Some users split off with similar technology to try to
>support it on their own; I haven't been keeping track of how they've done.

They started out as Res Rocket Surfer, then I think they became something
a bit more dignified sounding, like Rocketnet. They are definitely gone
now.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Michael]

do you mean latency in the hardware?

thanks

"dt king" > wrote in message news:<iGl3c.160071$4o.203248@attbi_s52>...
> "Michael" > wrote in message
> om...
> > hello
> > does anyone know of a live jamming program over the internet?
>
> Latency makes actual live jamming difficult. There was a subscription
> service supporting realtime colaboration --Rocket something -- but they went
> out of business. Some users split off with similar technology to try to
> support it on their own; I haven't been keeping track of how they've done.
>
> dtk

[Michael]

well, I'm planning on developing a live jamming software.. as for lag,
online gaming lives quite well with around 100ms.. but would 100ms be
too much for live jamming? Any suggestions would be greatly
appreciated.

thanks

"dt king" > wrote in message news:<iGl3c.160071$4o.203248@attbi_s52>...
> "Michael" > wrote in message
> om...
> > hello
> > does anyone know of a live jamming program over the internet?
>
> Latency makes actual live jamming difficult. There was a subscription
> service supporting realtime colaboration --Rocket something -- but they went
> out of business. Some users split off with similar technology to try to
> support it on their own; I haven't been keeping track of how they've done.
>
> dtk

[hank alrich]

Michael wrote:

> well, I'm planning on developing a live jamming software.. as for lag,
> online gaming lives quite well with around 100ms.. but would 100ms be
> too much for live jamming? Any suggestions would be greatly
> appreciated.

Does it bother you when someone misses the groove by a tenth of a
second?

--
ha

[Buster Mudd]

(hank alrich) wrote in message >...
> Michael wrote:
>
> > well, I'm planning on developing a live jamming software.. as for lag,
> > online gaming lives quite well with around 100ms.. but would 100ms be
> > too much for live jamming? Any suggestions would be greatly
> > appreciated.
>
> Does it bother you when someone misses the groove by a tenth of a
> second?


There's a 70ms delay between the back of the violin section & the bass
section at Carnegie Hall, no one seems to find that insurmountable.
The trick is to simply accept the fact that you may be in a "virtual
room" with these other Internet jam partners, but you are not in a
TINY "virtual room". Take advantage of latency: use antiphonal
compositions such as those by Ives, Stockhausen, or Braxton as your
inspiration, rather than the bland meandering jams of Phish (where the
latency occurs between a Good Idea and the fingers of the ****** who
already played something 100ms -- or 10 minutes -- earlier).

[Analogeezer]

(Michael) wrote in message >...
> well, I'm planning on developing a live jamming software.. as for lag,
> online gaming lives quite well with around 100ms.. but would 100ms be
> too much for live jamming? Any suggestions would be greatly
> appreciated.
>
> thanks
>
> "dt king" > wrote in message news:<iGl3c.160071$4o.203248@attbi_s52>...
> > "Michael" > wrote in message
> > om...
> > > hello
> > > does anyone know of a live jamming program over the internet?
> >
> > Latency makes actual live jamming difficult. There was a subscription
> > service supporting realtime colaboration --Rocket something -- but they went
> > out of business. Some users split off with similar technology to try to
> > support it on their own; I haven't been keeping track of how they've done.
> >
> > dtk

Nah 100 milliseconds is perfect, you get this cool slapback effect,
Elvis, Robert Plant, all the greats used it...

Analogeezer

p.s. Now an entire band, remotely located trying to play with 100 ms
of delay, that might be interesting...I bet it would sound like Sonic
Youth

[dt king]

"Buster Mudd" > wrote in message
om...

> There's a 70ms delay between the back of the violin section & the bass
> section at Carnegie Hall, no one seems to find that insurmountable.
> The trick is to simply accept the fact that you may be in a "virtual
> room" with these other Internet jam partners, but you are not in a
> TINY "virtual room". Take advantage of latency: use antiphonal
> compositions such as those by Ives, Stockhausen, or Braxton as your
> inspiration, rather than the bland meandering jams of Phish (where the
> latency occurs between a Good Idea and the fingers of the ****** who
> already played something 100ms -- or 10 minutes -- earlier).

Don't the musicians in Carnegie Hall usually have all of their parts written
out and a guy with a stick telling them exactly when to play?

What CDs of live jams at Carnegie do you recommend?

dtk

[Mike Rivers]

In article > writes:

> There's a 70ms delay between the back of the violin section & the bass
> section at Carnegie Hall, no one seems to find that insurmountable.

That's because there's a conductor, and the basses aren't getting
their timing by listening to the violins. Just try delaying your
headphone feed by 70 ms and doing an overdub and you'll see where the
problem lies. You'll think you're playing fine, but the result will
suck.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

[Arny Krueger]

"Mike Rivers" > wrote in message
news:znr1078952422k@trad

> In article >
> writes:

>> There's a 70ms delay between the back of the violin section & the
>> bass section at Carnegie Hall, no one seems to find that
>> insurmountable.

> That's because there's a conductor, and the basses aren't getting
> their timing by listening to the violins. Just try delaying your
> headphone feed by 70 ms and doing an overdub and you'll see where the
> problem lies. You'll think you're playing fine, but the result will
> suck.

I don't know which multitracking packages allow you to make small
adjustments in the timing of a block. With Audition, you just subtract
however many milliseconds you like from the start time of the block, type in
the result, and the delay due to latency simply goes away.

Of course this isn't a solution for live jamming but it could solve problems
with a recording of a jam with various amounts of latency.

[Scott Dorsey]

In article <lDL3c.225$zS4.455@attbi_s51>, dt king > wrote:
>"Buster Mudd" > wrote in message
om...
>
>> There's a 70ms delay between the back of the violin section & the bass
>> section at Carnegie Hall, no one seems to find that insurmountable.
>> The trick is to simply accept the fact that you may be in a "virtual
>> room" with these other Internet jam partners, but you are not in a
>> TINY "virtual room". Take advantage of latency: use antiphonal
>> compositions such as those by Ives, Stockhausen, or Braxton as your
>> inspiration, rather than the bland meandering jams of Phish (where the
>> latency occurs between a Good Idea and the fingers of the ****** who
>> already played something 100ms -- or 10 minutes -- earlier).
>
>Don't the musicians in Carnegie Hall usually have all of their parts written
>out and a guy with a stick telling them exactly when to play?

Some of them... and the reason that exists is because of natural hall
latency. A visual conductor can also be a big help in a lot of situation
where you have to deal with such things, such as groups playing on a large
film soundstage.

>What CDs of live jams at Carnegie do you recommend?

Absolutely run down and buy the Benny Goodman at Carnegie Hall concert.
Nothing short of amazing, in spite of the poor sound quality. Also do
not forget Calypso At Midnight, with an amazingly whitebread-sounding
Alan Lomax introducing some top notch calypso groups at Carnegie Hall,
The Weavers at Carnegie Hall (okay, not much jamming on that one), and
the absolutely hilarious first Carnegie Hall album from Harry Belafonte.
You can tell Harry is having a really good time. The second one he did
is very watered down and isn't worth the trouble.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[hank alrich]

Scott Dorsey wrote:

> Absolutely run down and buy the Benny Goodman at Carnegie Hall concert.
> Nothing short of amazing, in spite of the poor sound quality.

And, man, that is one of my worst sounding CD's, and I'm thinking it
ain't the medium's fault. (Better dub it off to a Studer and make an LP
of it...)

--
ha

[Roger W. Norman]

> Nah 100 milliseconds is perfect, you get this cool slapback effect,
> Elvis, Robert Plant, all the greats used it...
>
> Analogeezer
>
> p.s. Now an entire band, remotely located trying to play with 100 ms
> of delay, that might be interesting...I bet it would sound like Sonic
> Youth

If Sonic Youth is how you spell ****.

--


Roger W. Norman
SirMusic Studio

"Analogeezer" > wrote in message
om...
> (Michael) wrote in message
>...
> > well, I'm planning on developing a live jamming software.. as for lag,
> > online gaming lives quite well with around 100ms.. but would 100ms be
> > too much for live jamming? Any suggestions would be greatly
> > appreciated.
> >
> > thanks
> >
> > "dt king" > wrote in message
news:<iGl3c.160071$4o.203248@attbi_s52>...
> > > "Michael" > wrote in message
> > > om...
> > > > hello
> > > > does anyone know of a live jamming program over the internet?
> > >
> > > Latency makes actual live jamming difficult. There was a subscription
> > > service supporting realtime colaboration --Rocket something -- but
they went
> > > out of business. Some users split off with similar technology to try
to
> > > support it on their own; I haven't been keeping track of how they've
done.
> > >
> > > dtk
>

[Buster Mudd]

(Mike Rivers) wrote in message news:<znr1078952422k@trad>...
> In article > writes:
>
> > There's a 70ms delay between the back of the violin section & the bass
> > section at Carnegie Hall, no one seems to find that insurmountable.
>
> That's because there's a conductor, and the basses aren't getting
> their timing by listening to the violins. Just try delaying your
> headphone feed by 70 ms and doing an overdub and you'll see where the
> problem lies. You'll think you're playing fine, but the result will
> suck.


See, you're still stuck in that Jamming = Two Hippies Parked Around A
Campfire model. If the two hippies were sitting around a campfire that
was 100 feet in diameter, will they think they're playing fine? Will
their results "suck" ? Will it kill their buzz? Internet jamming
*requires* a new paradigm, and that includes expanding one's
references and definitions of seemingly obvious concepts such as
"playing together".

Incidentally, if you talk to most symphonic musicians -- especially
New York City members of Local 802 -- they'll tell you they don't get
their timing information from the conductor either. They primarily get
their dynamics information from the conductor; timing comes from their
sense of "ensemble".

[dt king]

"Buster Mudd" > wrote in message
om...
> (Mike Rivers) wrote in message
news:<znr1078952422k@trad>...
> > In article >
writes:
> >
> See, you're still stuck in that Jamming = Two Hippies Parked Around A
> Campfire model. If the two hippies were sitting around a campfire that
> was 100 feet in diameter, will they think they're playing fine? Will
> their results "suck" ? Will it kill their buzz? Internet jamming
> *requires* a new paradigm, and that includes expanding one's
> references and definitions of seemingly obvious concepts such as
> "playing together".

Internet audio has been available for years. For some reason, muscians who
leap to new paradigms have failed to make online jams flourish. I recently
revisited Yahoo chat rooms to check out the state of the art. I've yet to
see an actual conversation succeed over the bickering about mic etiquette
and people who still have not managed to get their audio working right.
You'd think, by now, people would have gotten the hang of it.

I believe that as broadband flourishes and technology improves online jams
will eventually catch on -- when ping times are commonly below 20ms. It's a
little sad though. Sitting alone in your room playing through a wire is a
pale substitute for actually gathering with other musicians and spectators
in a social environment.

dtk

[Scott Dorsey]

hank alrich > wrote:
>Scott Dorsey wrote:
>
>> Absolutely run down and buy the Benny Goodman at Carnegie Hall concert.
>> Nothing short of amazing, in spite of the poor sound quality.
>
>And, man, that is one of my worst sounding CD's, and I'm thinking it
>ain't the medium's fault. (Better dub it off to a Studer and make an LP
>of it...)

Well, it started out life as an Altec on the stage, going into a Presto
disc cutter with a cold stylus. And then those transcription discs were
played a lot and worn down pretty badly before anyone considered issuing
them on an LP. The recording was never intended to be actually released.

I have the original LP issue, which sounds really bad. But the band is
really, really good. It's worth the price of admission just for Sing, Sing,
Sing which is extended much longer than the usual disc version.

Incidentally, the rather crude recording system was similar to the one
used on the Calypso at Midnight recording, but the discs were treated a
lot more poorly. Calypso at Midnight has some weird things going on in the
lower midrange and some noise, but it sounds amazingly better than the
Goodman recording.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Mike Rivers]

In article > writes:

> See, you're still stuck in that Jamming = Two Hippies Parked Around A
> Campfire model. If the two hippies were sitting around a campfire that
> was 100 feet in diameter, will they think they're playing fine? Will
> their results "suck" ? Will it kill their buzz?

They'll proably be toasting marshmallows or drinking beer rather than
jamming. Jamming is a real-time, person-to-person experience. If I'm
in a jam session and the "circle" gets too big, I look for another
session. If I can't hear anyone but myself and a couple of people near
me, it isn't jamming, and if I can't hear myself at all, it isn't even
fun playing.

I think that putting microphones and earphones on everyone and having
someone mix it would be too much like a recording session. Do that,
but have the mixer insert random delays in each soruce and you have a
simulated Internet jam.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

[dafe]

(hank alrich) wrote in message >...
> Michael wrote:
>
> > well, I'm planning on developing a live jamming software.. as for lag,
> > online gaming lives quite well with around 100ms.. but would 100ms be
> > too much for live jamming? Any suggestions would be greatly
> > appreciated.
>
> Does it bother you when someone misses the groove by a tenth of a
> second?
...nice shot.
Oh, let's see..for doing dylan original covers, the slow ones, or, no,
better the loureed stuff, it might add a not so unfunny authentic
flavor iMho. I'm open for better suggestions, still.

dafe

[Ryan]

I've been interested in this type of thing for a long time. But have
never seen anything online about it, and I don't even have a midi
keyboard right now anyway. Just to clarify, we are talking about midi
here, and not actual audio, right? I'm sure we have to be talking
about midi, but no one has actually said that.

"dt king" > wrote:
> It's a
> little sad though. Sitting alone in your room playing through a wire is a
> pale substitute for actually gathering with other musicians and spectators
> in a social environment.
>
> dtk

Well, I would say that sitting alone in your room watching TV is a
pale substitute for sitting alone in your room playing music with
other real live people, despite the location of their physical bodies.
I think of this for eductaional purposes. If you want to learn how
to play a little cuban music, find a cuban music "room," etc.. Or how
about finding out what the cutting edge in Cairo is all about? Or
Beijing? And what about those of us who want to jam with old friends
and teachers from college, who now live on the opposite coast? This
is certainly cheaper than buying a weekly plane ticket. Even with the
latency problem, I can't think of a better tool for musical practice
and education. Bring it on Michael!

[Jay Kadis]

We have been experimenting with long-distance sessions using the new high-speed
internet backbone available to universities. We managed a two-way audio/video
jam between Stanford and McGill University with latencies of 100+ msec. The
video was quite slow, but the audio was within the playable range. Since it was
a very loose jam, the latency was not as annoying as I expected. (I've
experienced such latencies with local intoxicated players, but that's another
story...)

There is of course a minimum latency based on the transmission time involved, in
this case Stanford California to Montreal Canada. Nevertheless, with lots of
fiddling with the computer we got usable latencies. I don't think this will
work as well without the high-speed backbone and heavily optimized computers,
but eventually these issues may be resolved for everyone.

I still prefer live, local interactions but this stuff is intriguing.

-Jay
--
x------- Jay Kadis ------- x---- Jay's Attic Studio ------x
x Lecturer, Audio Engineer x Dexter Records x
x CCRMA, Stanford University x http://www.offbeats.com/ x
x-------- http://ccrma-www.stanford.edu/~jay/ ----------x

[Michael]

Hi,
I'm planning on doing it via MIDI, and output via sample cds.. any
comments or suggestions?

thanks
Michael
(Michael) wrote in message >...
> well, I'm planning on developing a live jamming software.. as for lag,
> online gaming lives quite well with around 100ms.. but would 100ms be
> too much for live jamming? Any suggestions would be greatly
> appreciated.
>
> thanks
>
> "dt king" > wrote in message news:<iGl3c.160071$4o.203248@attbi_s52>...
> > "Michael" > wrote in message
> > om...
> > > hello
> > > does anyone know of a live jamming program over the internet?
> >
> > Latency makes actual live jamming difficult. There was a subscription
> > service supporting realtime colaboration --Rocket something -- but they went
> > out of business. Some users split off with similar technology to try to
> > support it on their own; I haven't been keeping track of how they've done.
> >
> > dtk

[ryanm]

"Michael" > wrote in message
om...
> well, I'm planning on developing a live jamming software.. as for lag,
> online gaming lives quite well with around 100ms.. but would 100ms be
> too much for live jamming? Any suggestions would be greatly
> appreciated.
>
Heh... the games you speak of have seriously optimized packets that go
between the synching server and the clients on either a scheduled basis or
only as needed. Those games also make heavy use of latency-correction
methods, which are very arbitrary. For example, in a FPS game, they will
often hard-code the rule that if a player is in your crosshairs on your
client when you pull the trigger, it's considered a hit regardless of that
player's position on their client. This is the cause of those annoying times
in those games where you are easily clear of someone's line of fire and you
are suddenly, inexplicably "pulled back" out into the open and hit by
someone you didn't even see. This works because the bottom line in those
games is playability, not realism. For live jamming, "realism" (accurate
timing) is a lot more important.

We're talking about 100ms delay with packets consisting of 10 or 20
bytes of data (and often less). A wave (or aiff) file is about 24k per
second at 8 bit/22,050 in mono. That's 24 *thousand* bytes of data, compared
to 10 or 20 bytes. So that would be somewhere around a 1/4 second (250 ms)
delay per track, absolute minimum. Bring the quality up to 16/44.1, still
mono, and we're talking about 88k of audio data, which would bump the
latency up way past usable. Especially considering that you would have to be
streaming in both directions in order for it to work, both from the client
input to the server, and from the server's summed output to the client. And
that's just on the client side, let's say there are 4 clients connected, the
server would have to receive all of 4 streams from those clients, sum them,
and then stream back to all 4 clients the summed output. The server would
have to have massive, latency free bandwidth to handle it, plus it would
have to have enough processing power and ram to handle both the multiple
streaming processes *and* the summing process without any latency.

I'm afraid that it's simply not feasible at this time. It's a great
idea, and it's been tried before, but right now the high-speed bandwidth
that it would require just isn't widely available enough. Also, it would
*have* to be a pay service, because the cost of maintaining the server would
be considerable. We're still a decade away from that sort of bandwidth being
widespread enough, and even further from realistically being able to do a
peer-to-peer version.

That being said, if you get something to beta I'd be happy to help you
test it. It would rule if it could be done, but I'm not holding my breath.

ryanm

[dt king]

"ryanm" > wrote in message
...
> "Michael" > wrote in message
> om...
> > well, I'm planning on developing a live jamming software.. as for lag,
> > online gaming lives quite well with around 100ms.. but would 100ms be
> > too much for live jamming? Any suggestions would be greatly
> > appreciated.
> >
....
> I'm afraid that it's simply not feasible at this time. It's a great
> idea, and it's been tried before, but right now the high-speed bandwidth
> that it would require just isn't widely available enough. Also, it would
> *have* to be a pay service, because the cost of maintaining the server
would
> be considerable. We're still a decade away from that sort of bandwidth
being
> widespread enough, and even further from realistically being able to do a
> peer-to-peer version.

It could kind of work if the clients looped over the same eight or twelve
bars and added contributions as they became available. You might be playing
with a riff that somebody added 20 seconds ago and they'd respond with an
entirely different lick when you release your contribution and it reaches
their client. The server would tally up the resulting variations as fixed
loops that could later be remixed into a final release.

I think a midi version would be better if it included a softsynth engine, so
every heard the same midi implementation in the client. Midi would also
update a lot faster and make it feel more like a live jam, but you wouldn't
get many guitar players involved.

dtk

[ryanm]

"dt king" > wrote in message
news:LG36c.31052$KO3.81431@attbi_s02...
>
> It could kind of work if the clients looped over the same eight or twelve
> bars and added contributions as they became available. You might be
playing
> with a riff that somebody added 20 seconds ago and they'd respond with an
> entirely different lick when you release your contribution and it reaches
> their client. The server would tally up the resulting variations as fixed
> loops that could later be remixed into a final release.
>
That would be more of a "collaborating sequencer" or something like that
then, rather than a "live jamming" app. That would be *more* feasable, but
still not even approaching real-time collaboration over the internet.

> I think a midi version would be better if it included a softsynth engine,
so
> every heard the same midi implementation in the client. Midi would also
> update a lot faster and make it feel more like a live jam, but you
wouldn't
> get many guitar players involved.
>
See, you go to midi and you've lost my attention. The synths and
libraries vary so much that it would have to be included in the engine, and
then we're just talking about an *almost* real-time collaboration sequencer,
which doesn't interest me.

Something that *is* feasible now, however, is a long-distance
collaboration app for recording. The basic workflow would be something like
one guy records a rhythm guitar track, as a reference, which is synchronized
(uploaded) to all of the collaborators. The collaborators each play back the
initial track while recording their additional tracks. When they click
"Synchronize", those tracks are uploaded to all of the other collaborators.
Then when they click "record", it plays back the sum of all of the added
tracks. It would have to essentially work like any multi-track recording
app, only with a synchronize button or something that would cause you to
download all of the available tracks from each of the collaborators.
Collaborators could have roles, such as "musician", "engineer", etc, so that
the musicians would be capable of only listening to the total mix and
recording one or more tracks at a time, while the engineer can't record any
tracks, but can see all of the tracks and modify volume, pan, or effects
envelopes, and make other adjustments to the music on a track-by-track or
whole song basis. It could be done either as a client/server app or as a
peer-to-peer app with the "engineer" role being the central location for the
track source. Obviously, I didn't spend any time thinking about the
implications of this, I was just throwing ideas out, so there may be massive
pitfalls for an app like that as well, but the thing that I believe makes is
feasible is that it's not dependant on everyone being "there" at the same
time.

ryanm

[Mike Rivers]

In article > writes:

> A wave (or aiff) file is about 24k per
> second at 8 bit/22,050 in mono. That's 24 *thousand* bytes of data, compared
> to 10 or 20 bytes. So that would be somewhere around a 1/4 second (250 ms)
> delay per track, absolute minimum. Bring the quality up to 16/44.1, still
> mono, and we're talking about 88k of audio data, which would bump the
> latency up way past usable. Especially considering that you would have to be
> streaming in both directions in order for it to work, both from the client
> input to the server, and from the server's summed output to the client.

> I'm afraid that it's simply not feasible at this time. It's a great
> idea, and it's been tried before, but right now the high-speed bandwidth
> that it would require just isn't widely available enough.

If the delay was predictable and consistent, you could probalby line
up all the incoming sources at your end (by delaying each one so they
all got in sync) but I can see them wandering all over the place as
conditions on the net change.

I recall the high priced novelty of doing overdubs remotely when 56K ADSL
first became avaiable. Rather than send the tape across the country,
they'd feed a reference mix over an analog phone line, then send the
overdub digitally back, lining the monitoring up with delays at the
remote end. It cost a hundred bucks an hour just for the data line
back then, but it saved money when someone wanted a famous artist who
was in LA to play on a NY session. The cost of two studios plus the
data transmission was substantially lower than flying (first class of
course) across country, staying in a nice hotel to rest up before the
session, and then popping in for fifteen minutes to do his thing.

Ah, those were the days of REAL studio budgets.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

[ryanm]

"Mike Rivers" > wrote in message
news:znr1079567016k@trad...
>
> If the delay was predictable and consistent, you could probalby line
> up all the incoming sources at your end (by delaying each one so they
> all got in sync) but I can see them wandering all over the place as
> conditions on the net change.
>
Yeah, it would be all over the place as network traffic varied. And then
the question is, without real-time feedback from the other musicians, is it
really "jamming"? To me, that's the underlying connotation of "jamming". A
handful of musicians hanging out, improvising, and feeding off of one
another for the groove.

ryanm

[Mike Rivers]

In article > writes:

> Yeah, it would be all over the place as network traffic varied. And then
> the question is, without real-time feedback from the other musicians, is it
> really "jamming"?

No, not really. It would be playing along with other musicians who
were playing along with other musicians, more in a chain than in a
single group.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

[Scott Dorsey]

ryanm > wrote:
>"Mike Rivers" > wrote in message
>news:znr1079567016k@trad...
>>
>> If the delay was predictable and consistent, you could probalby line
>> up all the incoming sources at your end (by delaying each one so they
>> all got in sync) but I can see them wandering all over the place as
>> conditions on the net change.
>>
> Yeah, it would be all over the place as network traffic varied. And then
>the question is, without real-time feedback from the other musicians, is it
>really "jamming"? To me, that's the underlying connotation of "jamming". A
>handful of musicians hanging out, improvising, and feeding off of one
>another for the groove.

Well, you know, after the person made the comment about jamming in Carnegie
Hall, I got to think about how big bands jam. And they don't really jam
together, in part because of the latency and because the musicians can't
always hear one another. In a big band arrangement you'll sometimes see
a section blocked off that just says "bass solo" and then another one a
little bit that says "first horn solo." Everyone is playing a prewritten
arrangement, but everyone also gets a chance to solo now and then. And
if they could hear the last guy solo, they can improvise on it. And if
they couldn't hear the last guy solo because he's on the other side of
the band and the drummer is in the way, they can play something different.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."