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

Help, Support & Bugs
1

I love renoise but this is more of a rant about renoise being a vst host , iow instruments and vst’s being sequenced from hardware
I have one of the finest/tighest hardware sequencers on the market , cirklon 2
I didn’t even use the cirkloon usb out but the physical midi out and using the roland integra as a midi interface
Here is a project with two files , first reaper being the host , the other renoise
The instrument being controlled is a single microtonic channel .
Sequenced at 140 bpm , first the sequencer doing 16th notes , then 32 the notes and lastly 64 th notes
Renoise just struggles with the input , even noticeable at 16 th notes .
Reaper otoh is supertight
Will do some more testing with other hosts , but damn this is bad

Edit added a new file , both alligned to see the actual jitter
Left channel reaper (upper ) , right channel renoise (lower )
Noppes can’t do , filesize too big ( even after rarring )

exceptionally bad.xrns (3.8 MB)

1 Like
2

1
2

3

Testing loomer architect ( one of my favourite programs )
Handles the dense midi input without any problems
C’mon developers , fix this

4

Yeah I have to say, I’ve lways had latency difficulties with Renoise but have ended up making it work somehow…mainly recording the audio then chopping it after.

If it was a live situation it would be more difficult to resolve this. I feel your pain!

1 Like
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 ?