I did some further tests , but this time NOT the midi in , but the midi routing inside renoise
So not using the cirklon.but a vst that sends out midi note data to another vsti
The vsti I used for sending midi is Loomer architect ( a modular midi environment ) with rock solid timing , sending midi note data to microtonic
Same procedure used in reaper and architect (standalone )
Renoise suffers when note resolution is 1/128 , yes that is pretty fast but it shows there is an underlying issue with midi in geneal , even when routed internally
Other hosts, reaper and loomer architect standalone have no issues at all with note 1/128 resolution .
Notice the double notes in renoise (green )
EDIT : it seems that the ticks per line (song settings ) influences the internal midi routing resolution
By default it was set to 12 , increasing it to 16 improves it but it’s nowhere near as good as the other hosts
The last test is moe advanced , again same procedure but the triggered sound is a decaying impulse ( no envelope )
I also switch the tpl settings .
So first architect stepsequencer plays at 1/16th ,1/32 ,1/64,1/128 , whil renoise tpl is set to 1
Then renoise is set to tpl 2 ( same procedure in architect )
Followed by tpl 4,8,12,16
Conclusion , the tpl is not influencing the midi in ( while it does in internal routing , let’s tackle that later )
The midi timing is still off
taktik ,please download the demo of loomer architect for easier trouble shooting
If there are other examples needed. I’ve upload a test song done with Xfer Cthulhu. I did compare Renoise with FL Studio, both with direct sound driver. In FL the note offset is the same, but in Renoise its jumping. This causing sometimes missing notes and the overall arp feels “swingy”. Have this issue with several arp VSTi’s like BlueArp, Cthulu and so on. And as far as I have experienced, it getting worse, when you use phrases.
I can replicate this now here. The timing of every nth note is shifted by some samples. This only happens when routing the MIDI output of a VSTi to some other VSTi. It does NOT happen when routing the MIDI output of a VSTi to a sample in Renoise.
Unfortunately it will take a longer while to figure out what’s happening here, but I’m on it.
I also still can’t replicate the other issues mentioned here. @gentleclockdivider Did you manage to run the tests with the loopback device at the end?
Probably someone else could help testing this issue as well (MIDI input jitter).
Yeah it seems you are right. The reason why its unstable even with samples for me, was the static processing buffer flag. I thought this would fix my midi timing for internal routing, but its getting worse. Cthulu doesn’t like this. Bluearp works fine with both:
(green static buffer disabled = everything fine, red static buffer enabled = bad timings)
Edit: It seems, forcing static processing buffer to the target VSTi, which will be triggered by Cthulu, does improve timing. Maybe, this is one of the reasons why Renoise midi plugin timing is broken. The gate parameter in Cthulu is set to play the whole 16tel note and it seems Note off’s are too late and prevent to play the next note. With enabled static processing buffer in Xfer serum, it happens not so often.
Test song with Xfer Serum and Xfer Cthulu. check that Cthulu and Serum doesn’t have static processing buffer enabled. Hit play, go to serum and play with the static processing buffer setting. midi-static-proc-buffer-xfer-plugins-vsti.xrns (12.5 KB)
Yes, I have run them and reported them in this thread untill the loopback device decided to go hayware , but during the tests the results where the same as when using the cirklon .
The issue remains the same.
Regarding the internal routng of vsti to vst., the shifting is not just by a few amount of samples but rather milliseconds , 8 milliseconds to be precise
It’s also doesn’t matter If the destination is another vst or a renoise instrument .
Anyway , it’s great to have your attention on this issue
Perhaps I can create an additional topic ans invite people with hardware sequencers to join , as long as the hardware sequencers are tight .
Will be united with my cirklon this monday
O.K so I did the internal mid routing test again
Loomer architect triggering a renoise instrument , tpl is set to 16
The renoise instrument has a fader applied in the instrument amp section , with a decay of 20 milliseconds
Results are just bad at high pattern speeds ( set in architect vst ) , I am wondering if we are using the same software at all ?
At 1/32 the fader envelope isn’t even correctly processed , increading the speed makes it even worse
Audio is in the renoise file jitter.xrns (1.9 MB)
I think I am experiencing a similar issue, sending MIDI out through LoopBe using a VST in Renoise, and then recording that MIDI into another instrument track in Renoise. When simply playing, the sound/data appears to start on the very first line. However, when I press record, there is a delay of a few lines before the returning data starts recording. I would love to learn how to fix this delay, if such a fix is available.
All I can say is that renoise now perfectly accepts fast midi note input streams from external hw sequencer , no problem with 1/32 ,1/64th notes ,al evenly spaced and no jitter .
As always , taktik did a great job !
That’s great news. In the meantime (running version 3.1 on a 32 bit system), reducing the audio latency based on the other comments here on the forum seems to have solved my immediate issue of the recording not beginning immediately (i.e., on the first line) when using VST sequencers looped back through LoopBe .
.