Many ways to get to a solution.. how do I measure performance of M4L devices?

Jan 11, 2012 at 3:24pm

Many ways to get to a solution.. how do I measure performance of M4L devices?

Hi all – I find myself often making choices between methods of implementing an idea often balancing flexibility vs performance.

For example, my Ipad controls rack effects. When I change track, it queries all the parameter names for the racks on that track. I could instead have all parameter names for all tracks requested when I start up Live and store them (eg using coll) for retrieval when required. This will probably be faster/better but _how much_ faster and better?

I love using ‘pedant’ for simple structures but I don’t think it’s very useful for measuring M4L devices. What do you guys use?


Jan 11, 2012 at 11:30pm

I query the names at the beginning. I find it makes about .25 seconds faster when switching patches.

Jan 12, 2012 at 3:06am

Thanks benj373! did you find a way to measure that or is that your estimate from experience?

Jan 24, 2012 at 12:10pm

I always use cpuclock for speed tests (and use an uzi to repeat that same action lots of times to get a representable average time)

Jan 24, 2012 at 1:48pm

This tool is really useful. I put in a bpatcher form, and have it saved as a clipping so I can easily call it up if I want to compare two methods of doing something in a patch.

Feb 4, 2012 at 4:26pm

Thanks David! I use Pedant all the time, but haven’t worked out a way to use it properly in Live. I’m curious how you do it.. the code that you compare needs to be inside pedant’s subpatcher right?

I wonder how you manage to use the comparison in a bpatcher.

@Timo – I’m going to try that!



You must be logged in to reply to this topic.