MIDI timing in Renoise is bad when getting sequenced externally (by Cirklon 2)

Help, Support & Bugs
5

This has nothing to with latency , latency is just an added value but at least it’s constant
In this case it’s jitter between received midi events ,meaning the vst’s that produces the audio sound drunk
so there is NO use in recording the audio .
If you look at the screenshots and listen to the files you’ll notice that the 16th , 32nd and 64 steps don’t have equal spacing between them because renoise is not accurately capturing the incoming midi data , while reaper does .

Summary , renoise is ONLY used as an instrument host , all the midi data it receives comes from the cirklon , renoise’s play button is NOT used
1

1 Like
7

I said there is NO use in recording audio when renoise is used as a vst host andd sequenced externally because of the midi jitter , so why would I record jiitery hi-hats ??
Sure I record in renoise , when I sequence my hardware with renoise and it’s all verry tight but this is NOT what this is about .
Let me clarify , I am NOT talking about renoise midi out capabilities .
That has been rock solid for ever , I have been using renoise to sequence hardware instruments , vst’s and it does it exceptionaly well
This is about the MIDI IN data that is processed by renoise to trigger vst instrument
So renoise is just used a mixer where each channel holds a vst , the midi it receives is coming from the cirklon .
If you have a midi keyboard connected to renoise , think of replacing that midi keyboard with a hardware sequencer controlling/sequencing plugins .
Let’s no deviate from the topic and wait what the developers have to say about this

8

@ developers
You don’t need a cirklon to test this , just any hardware sequencer will do ( assumming it 's pretty tight )
Just create some 32 , 64 th notes in your hw seq. and send it to a vst in renoise

9

Renoise is the green track , jittering is already obvious at 16th notes
Right click open in new tab to see full screen
Cantabile also struggles with 64 th notes(yellow trck )
4th
8th
16th
32nd
64th

2 Likes
10

I have the same feeling about any midi keyboard input in Renoise since some version, timing is pretty random, and never is recorded exactly as played (macos 10.14.6 here).

After reading @gentleclockdivider 's post, I also think that midi out in Renoise is affected, too. I once sent midi out from Renoise to record it in Bitwig. I then stopped these experiments, because of extremely poor timing. Back then I really wondered, because CoreMidi is known to be rock solid, even with a virtual routing.

1 Like
11

7 posts were split to a new topic: Unstable timing (jitter) of VSTi MIDI routed events

12

Further tests
Simple midi out , line pes beat is set to eight , bpm 120 , so a line is a 32nd note
I place two notes on one line ,first note no delay value , the second note having a delay value of 80
So renoise triggers 64th notes
The result is absolutly horrible over midi out , what happened ?
One could argue it’s my midi interface ( roland integra ) , but then it would give equal shitty results in reaper and architect , which it doesn’t
Ticks per line is set to 16

1

13

This is getting a bit too much info. Let’s please test everything separately to see what exactly is the problem here.

Let’s first skip VSTis and MIDI routing between them, and only test the input timing of the RAW MIDI events into Renoise:

Raw MIDI Input timing:

I currently don’t have some MIDI generating HW here, so I’ve used loopMIDI | Tobias Erichsen instead to create a virtual MIDI port instead.

Using this virtual MIDI device as output port, I’ve created a simple MIDI clip in Ableton Live 19, triggering 16th C-2 notes at 120 BMP.

Then in Renoise, I’ve selected the MIDI port as input and created a new sample with a single spike (an Impulse) to hear the events.

Then I’ve done the same in Reaper, triggering a ReaSynth with a Pulse and no attack.

→ Timing, as I can observe it here, is equally good or worse. I can’t hear a fundamental difference here.

Doing the same test with Reaper instead of Live to generate the events, I got some unexpected wonky timing, but the problem here seems to be Reaper and not Renoise. I’ve tried changing some of the timestamp options in Reaper but without success. But maybe I’ve missed something here.

Please Note: When directly playing back MIDI input events, the events can’t be scheduled “back in time”, so even if there is timestamp info, it can’t be used. This means, the higher the audio buffering (latency), the worse the timing will be. This can be easily tested by increasing the audio latency in Renoise and Reaper while triggering the MIDI events from Live. Lower latency = Better timing. So make sure the latency in Renoise and Reaper is roughly the same when comparing the timing.

Raw MIDI Output timing:

The MIDI output timing of Renoise can be tested the same way as described above, but this time using Renoise instead of Live to generate the MIDI events, sending them to Live and/or Reaper.

→ Timing, as I can observe it here, again is as good as in Live from the previous test.

Please note: When sending out MIDI events, the timestamp info now can be used this time to fix timing of events. But On Windows, there’s unfortunately no way to do this at the driver level, so Renoise internally schedules MIDI events in a separate real time thread. This timing isn’t perfect, but it should be very usable at least and definitely should not be influenced by any song settings (LPB/TPL). The Audio latency also has a little impact here, but not as much as it has with the input timing.
Core MIDI on OSX allows scheduling events on a driver level, so the timing here should really be perfect.

@gentleclockdivider can you replicate the tests above with similar result on your setup?
Especially note the first comment about audio latency.

If this works for you, let’s continue the tests and bring in VSTis and test this in detail.

14

I am not sure if the virtual port is the propre way to test this .
Renoise receiving 16th notes is not an issue , it’s the 32nd and 64th notes that cause the issue .
I have created a topic where the TPL most definitly influences the midi timing (internal routing).
You can download a demo of loomer achitect ( it can run as a vst generating midi output ) , load a monosequencer . load a midi out module ( inside architect ) and set it to host
Then adjust the sequencer speed , when it’s set at 1/64 notes , adjust renoise TPL to hear the difference
We def. need someone with a hardware sequencer to test this ( will create a topic for this to measure tests)

15

Fro the other topic about tpl

quote
Yeah, that shouldn’t happen. Trying to replicate this now…

Can you also replicate this when triggering a sample instead of a VSTi with external MIDI?

Yes , I just did , same result the tpl and lpb influences the accuracy , at low lpb some notes are skipped
Didn’t even use an instrument envelope (that’s dependent on lpb ) but a pure noise sample with a destructive fade out

1 Like
16

It still would be interesting if you’re having the same problem in the tests mentioned above. We need to find out step by step what the problem is.

17

I recorded here an external synth, left channel is the live played output recorded in an external audio editor, and right channel is the replayed midi notes in renoise, with lpb 8, tpl 12:

I would say it’s quite a bit off, and more than the tick resolution would explain.

This might be interesting, too: I replayed the same midi recording 2x

In the first pattern playing (left channel), every note which is not on 0, 32, 64 and so on seems to be too late.

The same in Bitwig:

So those extreme offsets are not introduced by my midi connection or synthesizer.

18

@ffx Let’s please not mix up this thread. gentleclockdivider’s point is, that passed through timing of incoming MIDI events in Renoise is wonky. It’s not about recording MIDI into the pattern editor and playing it back. I know this is an important issue too, but please let’s stay on topic here, or we’re ending up nowhere.

1 Like
19

Ok, sorry for mixing up, thought it was the same issue.

20

And @gentleclockdivider

I’ve mainly set up this simple test to point out this:

Which latency have you tested this with in Renoise? It would also help if you could test this with a MIDI loopback device first, so we know we’re getting the same results - or not.

If this is cleared, let’s move on to the next issue please:
Timing of internal MIDI routing - sending MIDI from a Loomer architect VSTi to a Microtonic VSTi in Renoise.

21

Loopback installed and running , enabled in reapers’ midi settings but not available as an midi output in track settings ( will try harder ":slight_smile:
Also , how can you open two programs ( reaper midi master ) and renoise (midi receiver ) without sharing audio drivers ?
This loopback stuff is new to me
Will report when I get it up and running

OK go it running in loomer architect but since architect uses the audio driver , renoise doesn’t output sound ( at least not audible , scopes and vu meters are showing activity ) and there is no way to record it .
Changing the audio driver so renoise uses it instead of loomer architect , no dice …architect doesn’t run without an audio driver

So @ Taktik , the progam that you use for sending midi using loopback , how do you deal with the audio drivers ?

22

O.K
I got it up and running with a litlle bit of out the box thinking
Since renoise didn’t produce audible sound over the dacs but only internally , I recorded the output into reaktor as a vst ( it has a recorder ) , this all worked fine
So loomer architect midi out —>loopback—>midi in renoise
First test , architect sequencer running 1/8 notes , then 1/16,1/32,1/64,1/128
First triggered sound is microtonic , instant attack
Driver assio 4 all set to 10 ms
And why can’t we upload rar’s …we need this for troubleshooting duties
1
2
file download
https://app.box.com/s/o5cu0ugtraswv3fcqpajser18ztqnqri

24

By using DirectSound or ASIO4All. They both can be used at the same time in multiple applications.

Again, my point with MIDI Input jitter, is, that this is influenced by the audio latency. Bigger audio latency = Bigger jitter. But this should apply to all hosts: Reaper, Renoise, Live, Loomer, …

Not saying that there are no bugs in the MIDI routing in Renoise, but we need to make sure we’re testing the same thing. Also this is what you thread initially is about "
MIDI timing in Renoise is bad when getting sequenced externally (by Cirklon 2)".

I’ll look into the MIDI out timing with the TPL settings now.

25

Tested the TPL issue now. Using note delays or a higher LPB. I can’t hear a difference here with different TPL settings. Timing with the Loopback device is okay. Here’s the song I’ve tested with:

MIDI TPL.xrns (4.4 KB)

See again notes from above: On Windows we’re using a software scheduler for MIDI out events. It isn’t perfect, but I’m not aware of a better solution here. On OSX we’re letting Core MIDI schedule the events which should in most cases result into a better timing.

@gentleclockdivider Can you replicate this with the song above? How does the Loopback device vs. the real device behave on your setup?

Looking into the MIDI timing of the internal MIDI routing now (Loomer VSTi to some other VSTi). I’m not familiar with Loomer. Could you share a little demo song here with us?

26

Exactly that’s why I created this thread
The midi loopback is a substitute for the hardware .
It 's perfectly possible that midi timing-jitter is dependent on audio buffers , but as you said every host should then exhibit the jitter …not just renoise
The tests I have done with the loopback device are exactly the same as with the cirklon
Loomer architect is if you just want to set it up
Clink structure view type, add build in :monosequencer
Again : Type midi out : select port , if loomer is a vst , choose host as the output port in the midi out module
Type in : set channel (set channel but you also do tis from within the sequencer ), the module overrides oit )
Click on the monosequencer ,set conduct to play and choose sequencer to play
Everything can be modulated if yo uwish to do so , it’s a great program with rock solid timing
2
3

1