COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :

Go Back   Cockos Incorporated Forums > NINJAM Discussion > NINJAM Developer Discussion

Reply
 
Thread Tools Display Modes
Old 10-22-2015, 12:37 AM   #1
NakajimaYusuke
Human being with feelings
 
NakajimaYusuke's Avatar
 
Join Date: Aug 2013
Location: Japan
Posts: 58
Default Features request : PDC(Plugin Delay Compensation)for NINJAM Client.

Hi, I have a little idea for NINJAM Client's function.

Reaper has PDC(Plugin Delay Compensation) function for Plugin and ASIO delays.
PDC is a convinient function of the delay correction of recorded items.

PDC is known as abbreviation of "Plugin Delay Compensation".
However, this also functions when we don't use any plug-ins.

PDC also performs ASIO Input/Output delay correction.
When recording on the reaper using direct monitoring,
By enabling PDC function, Reaper adjusts a recorded item to the right location.


Can't this function be mounted on NINJAM Client?
Many of the performers using direct monitoring in NINJAM sessions.

Although direct monitoring brings correct timing to a player,
"the sound that is played by the direct monitoring" is including a slight delay by ASIO Iunput/Output!

How do you try to correct this in NINJAM Client?

Before the sound is send to the NINJAM Server,if this ASIO delay is corrected by NINJAM Client,
the timing of our sessions will become more accurate.

In the case of a real-time session, unless we use the time machine, it is impossible to correct the delayed sound.
But it should be possible in the NINJAM session.
NINJAM session is always synchronized with the long loop delay.
To compensate for slight delayed sound, it will be solved by increasing the loop delay.


This is a story for example.

A bus departs every 1hour from the bus stop.
A guitarist always arrives at a bus stop in 10 seconds late from the departure of the bus.

When the guitarist run and chase the bus with a delay of 10 seconds,
the time when he arrives at the destination is delayed 10 seconds.

When a guitarist waits for 59 minutes and 50 seconds at a bus stop,
he can take the next bus, so delay in the arrival time to the destination is 1 hour exactly.

I'm sorry if this is not a "good example story.

Best regards!
Attached Images
File Type: jpg pdc1.jpg (38.3 KB, 1303 views)
NakajimaYusuke is offline   Reply With Quote
Old 10-22-2015, 06:26 AM   #2
Fergler
Human being with feelings
 
Fergler's Avatar
 
Join Date: Jan 2014
Posts: 5,205
Default

I've never seen or had myself any issues of latency on Ninjam
Fergler is offline   Reply With Quote
Old 10-22-2015, 10:14 AM   #3
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 767
Default

You should only ever hear what you're playing through NINJAM - that overcomes any issues with being out of sync with the NINJAM metronome. Keep your local volume low enough you can hear the click, of course... If your hardware isn't up to supporting a low enough ASIO buffer size to avoid noticeable delays, PDC cannot help - you need to upgrade.

PDC is about adding additional delays to signal paths to compensate for delays in alternative signal paths -- it does not remove delays: it adds them.

The ReaNINJAM client introduces no PDC latency - a sample received on local input is output on the same cycle, so PDC doesn't help at all.

Externally connected NINJAM clients should work the same way: a virtual ASIO cable introduces no latency, so such clients themselves introduce no delay.
__________________
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 10-23-2015, 09:15 PM   #4
NakajimaYusuke
Human being with feelings
 
NakajimaYusuke's Avatar
 
Join Date: Aug 2013
Location: Japan
Posts: 58
Default

To confirm the delay caused by the use of direct monitoring, I tried an loopback experiment.
I connected an output to input by cable, across my audio interface.
http://forum.cockos.com/attachment.p...1&d=1445659918
In this way,"the output sound from the audio interface" returns to input.
This is a reproduction of the accurate playing using direct monitoring.

(If my rhythm is correct, I'd play with a metronome.
However, because my playing is unskilled, correct rhythm will not be obtained.
So, this time I was reproduced direct monitoring play in a mechanical way, to reduce an error. )

I entered a NINJAM server by this setting.
Metronome sound of ReaNINJAM is output from the audio interface, and it came back to the input.
This means "the sound of the metronome was sent from NINJAM client to NINJAM server".
I recorded multi-track recording data for this session in clipsort.log.

Then, I opened the clipsort.log in Reaper, and I confirmed the amount of delay.
This is the result.
http://forum.cockos.com/attachment.p...1&d=1445659918
Distance from the "tip of the item" to the "tip of the waveform" is the amount of delay.
If the delay is not present, tip of the item and the tip of the waveform is should overlap on the theory.

In my experiment, even tried in any buffer size,
the amount of this delay was almost the same amount as the amount of ASIO Input + Output Latency.
In this image, fully values match.
16 + 29 = 45

That is, when seeing from inside the NINJAM Client, the played sound using a direct monitoring is always delayed.
The amount of delay is the sum of the "ASIO input delay" and "ASIO output delay".

We are playing while listening to the "output sound from the audio interface".
And, "output sound from the audio interface" has been delayed by the amount of the ASIO output delay.
Because we're playing while listening to the sound(Index, mark, reference, clock) that was delayed, our performance has also been delayed.
In addition, the delay of the played sound is also generated when the input to the audio interface.

Thus it's certain that ASIO delay is included in the sound NINJAM Client sends to a NINJAM server, in case of direct monitoring use.
I hope the correction function for that to NINJAM Client.


I tried to specific experiments using readelay.
By entering the following delay time, I was able to correct the above-mentioned delay.

(60000*bpi/bpm)-(Asio Input Delay + Asio Output Delay)

But of course, it's troublesome to do this calculation each time during a session according to the change in BPM and BPI.
I want the function which calculates this automatically according to the change in BPM and BPI and applies it in NINJAM Client.
Attached Images
File Type: jpg directmonitoringdelay.jpg (48.4 KB, 1283 views)
File Type: png loopback2.png (5.0 KB, 1092 views)
__________________
Sorry about my poor English.
NakajimaYusuke is offline   Reply With Quote
Old 10-24-2015, 12:33 AM   #5
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 767
Default

PDC cannot help.

The sound, by the time your PC gets it, is delayed.

PDC can only delay it further.

Oh and regardless of if you think you play better by ignoring the sound coming from NINJAM, everyone else in the room will think you play better if you're hearing yourself play through NINJAM. Do not use direct monitoring and always hear the click if you're meant to be playing "in time".
__________________
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 10-24-2015, 02:30 AM   #6
NakajimaYusuke
Human being with feelings
 
NakajimaYusuke's Avatar
 
Join Date: Aug 2013
Location: Japan
Posts: 58
Default

Of course, I understand PDC cannot help at ninjam session.
I do not need to mount the PDC itself to NINJAM Client.

I just want a delay correction function when using direct monitoring on NINJAM Client.
"The function I desire" plays the role like PDC. But a way and a system would be different from the PDC.

Excuse me. Maybe my sentences were terribly ambiguous.
In order to explain my desire mechanism, I should not have used the word "PDC".

I wrote the PDC as a mere "result".
Perhaps you interpreted PDC as"the "function".
This is the cause that our conversation was incongruous, isn't it?

I'm sorry about it.
Now, please forget the word "PDC". I'll explain more simply.


1. Issue
When we played with the direct monitoring,
NINJAM Client receives the played sound with the ASIO delay.

2. Solution method I expect
NINJAM Client adds more calculated delay to played sound.
Then, played sound would go around the bpi and comes full circle.
The delay a session partner feels should disappear.
Even if the session in any high buffer size, the session partner would not feel the delay.
__________________
Sorry about my poor English.
NakajimaYusuke is offline   Reply With Quote
Old 10-24-2015, 09:45 AM   #7
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 767
Default

Ah, I think I see what you're saying.

As NINJAM is already delaying the received channels to align to the BPI, if a sender also included each channel's input ASIO delay, each recipient could adjust for that delay when aligning each received channel to the BPI. (For MIDI triggered audio that hasn't come in via ASIO, that delay would be zero, of course.)

That would mean a change to the protocol, indeed, and a change to each client to work with the new protocol (unless it can be added in a way existing clients can ignore).
__________________
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 10-27-2015, 01:15 AM   #8
NakajimaYusuke
Human being with feelings
 
NakajimaYusuke's Avatar
 
Join Date: Aug 2013
Location: Japan
Posts: 58
Default

Thank you for deciphering my intention.
It seems that I could tell my purpose. I'm happy.

Quote:
Originally Posted by pljones View Post
As NINJAM is already delaying the received channels to align to the BPI, if a sender also included each channel's input ASIO delay, each recipient could adjust for that delay when aligning each received channel to the BPI.
I think this is the most clever way!

In my described method, NINJAM Client would produce an extra delay of a bpi.
In the way that you explained, NINJAM Client does not produce even this disadvantage.

Though I'm not conversant with this field,
Perhaps, in synchronization in the current NINJAM server, only the network delay is processed.
When ASIO delay was also added to this synchronization processing, my wish will come true.


The only advantage of my method is "implementation is not a large scale".
It's simply a delay effect that is based on the bpm and bpi and Asio latency.
(Although I have no knowledge to make it...)
__________________
Sorry about my poor English.
NakajimaYusuke 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 04:45 AM.


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