Closed pljones closed 9 years ago
pljones, I read the post. This guy do a nice experiment. If I understand correct the problem appears only when using direct monitoring, right? I'm not shure if this a real problem to solve, "disable direct monitoring" is easy and the right thing to do. Propose a change in ninjam protocol is very complicated in my opinion. We can adapt Jamtaba to this new protocol version, wahjam can adapt, Tom can change ninbot servers, etc. But cockos will change ReaNinjam? This is a complex discussion in my opinion, not just a simple issue to add in Jamtaba list. Please feel free to disagree.
Ezee, what you think about?
" Ezee, what you think about? " ah ah ah ... please ... noooo... ! Well ... i've started to write something , but that ended to be too complicated . You say in few words the essential .
"disable direct monitoring" is easy and the right thing to do. :+1:
;)
Yes, that's my view too - I'm strongly of the viewpoint that the only sound to your ears should be through NINJAM when you're jamming.
Totally agree, I'm closing this issue. The solution is "no direct monitoring, please!" :)
For your info, this feature was from a post over on the Reaper forum: http://forum.cockos.com/showthread.php?t=167838 (ignore everything down until after the "Ignore PDC!!" bit)
It's a NINJAM protocol change affecting both client and server, so it may not be of interest.
From what I've understood the OP to want, I think the idea is to "know" the amount of delay due to ASIO input buffer size, pass this on each packet to the server and then on to each receiving client, then have each client know to "strip" this delay when aligning to the NINJAM clock.
I can't see it being possible in VST mode (you don't know where the audio signal came from, let alone whether there was any delay). I also haven't heard of anyone else with the problem other than the poster on the Reaper forum.
Thanks,
-- Peter