COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 04-25-2006, 07:16 PM   #1
johnny
Human being with feelings
 
Join Date: Apr 2006
Location: Serbia and Montenegro
Posts: 7
Default Great idea

Hi everyone,

I am dreaming about a program like this for a long time. And today I found it!
That's it, the solution for compensating 100ms+ latency - make latency even longer - just as long as one measure. Great idea, although it somehow alters the idea of jamming, but it also seems to be fun.

Well, besides the fact I'm astonished by this program , I'm also a programming student, and happened to find this app just because it is listed among Google Summer of Code projects. I am interested to take part in some programming here, with or without Google's help. I'm pretty sure I can make a Linux frontend in Qt, also have some ideas... anyway I downloaded source code and I'm going to analyze it in the next few days...

And I have to ask a question: why server doesn't mix the channels altogether and send them to a client (with or without client's channel mixed) instead of this client-side mixing? Of course, it presumes some application upgrades (already proposed: voting sistem or/and room moderator, probably with some producer options), but will greatly improve network-related performance. Is there some point I missed, because it seems like a very logical approach, and yet is not implemented?
Server too busy with mixing processes? Don't think so...

Greetings
Nikola

Last edited by johnny; 04-25-2006 at 07:19 PM. Reason: test
johnny is offline   Reply With Quote
Old 04-25-2006, 09:23 PM   #2
tanstaafl
Human being with feelings
 
Join Date: Apr 2006
Posts: 3
Default

Quote:
Originally Posted by johnny
Hi everyone,
Hi Nikola!

Quote:
Originally Posted by johnny
Well, besides the fact I'm astonished by this program , I'm also a programming student, and happened to find this app just because it is listed among Google Summer of Code projects. I am interested to take part in some programming here, with or without Google's help. I'm pretty sure I can make a Linux frontend in Qt, also have some ideas... anyway I downloaded source code and I'm going to analyze it in the next few days...
Hehe, just like you I was planning on submitting a couple of proposals to Google Summer of Code. I guess that make us competitors . I too think that a Qt-frontend would be a good thing to have. Not only so that Linux can have a real frontend (instead of the ncurses-based), but it could also be used to deprecate the other frontends so that there's only need for one source instead of one per platform...

Quote:
Originally Posted by Jonny
And I have to ask a question: why server doesn't mix the channels altogether and send them to a client (with or without client's channel mixed) instead of this client-side mixing? Of course, it presumes some application upgrades (already proposed: voting sistem or/and room moderator, probably with some producer options), but will greatly improve network-related performance. Is there some point I missed, because it seems like a very logical approach, and yet is not implemented?
Server too busy with mixing processes? Don't think so...
My guess to why you would like to do the mixing client-side instead of server-side is both (as you already has pointed out) that everyone may not want the same mixing so who should control the mixing?, some kind of voting/moderator system is needed. And also that you may want to have all the channels available to remix at a later time.

// Andreas
tanstaafl is offline   Reply With Quote
Old 04-26-2006, 05:05 AM   #3
yanhl
Human being with feelings
 
Join Date: Apr 2006
Location: Paris, France
Posts: 7
Default

Yes ! This is a reat idea but don't forget ninjam is not realtime music, so changing the mix will take a few seconds to take effect and adjusting the volumes correctly could be very confusing.

Maybe it'd be possible to have a quite good result by swapping automatically to a multi-channels mode when mixing, but again, it'll take a few seconds for that mode to take effect.

I suggest you to implement your idea as a "Freeze" option, a trigger between single mixed channel mode/multi channels mode. This way, users might understand and accept the delay for mode swapping.

I'm not sure this will be easy to code, and not quickly overload the server but i wish you good luck and hope to try it in a near future ;-)
yanhl is offline   Reply With Quote
Old 04-26-2006, 08:17 AM   #4
johnny
Human being with feelings
 
Join Date: Apr 2006
Location: Serbia and Montenegro
Posts: 7
Default

What I need in the first place is to have a few (dozens) jam sessions with you guys... I find this very confusing as a musician.
You are hearing a measure before, and playing along what will be heard in next measure. Well it is somehow neat because in 4/4 measure 1st and 3rd beat are more similar than 1st and 2nd...
I don't know what will make a master recording, so I don't have an idea what to mix to the other users. The fact is I think I know, but still I lack some real-life experience here. Unfortunately, my dialup here is simply too slow to try that right now. I'll pack my gear and go in some internet caffe.

I understand that server-side mixing would include some latency (mixing and probably decompressing/compressing), but servers are fast machines by default, aren't they? On the other side, right now bandwidth needed for 5+ member(instrument) band is (especially in my case) enormous and greatly reduces potential participants. In my opinion mixing should be done for sure, so every client recieves only one stream.
Users that have more than one local channel should mix it locally. Maybe some kind of distributed mixing is possible, but it needs some serious thinking.

@tanstaafl:
Yes, Qt is more suitable than GTK because it is multi-platform: supports (more or less equaly) X11, Windows and OS X, so there is no need for branches for each OS.


@yanhl:
I do not understand why do you think that chaning mix would make such a problem? Client with mixing privileges sends new mixing preset and server in the next mixing cycle applies the settings. Of course, that means that mixing must be synchonized, but that is a must anyhow. And I did not think of a producer seriously, it shouldn't be a man who constantly changes volumes and effects, just some guy you can tell: "Turn me down a bit".

Well see you in a few days,
Nikola
johnny is offline   Reply With Quote
Old 04-26-2006, 10:09 AM   #5
FingerSoup
Human being with feelings
 
Join Date: Feb 2006
Posts: 65
Default

Having individual mixes is important. If you're in a Jazz session, and NewBShredderBoB comes in to show off his lack of skills by breaking into a 20 minute guitar solo without even following your song/metronome, etc and fouls up the mix, you should have the option of muting him. Server side mixing would be much more difficult to implement and make the change. as well, would muting be persistent, or would it reset on login? If NewBShredderBoB sees a message saying he's been muted, can he log out, log back in, and kill the mix again? or in 2 days, when he's realied the error in his ways and becomes HappyGoLuckyPlayAlongBoB, and is actively trying to follow along and play with everyone, is he still muted?

No, Individual mutng works best, IMHO.
FingerSoup is offline   Reply With Quote
Old 05-03-2006, 05:49 PM   #6
johnny
Human being with feelings
 
Join Date: Apr 2006
Location: Serbia and Montenegro
Posts: 7
Default

Quote:
Originally Posted by FingerSoup
Having individual mixes is important. If you're in a Jazz session, and NewBShredderBoB comes in to show off his lack of skills by breaking into a 20 minute guitar solo without even following your song/metronome, etc and fouls up the mix, you should have the option of muting him. Server side mixing would be much more difficult to implement and make the change. as well, would muting be persistent, or would it reset on login? If NewBShredderBoB sees a message saying he's been muted, can he log out, log back in, and kill the mix again? or in 2 days, when he's realied the error in his ways and becomes HappyGoLuckyPlayAlongBoB, and is actively trying to follow along and play with everyone, is he still muted?

No, Individual mutng works best, IMHO.
The focus of my story is server-side mixing and each client downloading only one stream (or maybe few streams). So far a classic rock band (a guitar, keyboard, bass, vocal, and few channels for drumset) with a few background vocals requires very heavy network load for each client.
Things you mentioned are certainly important, but it's only the question of administration. KICK, MUTE and HATE as voting commands along with permanent user accounts would solve most of the problems. Also a privileged user should exist, and he can change the volume of other players. I really don't see that as a problem, since SOME user administration has be done anyway.
I also propose a change in user interface: when a voting is set, all the users on the channel get some sort of quick dialog (yes/no, few buttons, radio buttons, etc.) so there is no need to type a command and stop playing, when you can vote very quickly (maybe even hit SPACE button with your leg ).

That's it from me. Tomorrow I'm taking the source code to study... I'm feeling really enthusiastic!
johnny is offline   Reply With Quote
Old 05-07-2006, 09:34 AM   #7
johnny
Human being with feelings
 
Join Date: Apr 2006
Location: Serbia and Montenegro
Posts: 7
Default

Well I'll be damned. I didn't see it's already proposed as the Google SoC project idea. Sorry guys, the moment I saw the project I was eager to download it and test it, so I didn't read it properly. Certainly, server-side mixing it is one of the most important jobs to be done.
johnny 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 12:47 AM.


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