|
|
Member
Posts: 15
| Recording midi from revisit with loopbe into another track inside of ableton live 8.1 is working okay, but the timing is off a small amount. Doesn't seem to have anything to do with loopbe, as even midi recording directly to host is displaced slightly. Is this expected? Is there anyway to get ableton to compensate automatically? |
|
| |
|
Expert
Posts: 512
Location: Netherlands | Are these timing errors within the few ms? There's a slight delay each so-many ms in Cubase SX3 because Cubase was never made to allow plugins become sequencer.  LoopBE's timing errors are even slightly bigger (I have the full LoopBE with its 30 MIDI devices). The LoopBE timing errors become obvious when exporting as wav in non-realtime mode, then the timing it just horrible. Hence I export using realtime mode.
At the moment, supertight hihats are not really doable for me. So what I intend to do is to actually record reViSiT's output into Cubase so that I can quantize its output. Yes, that causes a problem with subrow effects (arpeggio, note delay, actual subrows, retrigger). Maybe.. one day, when reViSiT can save as a .mid from within reViSiT... ^_^ |
|
| |
|
Member
Posts: 15
| It's not very much, and yes I can quantize it to fix the timing errors, but it seems unnecessary, I've used other midi plugins and any sort of delay from the plugin was compensated properly. VSTs have a mechanism for reporting delay back to host for plugin compensation, is this being utilized with revisit? If so it doesn't seem to be working properly...if not, well new feature request please :D
Oh, I'm using loopbe30 as well, and I don't think it is adding any perceptible overhead in ableton (Comparing midi recorded directly to host as well as through loopbe30). I'll try to directly compare.
Edited by zeekay 2010-01-20 2:44 PM
|
|
| |
|
Developer
Posts: 746
 
Location: England | Hmm, this sounds much like the problem here:
http://www.nashnet.co.uk/forum/forums/thread-view.asp?tid=3184&posts=7&start=1
It seems related to Ableton's plugin delay compensation, which presents a problem for external MIDI messages. The issue is that the host is causing these messages (e.g. on LoopBe) to happen early, because it thinks everything to do with plugins needs delay compensation. Trouble is, when the host receives the MIDI from LoopBe, it has no idea it came from a plugin, so doesn't delay it. reViSiT has a MIDI Delay setting, but this doesn't appear to have any effect, according to the other thread. I'm not sure why this is, but I'm looking into it.
Can you confirm that it's always a little early? If so, the workaround is to add a MIDI delay, in the host - quantising it shouldn't be necessary, and might interfere with note-to-note timings. If Ableton supports VST MIDI, can you try the "VST Host" MIDI device, in reViSiT. Does it have the same problems?
Cheers,
Chris |
|
| |
|
Member
Posts: 15
| It's not early, the notes are all delayed...It's present when sending directly to host, loopbe30 does add some additional overhead when I use it. It seems to be directly related to the buffersize. At a buffer size of 2048 samples and 100bpm it's a bit about a 64th note late (I normally use a buffer size of 60 samples and isn't terribly bad in that situation). At a bpm of 200 this causes everything to start over a 32nd note late. It seems like revisit doesn't report it's internal latency properly, which causes ableton to fail to compensate.
Edited by zeekay 2010-01-20 5:38 PM
|
|
| |
|
Member
Posts: 15
| Actually...loopbe30 seems to be pretty irregular at 2048 samples...I'm getting really messed up midi back in...I'll continue to look into this stuff.
Edited by zeekay 2010-01-20 5:40 PM
|
|
| |
|
Developer
Posts: 746
Location: England | Another thing CS_TBL and I discovered a while back is that Win32 Multimedia Timers aren't all they've cracked up to be - the claimed accuracy of 1ms is rarely attainable, and I think there might be a problem with LoopBe being software, and in a different process to the host. Something like the host only being able to process LoopBe MIDI at specific points in time, around the times its busy with its own stuff, leading to irregularities in the timing. One way to test this would be to try a hardware synth from reViSiT, or the "VST Host" internal MIDI connection to the host - and see if at least the irregularities go away. There's another class of timers, Waitable Timers now being touted as the gold standard for Windows, and I'm hoping to have a crack at them when I have some time.
As for latency, reViSiT doesn't really have any, except for built-in latency of having to do a buffer of audio at a time, the length of which is set by the host. Have you messed around with the MIDI Delay setting at all? |
|
| |
|
Member
Posts: 15
| Within live, or within revisit? I've tried adjusting track and midi port latency settings but neither seemed to have any effect. Is there a midi delay setting in revisit? You wouldn't happen to be on IRC somewhere would you?
Edited by zeekay 2010-01-20 6:03 PM
|
|
| |
|
Member
Posts: 15
| This might be impossible, but is there a way you could add a midi-only option to revisit, so that it wouldn't buffer audio? I'm using the sampler that comes with live directly through revisit, I will personally be using revisit ONLY for midi. A midi mode would be nice for people working in a similar manner, if it'd alleviate these timing errors.
Edited by zeekay 2010-01-20 6:07 PM
|
|
| |
|
Developer
Posts: 746
Location: England | The MIDI Delay setting is in reViSiT's Preferences (F12) page. It defaults to Auto, which is the length of the audio buffer, but it can be set from 0ms to 1000ms, if I recall.
reViSiT cannot switch to being a MIDI plugin, because it is a completely different plugin architecture (and somewhat less well-supported by Steinberg). Hence, we're always going to have to handle music in buffers.
I am sometimes on IRC, as #gnasche on Rizon, but usually only "by appointment". Unfortunately, I'm a bit busy today, with data analyses, so we'd best stick to forum stuff. It also has the advantage that others will see the problem and its solution, should we find one. |
|
| |
|
Member
Posts: 15
| Ah found it! Yes setting the midi delay to 000 fixes it, when sending midi through host :D
Unfortunately the issue still persists with loopbe30, though...is it possible the MIDI delay setting is not working with external midi?
Alternatively, I've noticed when routing midi through live directly that I can't select channels as input with revisit. Normally I'd be able to select midi input from revisit, and then select the channel I want to use as input, but no channels are listed for some reason. If that worked, I could at least output midi to 16 distinct instruments (one for each available channel)
Edited by zeekay 2010-01-20 6:31 PM
|
|
| |
|
Member
Posts: 15
| Actually it seems to be a problem with live. It combines all the midi output from a given plugin and routes it into channel 1. This is why I can't select a specific channel to use from revisit. Not sure of any work arounds there. I wonder if loopbe30's performance can be improved at all 
Edited by zeekay 2010-01-20 7:17 PM
|
|
| |
|
Member
Posts: 15
| External midi output is not effected by midi delay setting in revisit. Potential bug, or was this done out of necessity? |
|
| |
|
Developer
Posts: 746
Location: England | I guess it could be a bug, if it's having no effect at all, but I think the delay is applied to the MIDI message before reViSiT splits it off between VST and external devices.
Thinking about it, it probably is something do with Live's plugin delay compensation - it's probably delaying the LoopBe MIDI In to account for the plugin delay. However, reViSiT already does this. I'll take a look when I can - it'd be nice to get to the bottom of this, even if it is something funky in the host. |
|
| |
|
Developer
Posts: 746
Location: England | Okay, I found a bug that was disabling the MIDI delay for external MIDI messages - this affected not only the Preferences setting, but the timing of some notes in general.
I've also had a thorough going-over of the timing code and have managed to improve external MIDI timing quite significantly. One of the problems is that the delay between the processing and the time sound is heard is not constant - nor even available. For example, processing might take longer at some points, compared to others. For audio and internal MIDI, the host holds everything back until it's ready to be played. For external MIDI, reViSiT is forced to schedule the notes, while it is processing. So, reViSiT now attempts to time the intervals between buffers being processed, so that it can estimate and incorporate the delay, and hopefully improve the sync.
I'll make a new version available in the next few days, with this and a couple of other tweaks.
Best,
Chris |
|
| |
midi recording from revisit has timing issues
