I have a 55 minute video loaded up into Simpler. While using my machine even outside of Live and Videosync (playback also off) my computer crashes randomly. As soon as I remove the Simpler containing this video from the set this stops happening. Of course if i use a simpler with a short video (tested randomly with a 3 mins one) this doesn’t happen. No LFOs on any of the parameters or anything like that.
Could this be because the first video is too large for simpler? either way is there an error message in place to prevent us from dropping in too large a video / what is the max length/size?
<3,
Anna
Hi Anna, welcome to the forum!
Indeed, Simpler is not really meant to be used with long duration/high resolution videos. That’s what we’d recommend using an audio track for in Session View or Arrangement View.
This is because in order for Simpler to be able play video instantly when triggering MIDI, all video frames between the set Start and End time are loaded into (GPU) RAM. Since videos are compressed files, they are also decompressed before loaded into RAM, which increases their file size and RAM consumption. If you’d open the macOS application Activity Monitor, you’d probably see a high amount of RAM pressure (yellow/red), and naturally this is something that can cause unexpected behavior. So it’s always good to minimize RAM consumption, hence the existence of the Start/End time parameters.
Only videos encoded using HAP are not loaded into RAM for Simpler, as this is a codec that is optimized for long/high resolution video playback read straight from the hard drive. But HAP also has its downsides, so we only recommend going this route when there is no other way.
Have you considered using a clip slot on an audio track to play back your video?
Hey Jean Paul, thanks for your reply!
This is clear to me.
I think you should implement an error message when a user tries to load a video that is too long. This could be dependent on the RAM capacity, although when we programmed something similar at Ableton, we set a hard-coded limit based on smaller RAMs, because of course you want a Live set you made on a powerful machine to be able to open on one with less capacity (obviously there are limits to that philosophy, too). Anyway, something to think about…I mentioned the LFOs because I thought maybe it matters if i’m scrubbing outside of the video or something 
For this particular use case it would be perfect to use Simpler slice mode instead of chopping manually. I was using MIDI notes with a little bit of randomization to play back a part of the video every 16th note. It looks super cool until it crashes 
I’ll look into HAP! Or try to cut my video to match my RAM capacity (although, it is 96 GB while my video is only 3.7 GB…so that’s kind of weird…)
…After writing this message I repeated my activities while watching memory usage on the Activity Monitor. When I loaded the 1hr video and then maxed out the end time it was VTDecoderXPCService which started using more and more and more RAM…Going up to reading 150GB before I shut down Live to prevent the crash. For my own understanding I’m very curious why so much RAM is needed?
We tried implementing such an error notification/limit into Videosync’s Console when Apple Silicon first launched, as at the time my M1 Macbook Pro would completely freeze and would require a hard reboot whenever I’d let Simpler max out the RAM, but couldn’t reproduce the same on my Intel Mac. It turned out it was quite hard to finetune when the limiter would take effect and the RAM pressure notification would appear, so it was pretty unreliable.
After some time passed, we weren’t able to reproduce the issue anymore, likely due to macOS updates, as macOS will now throw an error itself, saying the computer can’t continue to function unless the RAM hungry application is closed. So I think the crashing was just due to teething issues with M1 and Big Sur. Because of this we decided to drop implementing an error notification ourselves, and use the Start/End parameters to make it less likely excessive amounts of RAM are consumed. I think there is room for improvement for how this is communicated in the manual and in parameter info texts.
I wonder why the macOS error hasn’t happened for you though. May I ask what macOS version you are on?
Regarding understanding why so much RAM is needed for Simpler:
I’m assuming the file you’re using is encoded with h264, which would mean it’s a heavily compressed file. In order for Videosync to be able to instantly play the correct frame whenever you hit a MIDI note, the video has to be loaded in RAM uncompressed (this is the VTDecoderXPCService process you mentioned).
I personally actually have no idea how big such a file would be when it’s fully decompressed, or how to calculate that, so I asked ChatGPT 4 if it could make an estimation, and it could! I can’t verify its calculations, but given the assumed parameters (55 minutes, h264, 1080p, 24bit per pixel, 30fps), the estimated resulting file size would be 573.6 GB.
As ChatGPT nicely puts it:
This significantly larger size compared to the compressed file size (3.7 GB) illustrates the effectiveness of video compression methods like H.264 in reducing storage and bandwidth requirements.
You can read the full conversation here.