Ableton Forum

please download this live project : http://dl.getdropbox.com/u/174493/getCl ... roject.zip
it contains a MFL device "getClipsNames.amxd" (in track 1)
This very simple device fills a jit.cellblock with clips names from the 8 firsts tracks and 8 firsts scenes + reports the time it took to complete this operation..

a couple of observations :

1) the more clips there are in a project, the more time it takes to get 64 clips names
- in the first project "getClipsNames 64 clips" (8 tracks - 8 scenes = 64 clips)
here on my macpro, it takes ~ 100 ms to get 64 clips names
- with "getClipsNames 800 clips" project (8 tracks - 100 scenes = 800 clips) = ~180 ms
- with "getClipsNames 8000 clips" project (8 tracks - 1000 scenes = 8000 clips) = > 1000 ms

the device getClipsNames.amxd gets only the 64 firsts clips names, but the biggest the Live project is, the more time it takes to do it's job.


2) live.path is the problem
let's disconnect live.path from the live.object that gets clips names :
in the device getClipsNames.amxd, double clip the patcher "p getClipsNames" , and click on the graphic gate to disconnect live.object.
now, the patch only gets devices ids, but do not get clips names :
it takes almost the same amount of time
so : the bottleneck seems to be live.path getting clips ids, not live.object getting clips names..


3) edit this device in max, and click on the button to get clips names : it will multiply the time needed to complete the operation by 5...
and it will probably crash max if you do it a couple of times, in a big project containing many clips...


so, the question is :
is there a better way to get clips ids ?
or is it a bug, or will it be improved / optimized in a futur version ?

any tips is welcome !

thanks in advance

MathieU

It takes 1 second to get 8000 clip names? Wow, that's cool.

Please understand that in the "real" world of setting up controllers that performance is fine.

Performance over the connection between MFL and the editor will always be slower, and susceptible to bottle necks. It's something we're continuing to work on.

As far as getting ids goes, the less you do it the better. If you can cache them, then do so.

-A

pukunui wrote:It takes 1 second to get 8000 clip names? Wow, that's cool.

no ! when there are 8000 clips in the project, it takes more than 1 second to get only 64 clips names...
(please have a look at the device I sent)
(getting 8000 clips names would take probably more than 2 minutes...)

Please understand that in the "real" world of setting up controllers that performance is fine.

so no, I don't agree that that performance is fine...
I know many Live users who always have several thousands of clips in their project...
so browsing such a project with a refresh rate of 1 hz is not confortable ; and taking 2 minutes at load time to cache all clips ids is not very user friendly...
(yes, I'm trying to make a kind of clip browser / clipLauncher ; I need to display a grid of 64 clips names & colors..)

any chance to see any performance improvement of live.path soon ?

thanks in advance

Mathieu

matcham wrote:I know many Live users who always have several thousands of clips in their project...

Yes, I know them too and these are exactly the people who are emailing us because of "not enough memory" warnings and crashes.
You'll overload the RAM with so many clips, esp. if these are audio clips. Depending on how much RAM you have installed, and how much RAM your OS can address, anything > 1000-2000 audio clips is critical.
8000 clips is quite unrealistic in a normal usecase, if not impossible.

I can't really comment on the API access times, though.

Best,
Nico

hi Mathieu,

one question about your patch: how would you keep it up to date about changes of your sound files ?

would you trigger it with a metro ?
I have tried this without success. it works only -- when I click it with the mouse somehow.

thanks,
bd

pukunui wrote:It takes 1 second to get 8000 clip names? Wow, that's cool.

Please understand that in the "real" world of setting up controllers that performance is fine.

Performance over the connection between MFL and the editor will always be slower, and susceptible to bottle necks. It's something we're continuing to work on.

As far as getting ids goes, the less you do it the better. If you can cache them, then do so.

-A

+1