I’m trying to build a patch for video scratching using MIDI controller no. 12 and the scratch performance is erratic, meaning, I’m only capable of working very slowly with the MIDI controller. High scratch speeds cause very bad behavior.
I’m using MJPEG codecs with keyframe every frame for best scratching performance.
I’ve developed video scratch solutions with other languages before, so I’ve been trying similar technics, but maybe they aren’t suitable for vvvv. For example, you may see my Gephex-based MIDI scratch system (VJ Tailor is my VJing alias while VirtualFlavius is used for research)
Attached is the barebones patch, I’d appreciate it if you could please check with your own videos and provide your ideas on how to make it behave better.
I actually think the problem is with the MidiController On Data and FileStream module Do Seek relationship. From what I’ve noticed, the On Data keeps sending a 1 for a very long time. I have to work very slowly with the controller in order for it to send a 0, which triggers the Do Seek on the FileStream.
you could trigger the DoSeek pin with a Change (Animation) node connected to the MidiController output. i saw that the Buffer Length pin on the MidiController node was set to 100 in your patch. set it to 0 an you should always get the latest value of your controller…
First off I must say you guys are great and thanks a million for your help.
I think I’m almost there, but I have a misunderstanding about how th buffering mechanism works.
Check out the attached patch and you’ll see that the movie is playing from slice 0 provided by the buffer. I guess I’m not experienced enought with vvvv to realise what’s going wrong here.
Take a look at the patch please and tell me what you think.
If you look to the helpfile from the buffer node, you see that you need to fill the buffer before you can use it.
To fill it, you know totall amount off frames and length off the movie. Create an LFO off the movie lenght, map it to the number off frames. and use it for slice index and insert for the buffer node.
Does the MIDI output (slider or rotary knob??) gives you a value off 0.0000 t0 1.0000 ?? (I dunno, can’t test it atm)
I patched it for you, but it is a bit dirty (remapping an LFO for a counter, at low framerates doesn’t work well). There is also still one bug.
My ‘run an LFO 1 cycle’ makes the buffer clean the first few frames, because it stops to late. any suggestions??
Anyway, I hope this is what you where looking for, but I would also have said like tonfilm, use the ‘do-seek’ pin to scratch through movies.
EDIT:
Hmzz… seems you cannot Post 2 times in the same thread.
Ahh… well, also posted the other (better) way for video scratching.
First, thanks for you interest and proposals. I appreciate it and I hope this thread would benefit all of us.
The basic video scratcher is somewhat identical to my initial proposal, but it doesn’t solve the erratic behavior problem.
MidiScratchWest.v4p above looks like a good development of the buffer suggestion before, but regretfully it doesn’t seem to work on my system. Did it work for you?
Well, I have a feeling the buffer solution is the way to go, like before, but still don’t have a working example. Sometimes I wonder why such simple tasks are so difficult to accomplish.
OK I havent actually checked your solutions, but I’ve scratched with mjpg avi’s, but maybe I didnt have such high standards, so what exactly is the erractic behavure you get?
1 thing you should not that if you use do seek with an avi file, you need to make sure that the play pin isnt enabled, this is a bug (i think from 9 onwards) or an anomily at least, if play is checked it tries to play and do seek at the same time, and it goes a bit weird, so a not node with the do seek would help.
I’ll maybe try later with a short avi, all on my laptop are too long for scratching really!
I’ve also had latency problems with my midi controller, is it this you experience?
Also Hard drive speed would make a difference!
