Do higher TPL or LPBs improve MIDI recording?

Help, Support & Bugs
6

UPDATE

I think I now found the reason:

The midi latency compensation does not work properly.

STEPS TO REPRODUCE

Test Setup: 48kHz, 50ms latency, LPB 8, 126 BPM

  1. Enable compensation

  2. Use spiky very short sound. Fill-in first track with a note each 8 lines.

  3. Now record on second track (with metronome, too). While recording, the played impulses will sound quite near the first track / metronome. On replay, the whole recording is too much shifted downwards

  4. Disable compensation.

  5. Disable 2nd track. Record on 3th.While recording, the played impulses will sound quite near the first track / metronome. On replay, the whole recording is too much shifted upwards.

7

I think it would heavily improve the “humanized” midi recording, if the limit of tick per line in song options (currently max.16) would be increased to 32 or even 48.

If I use a song setting with126bpm / 8 lpm, one 1/32th note or one line takes ~60 ms. If you set ticks per line to 16, which is a timing fluctuation of 3,75ms.

So if the ticks per line would be now 32 the fluctuation would be only 1,8ms, almost inaudible.

For lower BPM, a even higher value would of course better.

Personally I don’t want to work with LPB 16, since it results in a huge, faaast scrolling pattern, too fast for my eyes.

Thank you!

8

Err… Did I put it in general suggestions or you? I thought I put it in 3.1? :slight_smile: n/m

9

Ticks Per Line in the Song Settings affects the playback of certain sample-based effects like Rxy Retrigger, Axy Arpeggio, Gxx Glide, etc, and also the playback of certain modulations like how often an LFO or some other Track DSP meta device will apply its output value.

As far as I’m aware, TPL should not be affecting the resolution or “humanization” of any notes you play and record live, since this is unrelated and handled elsewhere.

Basically, the notes you play live come into Renoise with sample accuracy (as accurately as your audio interface can provide anyway), and are then recorded into the pattern at a fixed resolution of 256 events per line (assuming you have quantize disabled, of course).

If TPL did affect the resolution of recorded notes, then using 1 TPL would be equivalent to recording with quantize enabled and set to 1, which is clearly not the case.

Are you experiencing something different that you can reliably prove with a test case, or is it just more of a general feeling you had while experimenting with different settings?

Or did I simply misinterpet something you’ve said above? (Wouldn’t be the first time, I admit.)

As usual, the more information you can provide, the better. You may indeed be experiencing some fuzziness when recording live, but I don’t believe it should be related to TPL in any way.

(The suggestion to raise the TPL limit is still interesting in and of itself, though.)

10

Hi,

ok I doesn’t seem to understand this option correctly.

I only made some tests:http://forum.renoise.com/index.php/topic/46581-midi-recording-notes-sometimes-placed-a-line-too-early/?p=341228

Using a spiky sound and recording it with metronome (and also audio recording while recording using melda mrecorder). Then I did compare the record while recording with the replayed version:

The the maximum variation between spikes in both recordings were about 5ms, so I thought this seems to fit with the setting 12 ticks per line that I used.

So maybe I should rephrase this feature request into something like:

“Please at least double the resolution for a single line at LPB 8” ? Can the user influence this resolution already? 5ms variation is IMHO a bit too high. And will even increase on low BPM, right?

As far as I know and discussed with other Renoise users, they believe that a higher LPB results in more precise recordings. But LPB > 8 is too fast scrolling for me.

11

Thinking about this in terms of PPQN (Pulses Per Quarter Note) as other hosts commonly do, Renoise’s default setting of 4 LPB (Lines Per Beat) gives us an effective note event resolution of 4 lines x 256 note delay resolution = 1024 PPQN.

At 8 LPB you do course achieve a higher overall resolution of 2048 PPQN, simply by factor of cramming more potential pattern data into the duration of a single beat.

I think the real issue may be one of timing, and not necessarily resolution, and the timing issue is unfortunately a lot weirder to deal with.

If you’re recording notes while listening along to some existing sounds or the metronome… The sound is produced by Renoise and delivered to your audio interface with some amount of latency for the audio buffer to fill up, then some tiny delay to be sent out through your speakers, then some tiny delay that it takes for your ears to hear the sound, then some (potentially considerable) delay for you as a human to react to hearing that sound and actuating your arm/hand/finger into pressing a key on your controller, not to mention the weird crap we humans tend to do like anticipating the upcoming note too soon or playing it too late, then some delay for that MIDI message to get from the controller to your computer, then some more latency for your audio interface to deliver it back to Renoise…

All that crap is a lot more spooky and difficult to figure out!

12

Thanks for all this info and your thoughts about it!

But I think, I found a bug at least here:http://forum.renoise.com/index.php/topic/46581-midi-recording-notes-sometimes-placed-a-line-too-early/?p=341268

Can you replicate this, too (on OSX)? This would explain, why quantization strangely moves notes to early or whatever. Here, if compensation is enabled, notes are quite a lot too late, without too early. And this is not just in my imagination. It’s imo quite audible, if the latency is huge…

13

… No answer means no, I guess?

Anyway, dblue, I like to ask you some more detail:

Somebody told me that at least the refresh rate meta modulation actually is dependent on TPL… Is this true? If so, how should I understand this, let’s say regarding a sine Lfo, or a curve of the signal follower? Is the target device then set/updated with TPL frequency? And in between, does there happen an interpolation?

Sorry if i ask questions that were already answered…

14

C’mon guys… !! Please give me at least an answer!

I mean I am trying to improve your software here. Do you can replicate it? No clue what I am writing about? Won’t fix? Or do you think, it is a problem in my system?

Here is now a test case/song for you. Settings in OSX are 48kHz, 60ms latency:

Attachment 6420 not found.

first pattern recorded with compensation, second without. Uses melda mrecorder in master track.

Listen to the live recordings, first only the programmed kick, then the recorded live recording (how it should sound), and the last part the replayed pattern:

Attachment 6421 not found.

Attachment 6422 not found.

See the difference in a sample editor. Here are the differences between live and replayed, left channel is live, right channel replayed:

Attachment 6423 not found.

Attachment 6424 not found.

You can also hear the difference. In 1, sometimes it’s totally obvious, mostly it’s some milliseconds, so max zoom it. In 2, it’s constantly obvious.

15
  • UPDATE *

It seems to be almost ok if I use Renoise 32 bit build with midi compensation enabled. It is obviously better or maybe good here… Not so in 64bit build. (not 100% sure about this, I will do more investigation) EDIT: Damn, this is hard to test. Was rubbish, same behavior 32 vs 64

@robohymn, do you use OSX? Did you set the latency to 60ms or more?

Yes, I think there are two problems:

  1. Sometimes a note is placed too early, just like robohymn reports it too

  2. With enabled compensation, the variation is quite small, maybe not audible, if you do not directly compare recorded live recording vs. replay. But IMO it is there, and will cause the quantization to go crazy.

With or without compensation the replayed result should sound just like it sounded while live playing/recording.

@robohymn, did you compare the diff while recording and replaying? Or simply the result.

16

taktik and dblue,

I am now confused about the provided information: dblue stated here, that renoise has a resolution of 256 per line. The above problem is nothing the fine, it is much more fought timing problems.

But if I record with LPB 32, the problem is almost gone. I mean almost no more sporadic dis-placements and also much less offset. So it seems to be dependent on LPB? Cant you “just” quick fix this, so renoise will use internally LPB 32 while recording, without changing the display or modifying song structure? Or even LPB 64?

Something in midi input is totally messing up here.

17

@ffx: sorry, but this topic is messed up. You’ve lost me.

Please do not try to guess what the problem could be. This never works. Simply let us know what exactly you are doing, what is happening, and what you are expecting. Let us take care of the rest.

Also, to make sure we’re talking about the same thing, there are two options for recording in Renoise:

  1. With latency compensation enabled means “Record what you hear”
  2. Without latency compensation means “Record what you play”

What you hear means here, the sound that you are hearing from your speakers while recording an instrument that is played thru Renoise.
What you play, is the time you hit the keyboard key/stick/whatever else that is going to trigger something in Renoise.

  1. is usually what you want, as most people automatically adapt their playing to what they are hearing.
18

Ok, it’s a mess, I agree.

But there is still a problem with midi recording in Renoise… A pity you are trying to ignore this. I’ve chatted with a bunch of users, and as far as I can tell, a lot people moved on to other daws because of this timing problems.

Could you give then access to the following two functions in the API:

  • pattern expand ( command + F9 )

  • pattern shrink ( command + F8 )

?

Because then, I would add an “auto expand to LPB 32” on my “record on”-shortcut and a shrink on “record off”.

This will not work with expansion via a lua script, since it needs to be blazingly fast, just like command + F8 / command + F9. Instantly.

Please consider this. Thank you.

19

… No answer means no, I guess?

I only responded to your main post here to say that TPL has nothing to do with note recording.

You got no other answers from me yet because I don’t keep a Mac system or MIDI controller at home, and I haven’t been to Renoise HQ yet this week where I do have access to both of those things.

It will be tomorrow at the very least before I’m able to test anything you’ve posted so far. Even then, I’m not really a Mac user in the first place, I don’t have the exact same setup as you, nor the same timing and playing abilities, etc, so my own tests may ultimately reveal nothing special anyway.

Somebody told me that at least the refresh rate meta modulation actually is dependent on TPL… Is this true?

Correct. TPL is also responsible for how often a meta device will “tick” and send its output to the other connected device(s). I briefly mentioned this above, and it’s also mentioned in the manual.

An LFO will pump out its current value 12 times every pattern line (or whatever TPL is set to). Even when the LFO is tuned to its fastest possible frequency of 1 line per cycle, the default 12 ticks per line is still quite enough to represent a basic sine shape for the purposes of modulating some other parameter.

Whatever you connect the meta device to is also likely to be interpolated anyway. For example, pretty much anything in Renoise relating to volume, panning, filter frequency (especially those with intertia), and so on, will apply its own smoothing “in between” ticks depending on what it needs.

In the future, I think it would make sense to finally separate TPL away from the meta devices, so that TPL can really only be applied to the classic sample commands, and then the meta devices have their own more flexible (and higher frequency) modulation rate, similar to how we beefed up the instrument sample modulation rate in 3.0. But that’s a discussion for another time.

20

dblue, thanks a lot for clarifying this to me!

Ok, now finally, I start to understand:

A LPB of 32 or even 64 would resolve almost all midi record timing problems. But working on a pattern with LPB 32 isn’t ergonomic. So I highly looking forward for the day, you guys either give us access to internal pattern expand/shrink commands, like mentioned here, or you will change the way internally how Renoise is doing recordings, by temp-switching LPB to 64, without visual change.

EDIT:

Since,

if I work on LPB 8, expanding to LPB 32, recording then and again shrinking to LPB 8, results in a good timing. Not so recording directly in LPB 8. So this is the proof that those timing problems don’t exist, because the resolution is too low on LPB 8. Which was my initial assumption, since lot of people told me so. It is also a proof, that something fishy is going on.

21

You’ve misunderstood dblue here. See https://forum.renoise.com/t/do-higher-tpl-or-lpbs-improve-midi-recording/45134 please. If you are recording !without! quantization, with the note delay column enabled, a resolution of 1024 PPQN is more than enough in most cases.

Changing the LPB does nothing at all to Renoise’s internal resolution. Renoise’s internal resolution are samples. LPB only changes the resolution the events are written into the pattern - and thus are played back afterwards when played back from the pattern.

So recording a pattern with an LPB of 32, then shrinking it back to LPB 8 does not improve timing.

Instead of trying to look for a solution for a problem, try to describe your problem as detailed as possible please, so we can replicate it here. When there is a bug and it can be replicated, it will be fixed. Else it’s really hard to do something here.

22

So recording a pattern with an LPB of 32, then shrinking it back to LPB 8 does not improve timing.

taktik, but exactly this is NOT true! Really. I really don’t know how to describe it better, maybe due my lack of sophisticated skills in English…

Please try my test case I uploaded and do the following steps:

  1. Load test case song. Disable metronome, disable quantization. Enable compensation. Set latency very low (e.g. 8ms)

  2. Now record the rimshot (key C#3) on track 2 along to the kick, exactly for one pattern length. TRY TO REALIZE WHICH NOTE didn’t had much offset while live playing.

  3. Let the pattern loop play and immediately listen to the recording. Usually you will hear at least one note that totally differs (in position) from what you just played (If not, then just re-record, or try higher latency)

  4. Now set LPB to 32, expand x4 using dblue’s pattern resizer tool. Clear track 2.

  5. Repeat steps 1-3, this time with LPB 32. You wont hear any timing glitch anymore.

  6. Now resize pattern /4 (resizer tool), LPB to 8. The timing is still nice.

23

For a more obvious demonstration about that timing problem, check out my latest update of “TunedShortcuts”:https://forum.renoise.com/t/topic/43378

It’s simply amazing how much better you can record at LPB 32. The shortcut will temporarily expand pattern, and shrink on disabling record again. Could be even better.

Please check this out, to get what I mean. Thanks.

24

So I now conclude here my investigation finally:

  1. Using enabled midi compensation, the recorded input will be placed too late in comparison to the live played.

  2. This effect is the stronger the higher the latency

  3. Using very high lpb >= 32 for recording will fix this problem a bit. Also the “random note too early” disappears

  4. Back shrunken pattern to original lpb still have a much better timing regarding the too late position

  5. This about some milliseconds, so best noticeable if testing with short impulses (like in test case above)

25

I cannot hear anymore any issues (in 3.1 RC1) so far… :slight_smile: Also live quantization again works like it should.