Newbie: A 7 minute movie demo - I'm making a movie wrong w/Ebosuite - please set me right

Here’s a link to a 7-minute screen shot movie showing my wrong-headed approach. It’s on my site, I vouch for the file. Try refreshing the page, or right-clicking and going directly to the MP3 file URL if the video doesn’t load up.

I’m trying Ebosuite as a video editor for a movie made out of a 400 Jpg files, just crossfaded one to the next. The movie will be about 15 minutes long when it’s done. Ebosuite works fine, but it doesn’t scale up to that many eSamplers-inside-drum-racks very well.

I’ve got an 18-core iMac Pro with 128 GB of RAM, running Mojave and Live 10.1.

The first part of the movie shows a set with about 150 slides in it – which takes about 8.5 minutes to load and puts Live into a pretty-high CPU state.

I thought maybe splitting the drum racks up might make things go easier and the second part of the video shows that it doesn’t really – 64 eSamplers spread across 16 tracks of drum racks takes about 3 minutes to load and still makes Live work pretty hard.

Does anybody have suggestions? The workflow is…

  • string 400 JPGs end to end with crossfades
  • create a composition to complement the slides
  • adjust sequence and timing of slides (and the timing of the music)

I could use help with either:
a) reducing the CPU footprint of my Arrangement-view workflow, or
b) stringing together 400 eClips in Session View in a way that allows me to adjust
the overall length of the video and the music at the same time.

Hi Oconner

Try reducing your buffer size 512 or more in Live and test …

Hi FrankyDS

My current audio buffer size is 512k. I’m a little confused by your suggestion – reducing it by 512 or more will result in zero buffer. Or did you mean to type “increase” buffer size? I’m asking because each test will take about twenty minutes to load. :wink:


I’m working up a series of use-cases to see if I can figure out where things break and came across a crash that I can replicate. Here’s the formula that I use to recreate the crash:

  • Shut down and restart computer
  • Create Live set with 1 MIDI and 1 Audio track
  • Drop empty drum rack on MIDI track
  • Drop eSampler on C1 key in drum rack
  • Set eSampler Attack and Release to ~500ms
  • Set eSampler to Looped Playback
  • Option-Drag eSampler to C#1, D1 and D#1 slots in drum rack
  • Load (8 MByte) JPGs into eSamplers

Now that the set has been prepared, here’s how to recreate the crash:

—> Toggle “Load in RAM” setting from off to on in any of the eSamplers

Here’s a link to the crash report. I vouch for the file, it’s a zipped cut/paste text file version of the Apple crash report.

Sorry I meant increase …

Hi OConnor,
Sorry for my late reply. Because the eSampler is an advanced video sampler it will increase load time when you use many of them in a Live Set. Therefore we made the eSimpler as a much lighter alternative, in case you need to trigger many video samples (or jpg’s in your case). Did you try to use the eSimpler?
We are aware of the crash that happens when you turn on Load in Ram for a image file. That will be fixed in the next update. Thanks for the report!

Increasing the number of samples in the buffer from 512 to 1024 finds the sweet spot between reducing CPU load vs latency when playing keyboard instruments. Thanks Franky!

I looked at the eSimpler but couldn’t figure out a way to replace the fade-in/fade-out (ie crossfade) capability of the eSampler. I want (in Arrangement View) to be able to vary the length of the notes playing the slides and have the crossfades move with those changes in note length (just like eSampler). Any ideas would be most welcome.

By the way, I have a new crash report for you. This was a crash while loading my big test set, so I don’t have many clues what causes it. I can replicate the crash and would be happy to provide you with the test set but it explodes to 10 gBytes if I roll the photos into the set. Interestingly, allowing Live to restart after the crash and then reattempting the file-load operation succeeds.

Here’s a link to the crash report