COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 09-18-2009, 09:10 PM   #1
phNord
Human being with feelings
 
Join Date: Jul 2005
Location: Boston
Posts: 22
Default "Leader Mode"

Hey guys,

I think a great feature to enable would be a "leader status" that could be appointed to someone in the jam. The result of this would be their interval time would be set to half of everyone else's.

Basically, the architecture would look like this:
- Everyone streams their sound to the Ninjam server, as normal
- The leader gets streamed from the server to everyone else with a 1/2 bpi delay
- Everyone else gets streamed from the server to the leader with a 1/2 bpi delay
- Everyone else gets streamed from the server to each other with a full bpi delay, as normal

This basically has the effect of cutting the delay in half between the leader and everyone else, while still keeping everyone synced up in the interval. Here are a few scenarios where this could be helpful:

Starting a jam: If the leader starts a jam, everyone else will only have to wait half the time to hear them ( 30 * bpi/bpm seconds as opposed to 60 * bpi/bpm seconds)

Propagation of changes by the leader: Normally if someone changes the beat for instance, the change takes two full intervals to fully propagate. For instance, say I was playing a 12-bar blues at 120 bpm - so an interval of 4*12 or 48 beats. If I was the bassist and I changed the beat to a shuffle, the drummer would not hear that change until the next form and I would not hear the drummer playing a shuffle beat until two forms from when I started it - about half a minute later.

However, if I were the leader, the drummer would hear that I had started a shuffle while I was still finishing the first form, and I would hear him playing the shuffle along with me the very next form - around 15 seconds later.

Reinforcement of changes by the leader: Let's take that previous example and have the drummer start the shuffle beat instead of the me. I would hear him playing the shuffle during the initial form in which he beings it, and could play along with it. Then when it hits everyone else, they hear both the bass and drums as a shuffle as opposed to just the drums.

Unfortunately, there can only be one leader set at a given time. I would propose that the leader can be voted for in the chat in the same way one votes for the bpi or the bpm.

I'd love to implement this myself, but I really don't think I have the coding know-how to do so or the time to learn at the moment. But if someone wanted to take it upon themselves to develop this feature, I would very much appreciate it!

Thanks,

Phnord
phNord is offline   Reply With Quote
Old 09-20-2009, 07:04 PM   #2
AndyMc
Human being with feelings
 
AndyMc's Avatar
 
Join Date: Dec 2006
Posts: 441
Default

Shortening down the Length of the BPI sent wouldn't make it any quicker.
The whole way it works will always leave someone getting it a interval after the rest.
It's like a cascading loop that's being confined within parameters.

I think with about 80% certainty that its a bit like first connected first served basis, so if you wanted a leaded you would receive from first you could all reconnect except them but I still think for some it wouldn't make a difference.

TBH it works pretty good as it is and I don't see how making shorter time till sends would make it better, it would only cause more disconnects.
But it would be nice to have some extra vote options or an update to the standalone to include single channel stereo like in ReaNINJAM and similar FX gui to REAPER's.

EDIT:
Sorry if I sounded rude there, I didn't mean to be.
__________________
Latest Shit (looking for singers): http://www.soundcloud.com/AndyMcProducer
Twitter (@AndyMcProducer): http://www.twitter.com/AndyMcProducer
Facebook Page: http://www.facebook.com/AndyMcProducer

Last edited by AndyMc; 09-20-2009 at 07:06 PM.
AndyMc is offline   Reply With Quote
Old 09-20-2009, 07:59 PM   #3
phNord
Human being with feelings
 
Join Date: Jul 2005
Location: Boston
Posts: 22
Default

AndyMc: I'm afraid you're not following what I wrote carefully enough, nor have an understanding of exactly what is going on regarding delays and what you hear / what other people hear in NINJAM. I'm going to draw it out here a little better.

Let's say you had a song where the chord progression (aka the form of the song) was as follows:

Code:
| C  | Am  | F  | G  | Am  | Dm  | E7  | F  |
The song is in 4/4, at a tempo of 120 bpm. That means a full chord progression takes a total of 32 beats, at 120 bpm.

The goal when you play a song in NINJAM is for everyone to lineup in the same place of the form of the song. NINJAM does this by delaying what you play by a certain number of beats at the bpm specified so that everyone ends up at the same place within the interval, albeit the same place in a different interval.

As an example, lets say you were jamming the following chord progression:

| Gm | C |

In 4/4 at 120bpm, that would need a bpm 120 and a bpi of 8 to line everyone up. If the bassist started that off, then the time-line looks like this:

Code:
      (A)       (B)       (C)
BEATS |....|....|....|....|....|....|
Bass: | Gm | C  | Gm | C  | Gm | C  |
Guit: |    |    | Gm | C  | Gm | C  |
Drum: |    |    | Gm | C  | Gm | C  |
At point A, the bass starts playing. At point B, the guitarist and drummer hear the bass playing and join in. At point C, the bassist can hear everyone else is playing, which syncs up with his third time through the form.

Now lets take a song with a longer form - for instance, a funk song with this 8 measure chord progression:

Code:
      (A)                                     (B)                                     (C)
BEATS |....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....| ...
Bass: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
Guit: |    |    |    |    |    |    |    |    | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
Drum: |    |    |    |    |    |    |    |    | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
As you can see, since it is 8 measures long, the bpi must be 32 now. That's a pretty long time after the bassist starts the music before the guitarist and drummer hear him playing, and double that time until he can hear them / they can hear each other at C. For the bassist, there are 16 full measures of music before he even hears anyone playing along with him.

Additionally, say the jam was already going on, and the drummer wanted to change the beat to a jazz beat:

Code:
           (A)                                     (B)                                     (C)
BEATS |....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....| ...
Bass: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
Guit: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
Drum: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
The drummer makes the change at point A. The bassist and guitarist could not hear the change until point B. Even more upsetting, the drummer wouldn't hear them playing along with the shuffle until point C - he would be stuck playing a jazz beat against a funk bass and guitar in his speakers from point A until point C!


What I propose we do is modify the server script very slightly. Right now, the server works like this:
- It receives audio from everyone slightly after they play it (w/up to .5 seconds latency)
- It streams the audio to the people who didn't play it with instructions to their client programs to delay it's play time to one full interval after it was originally recorded

I suggest that we allow one person to be designated a "leader," and for the server to function as follows:
- It receives audio from everyone slightly after they play it (a few milliseconds)
- It sends audio from the "leader" out to everyone else's client programs with instructions for it to be played 1/2 interval after it was originally recorded
- It sends audio from the everyone else to the leader's client program with instructions for it to be played 1/2 interval after it was originally recorded
- It sends audio from everyone who is not a leader to everyone else who is not a leader with instructions to delay it's play time to one full interval after it was originally recorded

Lets say the bass was the leader. This would result in something that looks like this:

Code:
      (A)                 (B)                 (C)                 (D)
BEATS |....|....|....|....|....|....|....|....|....|....|....|....|....|....| ...
Bass: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | ...
Guit: |    |    |    |    | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
Drum: |    |    |    |    | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
At point A, the bassist begins playing. At point B, the guitarist and drummer hear the bassist and drummer begin playing, and start playing along. At point C, the bassist hears what the drummer and guitarist are playing, which syncs up with his second time through the form. Finally, at point D the guitarist and drummer hear start hearing what each other played at point B (which syncs up with what the bassist played at point C - his second time through the form as perviously mentioned).

Now lets say that the drummer wanted to make that change to the jazz feel:

Code:
           (A)                  (B)                (C)                 (D)                 (E)
BEATS |....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....| ...
Bass: | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | ...
Guit: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
Drum: | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | F  | G  | Am | Dm | E7 | F  | C  | Am | ...
At point A, the drummer makes the change. At point B, the bassist hears the change and starts playing along with the jazz feel. At pint C, the guitarist hears both the bassist and drummer playing the jazz feel and starts to play along. Also at point C, the drummer hears the bassist playing along with his jazz feel. At point D, the bassist will hear everyone (including the guitarist) playing the jazz feel as well, and at point E the drummer hears everyone playing the jazz feel he started.

--------

The end result of all of this is basically:
- The leader can hear changes made by others in half the amount of time as normal
- Everyone else can hear changes made by the leader in half the amount of time as normal
- Everyone stays synced up to the correct point in the form with each other

In regard to the issue of the people "dropping out," that isn't something that should be a concern here. Leader mode is intended for songs with long forms (aka hi bpi), so that people can play them without having to wait multiple forms for changes propagate and songs to start. For the network (bandwidth / ping time) side of things, the requirements are the same as if everyone had the bpi of the song set to 1/2 - for instance if you were playing a 32 bpi song, the participants would have to have connections that could handle the same song at 16 bpi.

Last edited by phNord; 09-21-2009 at 12:19 AM. Reason: cleared up some phrasing
phNord is offline   Reply With Quote
Old 09-20-2009, 11:51 PM   #4
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 767
Default

Quote:
What I propose we do is modify the server script very slightly. Right now, the server works like this:
- It receives audio from everyone slightly after they play it (a few milliseconds)
- It sends the audio to the people who didn't play it with instructions to their client programs to play it one full bpi after it was originally played
From what I was told, the above isn't quite true. "a few milliseconds" can be over half a second. And "to play it one full bpi after it was originally played" is actually "to play it at the start of the next interval". It's far more chaotic than you present .

Other than that, I like it.
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.

Last edited by pljones; 09-20-2009 at 11:54 PM.
pljones is offline   Reply With Quote
Old 09-21-2009, 12:13 AM   #5
phNord
Human being with feelings
 
Join Date: Jul 2005
Location: Boston
Posts: 22
Default

Quote:
Originally Posted by pljones View Post
From what I was told, the above isn't quite true. "a few milliseconds" can be over half a second. And "to play it one full bpi after it was originally played" is actually "to play it at the start of the next interval". It's far more chaotic than you present .

Other than that, I like it.
I did mean "to play it at the start of the next interval." I'll change the wording so it's a little less confusing.

I do believe, however, that the way the NINJAM server works *is* in fact to stream the incoming audio from one person out to all others with their programs scheduled to play them one interval after they were performed. To quote the NINJAM website's front page on the matter:

Quote:
Just as the interval finishes recording, it begins playing on everyone else's client. So when you play through an interval, you're playing along with the previous interval of everybody else, and they're playing along with your previous interval.
And even if the latency from performer-to-server and server-to-others is a full second each, that's a total of 2 seconds of latency. This means that the leader system should theoretically work as long as the interval is at the very least double that - 4 seconds, or 8 bpi (without taking non-latency related issues, such as bandwidth, into account).

Since again, this system is aimed at reducing reaction times for songs with large bpi, that is not an issue that should complicate things. I was in a jam this morning with some people playing the jazz ballad Misty. It's a slow tempo - 40 bpm, and in order to encompass the full 32-measure form it requires 128 beats. That meant that when I played a note, no-one else heard it for over 3 minutes, and I didn't hear their response until 6-and-a-half minutes after I played the note! The goal is to prevent those kinds of situations as much as possible while allowing people to play songs that are more complicated than an 4-bar jam.
phNord is offline   Reply With Quote
Old 09-21-2009, 09:52 AM   #6
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 767
Default

Sheesh, that's some staying power to keep the feel going.

I think the web page provides a "best case" example but I may have misinterpreted something Justin mentioned. (I won't even try to dig out the forum post..! )

For the times it's most needed, it shouldn't be an issue anyway.

Now we just need Brendan and Justin to decide to implement it .
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 09-29-2009, 07:39 PM   #7
AndyMc
Human being with feelings
 
AndyMc's Avatar
 
Join Date: Dec 2006
Posts: 441
Default

If someone connects late, say 2 bar after clients are are receiving or hearing the leader, then they wait the normal gap of bpi till its end to receive audio from the leader, and say this is from start of progression how does it work from that point?
Do they recieve audio from the leader, then wait another full bpi for others, or forgo 1 whole bpi then recieve the leader then forgo another whole bpi with just leader before recieving all.
If forgoing 1 whole bpi on top of remaining bpi from time connecting, to create whole sync and bpi is say 32 or 64, would this be a long gap before audio?
Or would the server calculate who's where, send you leader more current and others more late, would this then cause a problem of getting data to a client quicker than the latency?

I do totally understand what you mean and see the benefits to some degree, but I can also see the problems that could come from it too.
It sort of has a taint of ejamming.


I guess I'm thinking, would there be a big enough benefit for the work needed and possible updating to repair problems.
If there was time to make these changes would ninjam standalone or reaninjam not have already received many updates which some that have been mentioned have been very wanted by the people who use it.

Having a shorter time like I said before won't make a difference, no one would be truly sync'd, when the progression keys changed it would still leave a mess.

What your explain is sort of what it is now but you suggest all hearing 1 person together then all their audio passing back out and being swapped for the next interval.
I don't know if NINJAM staggers or streams constant, I guess it could stagger out the data to all, this would reduce bandwidth needed to run a server by queuing all in a precise manor. But if it does this already then to possibly achieve everything in time before latency then becomes an issue it could increase the amount of bandwidth a server needs to host people.
This could also then increase the bandwidth needed on a client too. NINJAM get away with so much by being able to delay audio lazily and throw it to users in this way.
If anything I'd suggest people were pinged and if on high ping they were captured in a doubled bpi and sent to maybe in double if there ping is that high. This would keep them connected maybe when they have bad latency to a server.

But maybe I'm wrong about it all and am missing something, it seems to work fine now, you can't do cover songs but it just allows people to become better musicians instead of presets.
I suppose its very similar to data input and computer programmer.
I'm not saying what ya suggesting wouldn't work and there is maybe someone who could get it working too.

But on a serious note, at one point you mention pint C, can I have one of them please
I'm so thirsty at the mo. ;P
__________________
Latest Shit (looking for singers): http://www.soundcloud.com/AndyMcProducer
Twitter (@AndyMcProducer): http://www.twitter.com/AndyMcProducer
Facebook Page: http://www.facebook.com/AndyMcProducer
AndyMc is offline   Reply With Quote
Old 10-25-2010, 08:39 AM   #8
Sound asleep
Human being with feelings
 
Sound asleep's Avatar
 
Join Date: Nov 2009
Location: Montreal, Canada
Posts: 9,048
Default

I think for me something like ninjam will never be practicable until they figure out how to send information faster than the speed of light. or at the speed of light and i'm not too far from the other people in my session.

these sorts of delays are so huge. like in the first post talking from like a minute delay to 15 vsecond or whatever? omg, that's so huge. i could almost play every instrument with a delay like that kind of thing.
Sound asleep is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 07:09 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.