Did you ever want REAPER to send MTC when stopped or paused?
Now this is possible.
The 'virtual Vertical Interleave MIDI Timecode Generator' (vVIMTC Generator) sends Fullframe MTC (SysEx) or Quarterframe MTC when REAPER is in stop or pause mode.
This allows positioning of the edit cursor and a video application follows without the need to start playback or recording.
The vVIMTC can also send Quarterframe MTC in playback or recording mode.
Put it on an empty track, record arm the track, set it to 'Monitoring, Not Recording' and choose a MIDI output in the track's I/O screen.
Don't forget to set the proper framerate in the plugin AND the project settings (and if neccessary in the slave application).
This is my first JS, so please put it through it's paces and tell me if you find some bugs. (Thanks to mbncp for the help and some code)
I tested it with MIDIox, a spawned instance of REAPER and an old MIDIman synchronizer - no problems so far.
Sony Vegas doesn't seem to like Quarterframe MTC when stopped or paused and doesn't understand Fullframe MTC at all.
Perhaps we can put together a list of working applications and equipment in this thread.
This is amazing!!!
I'm just working on a little "Music-to-Video-thing", and it works absolutely great!
I was never quite satisfied with syncing to LTC...
Cheers excellent plugin, works a treat and solved an issue that I had with the inbuilt MTC in reaper that for some reason wouldnt let my automation run on my Tascam DM24, its working a treat now
Great job, man - though I have one question:
I did everything like you described (track armed etc.) but I can't get the signal sent over a Ethernet Midi network on different computers.
What I did: I set the IO to "MidiYoke8", which is the input for Ethernetmidi. But there's no signal transmitted (a green "light" would indicate this). With any other signal, it works.
Or is there a workaound for this, via ReaStream or similar??
Hmm, i had no problems so far when MIDI-Yokeing the timecode to other applications.
Probably a dumb question: Did you move the cursor? Timecode is only being sent if the cursorposition is changed (by mouse or via play/rec).
Other than that i have no idea what the problem might be.
Can you make a test with MIDIox or a second REAPER instance?
Well, the problem seems to be related to some unexplainable "midi feedback". Now i could set up both computers to monitor the signal within the EthernetMidi window at least. But Midi-Ox' monitor shows feedback, i guess, on more or less all inputs, and when I exit the program, the notification window "Midi feedback detected" would show up! I really don't have a clue where the loop might be (Reaper's inputs are set to Yoke 1 and 2, outputs are set to 3 and 4)?
In one of the recent updates REAPER's behaviour was changed and you don't need to rec arm and monitor the track anymore.
I think there was an option added somewhere to make a MIDI plugin merge it's output data with an incoming MIDI stream or block the incoming stream.
Maybe that's why rec arm and monitor is causing feedback now?
(I haven't noticed that here though.)
I go hunting for that option now and be back when i found it and know more.
OK, the merge MIDI feature is on a per instrument basis and has nothing to do with your problem.
The code of the timecode generator doesn't contain 'midirecv()', so incoming MIDI is passed through the plugin.
Perhaps i should add a midirecv() to block incoming MIDI.
OTOH as there is no need to rec arm/monitor a track anymore, incoming MIDI is blocked automatically.
If your feedback problem involves the timecode generator track, try unarming the track and turn the monitor off to break a potential loop.
And finally it turned out that "Ethernetmidi" was to blame (as was "Netmidi")! Those apps will totally mess up the sync data, so there is "something" that's being transmitted, but those bits are definitely no timecode. Do yourself a favour and use "Wac.NetworkMIDI". Works like a charm!
AND SO DOES vVIMTC! Blechi, this is brilliant! And I owe you a beer for your help and analysing! Cheers!
A bug in the JS system prevents the 'play_state' variable from being updated correctly if the track is not rec-armed.
The result is that the state of the pause button is ignored.
The solution is to set the vVIMTC track to 'Record: disable (input monitoring only)'.
You can confirm the issue here.
Hope that'll get fixed soon.
I spent the week-end struggling to find info on synching 2 PC and the final step is apparently to get "wac.NetworkMIDI"... the problem is, I cant find it anymore. The link is dead and no way to find it somewhere else.
BEINGMF, would it be able for you to send it me or to put this promising software somewhere on the NET?
Hi Blechi - thanks for your plug, its a great idea I wish Repaer would implement.
Im having weird issues and wondering if you can help me. On my Tascam DM4800 it takes about 10-15 seconds to 'lock' to the incoming MTC, and then the faders jump into place and begin working as they should. No matter where I start playback from, that same issue.
Also, after a short period of time I get weird project slow-downs and near hangs when your plugin is armed. If I remove the track with your plugin on, the problem goes away. I noticed the pluging GUI seams to very slightly shimmer erratically too, like its trying to send information. Almost as if its creating a midi feedback loop or something. I have read that you dont need to have it armed in rec mode now, and its not.
i have no clue why it takes 10-15 sec until your DM4800 locks to MTC.
Do all the framerates match? (project, vVIMTC, DM4800)
Does the DM4800 lock quicker/at all if you use a SMPTE/MTC-generator item instead of the vVIMTC?
('Insert' -> 'SMPTE LTC/MTC Timecode Generator')
Do you use 'normal' MIDI or some MIDI over LAN thingy?
(beingmf had problems with these as you can see some posts above your's)
To break a possible MIDI feedback you can try putting 'JS:MIDI/midi_eater' before the vVIMTC in the FX chain to block incoming MIDI data on this track.
The slowdowns etc. you mentioned may be related to MIDI feedback, although i didn't notice such problems here yet.
The vVIMTC track has to be record armed ('Record: disable (Input monitoring ony)') because otherwise the JS engine doesn't recognize the state of the pause button (already reported this as a bug and i hope it's being fixed some time).
How does the DM4800 behave when playback is stopped and you move the cursor? Does it lock? Do you use fullframe MTC or quarterframe MTC?
hi, thanks for your detailed response. Ive been working my way slowly through all the scenarios.
Quote:
Originally Posted by Blechi
Hi Jacko,
i have no clue why it takes 10-15 sec until your DM4800 locks to MTC.
I timed it - 15 seconds to lock, or start automation playback. It then drops lock at 1:15 everytime, and the desk starts doing weird stuff (constantly writing automation data to the save file). no matter where I start playback from, always the same, 15sec till anything moves, 1:15 it all goes haywire.
Quote:
Originally Posted by Blechi
Do all the framerates match? (project, vVIMTC, DM4800)
Does the DM4800 lock quicker/at all if you use a SMPTE/MTC-generator item instead of the vVIMTC?
('Insert' -> 'SMPTE LTC/MTC Timecode Generator')
Do you use 'normal' MIDI or some MIDI over LAN thingy?
(beingmf had problems with these as you can see some posts above your's)
Yeap, all settings are correct. Im using bog standard USB MIDI.
Quote:
Originally Posted by Blechi
To break a possible MIDI feedback you can try putting 'JS:MIDI/midi_eater' before the vVIMTC in the FX chain to block incoming MIDI data on this track.
The slowdowns etc. you mentioned may be related to MIDI feedback, although i didn't notice such problems here yet.
Cheers for that, its fixed the hanging issue. Ive got some crazy configuration issue here as the desk needs to use USB port 3 to receive MIDI for MTC, but send MIDI for the remote control. Ill try to work out how to assign different ports. In the mean time that JS plug works just fine.
Quote:
Originally Posted by Blechi
The vVIMTC track has to be record armed ('Record: disable (Input monitoring ony)') because otherwise the JS engine doesn't recognize the state of the pause button (already reported this as a bug and i hope it's being fixed some time).
Mmmkay, doesn't change anything though.
Quote:
Originally Posted by Blechi
How does the DM4800 behave when playback is stopped and you move the cursor? Does it lock? Do you use fullframe MTC or quarterframe MTC?
Yes, it shows the correct TC location on the metrebridge when I move the cursor. Im using quarterframe MTC Always.
Im not suggesting its your pluggin at fault, Im sure If got crazy-wrong settings or something buggy over here, but if anyone knows about it Im hoping you do.
Just an update - turns out the automation is a lot smoother now with the little JS MIDI Eater inline. Theres obviously some weird stuff going on somewhere that's feeding back via the USB.
Also: The drop has dropped if I dont start from 0:00!! I still have the 15sec pause before anything happens which makes the faders suddenly jump into place, but if I start a little into the project, it doesn't drop out. I can run automation continually.
Please try a SMPTE/MTC-generator item as MTC source instead of the vVIMTC to test if the DM4800 syncs quicker.
('Insert' -> 'SMPTE LTC/MTC Timecode Generator')
* ATTENTION: Due to a bug (?) in the JS system the track that contains
* this FX must be RECORD ARMED! Set the track to 'Monitoring, Not Recording'.
* The generator does not work if it's track is muted or other tracks are
* soloed.
* The SOLO restriction can be worked around by creating master/slave
* solo groups and putting the generator track a solo slave in each
* group.
I have, it dosnt work. It makes the metrebridge TC count, but the automation engine don't even see it.
Is there a change in the DM4800's behaviour if you use the normal 5pin MIDI connections instead of USB-MIDI?
Quote:
Originally Posted by steadyrev
* ATTENTION: Due to a bug (?) in the JS system the track that contains
* this FX must be RECORD ARMED! Set the track to 'Monitoring, Not Recording'.
* The generator does not work if it's track is muted or other tracks are
* soloed.
* The SOLO restriction can be worked around by creating master/slave
* solo groups and putting the generator track a solo slave in each
* group.
Does the new SOLO SAFE make the work around void?
Didn't try that yet, but with the new SOLO-Defeat function the workaround shouldn't be neccessary any more.
just made a quick test with Reaper (v3.52) & MIDI-OX:
- the vVIMTC track still must be record armed ('Monitoring, Not Recording') to work properly
(Maybe you can confirm the play_state bug here, so this gets fixed some time.)
- the vVIMTC track must be set to 'Solo defeat' to be able to send MTC regardless of the solo state of other tracks
- master/slave groups for soloing are not needed any more
- of course the track doesn't send anything if it's muted, so don't mute it.
It should be possible to send MIDI clock/SPP, although conversion MTC->MIDIclock seems to be unnecessary complicated.
It's easier to write that thing from scratch.
I'll give it a shot when i find the time.
You'd have to be the guinea pig, because other than MIDIox i have nothing at hand for testing.
I've just started using Reaper, and will be needing the use of this plugin to generate timecode. Being that I am new to much of this, I need to know exactly how to put this plugin to use.
1. When copied into the appropriate folder, it keeps the .txt extension and not "File" like the others have...not sure if that is a problem.
2. Applying it to the project: do I add a blank track and apply this FX/plugin. Or, is this plugin designed to be used in the effects chain with the inserted Reaper SEMPTE Generator.
this, sir, is totally awesome.
a heap of thanks for that!
works great with the "mtc video slave"-software, making reaper an even better DAW for film and video works.
I'm positively astounded!
:')
(btw. i use this with the aforementioned program, along with midiyoke. works great, due to midiyoke being limited to 32 bit only on reaper 32 bit. in case anyone searched for this.)
Hi there! Sorry for reviving this old resting thread ;-)
First off: thanks a lot for that plugin! I'm using it to sync my Euphonix CS2000 console to REAPER, and for the most part, it works.
Here's the catch though: When in "STOP mode" (play_state 0) REAPER only sends a full frame MTC message every 4 cursor movements, e.g. I click somewhere inside the timeline, nothing happens. I click a second time (must be a different location): nothing. A third time: nothing. A fourth time: success! And then the cycle repeats...
When in "PAUSE mode" (play_state 2), clicking around seems to send a full frame MTC message every time. I write "seems to", because I'm not at the studio right now, but just discovered this behaviour on my Notebook, which isn't connected to anything.
This behaviour can be monitored through REAPER's track metering, where it shows MIDI activity. Same behaviour on my studio PC, as well as on my Notebook.
I'm wondering, since the plugin doesn't distinguish between stop / pause. It rather checks if play_state is 1 (PLAY) or not.
Does anyone have a clue or a workaround?
Last edited by TeaBone; 08-16-2019 at 09:20 AM.
Reason: typo
I'm trying to modify this to run 23.976 but in my efforts the stopped position while in "quarter frame always" is a full second off. Anyone know how to fix or properly modify this for 23.976?
Currently all I've done is removed the 25fps and modified to slider 1 == 24/1.001 and relabeled. I'm sure it's a bit more involved than that.
Mine updates on every 7 or 8 movements so perhaps it's not a hard-coded thing in Reaper. I'm wondering that because the code relies on updated sampleblock to update the position, maybe Reaper doesn't update that with every cursor reposition when the transport isn't rolling. This might explain why it works as expected while the transport is paused. I don't really know but I'm sure someone here does.
One possible workaround that might alter ones workflow a bit is to use scrub rather than frame forward and back keycommands. In scrub the frames update every time.
Also interesting that in quarter frame mode video wobble constantly and every cursor move updates MTC correctly, maybe it’s because of its constant wobbling- scrubbing?
sorry to resurrect such an ancient thread, but I'm also having trouble getting vVIMTC Generator to work properly in 23.976.
If another Reaper instance (on another computer) is the follower device, I can get it to track accurately if I set the option "24/30 fps MTC is 24/30 fps MTC" as opposed to "24/30 fps MTC is 23.976ND/29.97ND if Project is ND" (which is what I would expect.
If I want to have my reaper session follow a different DAW or MTC generator running at 23.976 (Pro Tools, for example) I have to have the option set the other way. So, it's functional, but I have to remember to switch this option in my follower machine when switching Leader applications ... I hope this makes sense. Anyone else using vVIMTC Generator and seeing this?
Hi all,
I saw this thread and remember I had same issue so I added some options for ND,
It had to do with actually dividing current position to 1.001, and making sure the right framerate is sent thru MIDI.
I didn't have luck running it smoothly with Video Slave back then.