Reaper 5?

[lfm]

No, I did not read all your posts, just a reaction to and expansion of the quoted one.

which is why your posts don't address concerns that aciddose has raised.

If all is setup to sound properly with external monitoring, and you calibrate your recording device for different internal delays - they will sound the same when starting to mix the recorded material.

...which is totally not what aciddose was talking about. he was talking about latency compensation when doing live output. recorded sounds and background sounds do sounds align on the recording, but don't align during monitoring (i.e. the live output is not latency-compensated against the background).

Then my post raised and explained some other issues regarding lining up for recording purposes - acknowledge or ignore is up to everyone. It is a subtopic of this thread, so, the thread was started sept 2014, a year ago. My remark was mainly adding to acidose, not replacing it.

What plays back will be lined up regarding plugin delays - what is monitored live through normally not( but see comment below). Position of any recordings on the same material will though be positioned correctly(clips offset accordingsly) - to later be mixed and played back lined up - if recording that is.

And as shown before, Reaper has this setting "preserve latency" if you still want your recorded clips, if any, to be positioned in the timespot where it arrived - no compensation applied, no soundcard delays, no plugins delays compensated for.

Unless hardware inputs are calibrated daw have no chance to compensate for plugin latencies anyway. Different input latencies is not possible to set up in asio, it's one value that can be reported to host.

Since Reaper has ability to put plugins in input stream - you can even use delays that correspond to plugins delays - so they line up. Some careful planning though of the whole setup is needed - and if as much as 256 samples to start with it might not be useful to do anyway. One thing that made me leave Reaper was how output latency was handled in multiple buffers only.

But before anything, look at what converters produce regarding delays. If this is correct, the rest of the chain is much simpler to set up. It's down to only compensate for plugins latency left.

Then let's say you've got 64 samples plugin latency on what is played back, putting a plugin that delays 64 samples on input stream(not ordinary plugin slots for realtime effect, but input slots that also allow plugins in Reaper) will make monitored live align with the rest played back.

But if this aquired total latency will affect playing is another matter. In my case running 64 samples asio buffer probably would work still adding 150-200 samples plugin latency, acidose example of 256 probably not.

You need an interface that match your needs. Reaper is worse than other daws on this - since more output latency is added if you exceed a threshold for one buffer, you will immediately get two buffers delay on output. I never had recording issues with 128 samples in other daws, but in Reaper I had to go down to 64 because of how it handles latency. If basic interface setup need 256 samples, then you are in trouble.

[aciddose]

As I read what you're saying, it looks like you do not understand the issue or the technical details of the issue completely.

I'll explain again: The input latency is fixed. We can measure it. In order to align the monitoring input with other tracks, other tracks must be delayed equal to the difference between them. That delay is equal to the delay applied to the tracks after recording.

See here:
http://xhip.net/temp/timing.wav

These two sounds should occur at exactly the same time, they're both triggered from the same MIDI input.

This can be fully compensated, automatically.

Yes, you can manually insert a delay plugin to other tracks to line them up with the monitoring input.

Due to this, why doesn't reaper already do this for me?

Think of the input like this:

[analog/ADC] -> [monitor input] -> [input latency plugin] -> [other Reaper fx slots] -> [mixer]

The problem is while Reaper takes into account all the other plugin latencies and corrects them, it ignores "input latency plugin".

I can create such a plugin myself. It passes the signal directly with zero latency, but it reports to the host the input latency.

This shouldn't need to be a plugin or script, it should be a core function of the host.

[kbaccki]

[analog/ADC] -> [monitor input] -> [input latency plugin] -> [other Reaper fx slots] -> [mixer]

The problem is while Reaper takes into account all the other plugin latencies and corrects them, it ignores "input latency plugin".

I can create such a plugin myself. It passes the signal directly with zero latency, but it reports to the host the input latency.

I believe PDC is disabled by default on rec-arm'd tracks. I think you can right-click the arm button and tell it to account for PDC, but i dont know if that's for monitoring + clip placement, or just clip placement.

I also believe there are known limitations/issues wrt. compensating MIDI event latency relative to overall audio latency compensation.

http://forum.cockos.com/showthread.php?t=155667

I don't do live MIDI monitoring (everything ITB here), but am curious to understand the latency issues and possible PDC settings... plus I want to play around a bit with v5...

[aciddose]

I think you can right-click the arm button and tell it to account for PDC, but i dont know if that's for monitoring + clip placement, or just clip placement.

You mean the "preserve PDC delayed monitoring in recorded items" option?

This compensates the monitor input channels, but only according to the offset generated by plugins on other tracks. So it will further delay the monitor signal to line up with other tracks, but since Reaper has no account of the input latency the monitor track isn't lined up to start with.

So:
[ADC] -> [Monitor] -> [Input latency] -> [Delay +100 samples] -> [Other plugins] -> [Mixer]
[Another channel] -> [Effect produces 100 sample latency] -> [Mixer]

The problem is still "Input latency" has not been taken into account, so adding the 100 samples doesn't help. If input latency is already equal to 100 samples, the delay should not have been applied at all.

The option itself though simply maintains that PDC delay in the recording itself.

See here:
http://forums.cockos.com/showpost.php?s ... stcount=47

I don't want to record what I hear, because what I hear is wrong. I want it to be right

(The thread like most on the Reaper forum makes me feel sick. It's a bunch of people talking about something they don't understand. Someone asks a question they know they don't know the answer to, and everyone else who doesn't know tries to answer. Barf. Please people, if you don't 100% know what you're talking about for the love of whatever, STFU.)

"Plugin Delay Compensation" is a dumb name. Justin should rename this feature simply "Latency Compensation" and also take into account other sources of latency such as the input latency if this isn't accounted already.

I'm already having to explain the same thing 15 times and we're not even on the Reaper forum yet. This isn't really providing me with a lot of hope.

[sugo]

I don`t know what you are talking about, but i give 150% with Love

[aciddose]

I'll give another simple example in case it might help someone who still doesn't get it.

You have many channels/tracks. Each has some latency. The goal is to align each in time at the output.

So: (track latency in samples)

1. = 50
2. = 0
3. = 95
4. = 206
5. = 608

In order to line these up, we need to mix them with latencies that are all equal.

To make them equal, we must add latency to the lower latency tracks to match the highest latency track.

(mixer latency to delay)

1. 608 - 50 = +558
2. 608 - 0 = +608
3. 608 - 95 = +513
4. 608 - 206 = +402
5. 608 - 608 = 0

So now we have the mix of all tracks aligned.

(total latency at mix)

1. 558 + 50 = 608
2. 608 + 0 = 608
3. 513 + 95 = 608
4. 402 + 206 = 608
5. 0 + 608 = 608

[EnGee]

@aciddose
It's tiring indeed. I suggest to post in their forum and write a link to your starting post here.

Not all roads covered with roses unfortunately. I had also a bug to report when Reaper 5 was in beta and the developer didn't find it that crucial, which it isn't. I checked it in the final version and it's still there. It is when you view midi files (say drums patterns) there is a speed info with it. Let's say the midi file tempo is 69 but the host tempo is 120. If you want to hear the midi file at 69 bpm, you need to change the host tempo because the option to hear the midi file at its original tempo doesn't work.

The above bug is not in Reaper alone! It's also in Studio One and Sonar (as I remember). Actually it's only working in Cubase.

Anyway, still I consider Reaper as my second choice after Studio One. I uninstalled Cubase because the licencing policy is really mean now that I only can get one computer to be authorised with Steinbergs products if I use soft e-licenser! While in the past I could install them in 4 systems the same time (now I have only 2).
Nothing is perfect, so choose whatever fits your priorities and accept the minor things if they are minor in your mind.

[aciddose]

I've had that same issue with MIDI tempo... As far as the bug you can't really blame them because the Microsoft .mid format is such a huge pain to deal with.

It definitely is important and difficult to work with though. It bugs me every time I encounter the problem and need to make all the manual adjustments. I've found manually stretching the clip works okay, but that only works if you have some reference point to line them up and then quantize. It is definitely not a technical solution, just a shitty work-around.

The delay thing is also minor in some cases, just that when you need to insert special plugins on several different tracks and adjust delay times it gets to be likewise a major pain. Inserting delay plugins is a technical solution actually, but it would be so much easier if they would just do this. I haven't seen the code myself, but I would be flabbergasted if it wasn't far easier to take input latency into account for the PDC (and allow individual input timings to be tweaked) than it is for me to need a special delay plugin/script and fiddle with it every time, over and over.

The real pain is the same with both issues, yours and mine. The problem is we're forced to manually do exactly the same thing over and over that could be automatic.

[EnGee]

The real pain is the same with both issues, yours and mine. The problem is we're forced to manually do exactly the same thing over and over that could be automatic.

Which what the computers supposed to solve

No, I don't blame them. I remember once a SQL request that made me crazy with Microsoft SQL Server express. I didn't want to give up, so I went here and there asking the gurus in Microsoft forums ..etc. In the end it was a bug in the SQL Server! I used Access for my database client program and it worked with my SQL request! That was more than 7 years ago though and I'm not into programming anymore. Anway, I learnt from it, that I need to put the possibility of the big companies bugs (from the OS to the small libraries) into consideration and I can understand the developer's point of view when some bugs are very tricky to deal with not because of a lack in the knowledge but simply a bug in the platform or core libraries!

[fmr]

I'll give another simple example in case it might help someone who still doesn't get it.

You have many channels/tracks. Each has some latency. The goal is to align each in time at the output.

So: (track latency in samples)

1. = 50
2. = 0
3. = 95
4. = 206
5. = 608

Just to make sure I understand exactly what you are talking about - you mean tracks you recorded with outside gear, while listening to some guide track, right?

[aciddose]

No, I mean any track. Unless you mean "some guide track", usually there are a mixture of many external sources and internal sources and they must all be in sync.

The numbers I gave are just some random numbers to show how latency compensation works.

Any track can have a latency associated with it, and latency compensation is the act of making sure all delay times are equal before the tracks are mixed.

Possible sources of latency include input latency and plugins or other processing.

I mean this:
https://soundcloud.com/aciddose-1/latency-compensation

I had to manually insert a delay plugin to add the input latency to align the tracks.

I could also use REAPER's PDC system if I inserted a different plugin to report the input latency to the host on the monitored track.

This is a pain. In this case I only needed to use one insert, but once I start using multiple inputs with different input latencies and many channels it becomes a nightmare.

This was recorded live, so the important thing is I need sync on what I get from my speakers. I don't care about REAPER's recording offset features, I care about actually recording what I hear in sync in real-time.

This is just one example however, this becomes an issue in many cases.

I can create another clip to demonstrate although I'm not sure how useful it might be. Just delay one channel by the input latency and mix them to hear for yourself. I'm sure everyone understands what 13.5ms delay sounds like.

[jens]

The problem is while Reaper takes into account all the other plugin latencies and corrects them, it ignores "input latency plugin".

Either it doesn't ignore it or I don't get what you mean...


edit: reading through the last few pages got me progressively confused

[aciddose]

Well ranting about it isn't going to help, I'm hoping to convince Justin to consider implementing this.

Yes people tend to get confused when I attempt to explain stuff.

It ignores it live, like when you're monitoring, it doesn't apply PDC based upon the input latency to the other tracks.

It will shift the position of the input track after you've recorded it (backward), but if you try to play external synths and plugin synths live (by monitor of the input for the external synth) they won't be synced (forward).

You can force PDC to take effect by inserting a "liar" plugin on the monitor effects that claims to have the same latency as the input has.

I'll build this plugin and test quite soon it to ensure I'm not simply making this up

So far the way I handle it is instead I insert a delay plugin set to the latency on every track except the monitor input track. That's a pain with a lot of tracks involved.

[aciddose]

Justin's response was that you can use ReaInsert to accomplish this by entirely replacing the record/monitor functionality.

The method is equivalent, although not at all intuitive in my opinion compared to hardware multi-trackers or other DAWs like Cubase.

It isn't possible to use the monitor inputs, REAPER does not apply PDC to them and despite my urging Justin seems reluctant to add such an option.

Instead, when you use external equipment you must use ReaInsert as an effect insert and select the input/output there instead of using the record/monitor/route sections.

For example what I do is place the MIDI clip as a sub-track of the audio (recording destination) track with ReaInsert applied there.

On the parent track, enable record and select "output" without latency compensation as the source.

ReaInsert has a "ping" feature to attempt to measure latency by sending a MIDI trigger and detecting a response on the audio input, although this is dependent upon the input signal and somewhat unreliable.

It also allows manual adjustment.

The one thing I don't like is if I'm using many different inputs with many different latencies and "ping" isn't reliable, if I want to switch inputs on a track there is no automatic way to account for that change and update the latency compensation coefficient.

That said, although it is a major pain and requires quite a bit of additional manual and repetitive user interaction for the most part it is entirely equivalent.

I'm satisfied, but I don't think this is a good solution if REAPER is designed to work like a hardware multi-tracker.

[EnGee]

Thank you aciddose for the info