bongo808

Hi, I've made a device which aim is to save kind of presets of Live set, it saves mixer and devices parameters using Live API, and fits perfectly my needs. Its main issue is CPU peaks that may be caused by some data loops. Since I am not a Max expert, and I learned it mainly by creating this device and a few (simpler) others, I can't figure out what is wrong (trust me I tried) and I may not have the skills and workflow to diagnose it properly. But this device seams close to be reliable, so it may only take a few minutes for an experienced Max user to find what is wrong, and maybe fix it. Please note that this device is dedicated to be freely shared with the community, but since I need it to be reliable quite quickly I am willing to consider paying for this job. I am open to discuss on the budget. Thanks for your replies !  

Hi, I've made a device which aim is to save kind of presets of Live set, it saves mixer and devices parameters using Live API, and fits...

check-and-optimise-existing-m4l-device

hello. I just opened the patch. some stuff seem missing. you have to freeze your device before sharing it.

Any way, l'm not a max guru at all but I see that in the client console of your pattrstorage. is it normal ?

Then I see that and I am wondering if the use of [poly~] shouldn't be something to look at..

Using preset or pattrstorage objects like this will always result in CPU spikes because they will always try to do all the recall all at once.

You could maybe  use pattrstorage for it if you, say, recalled only a only subset of all the clients in each signal vector.  It would basically look like:

This way you'd spread the CPU work out over time, rather than creating one gigantic spike.  I've done something similar effectively while using [dict] objects (rather than pattrstorage) for holding info like this in the past.

But really...  IIRC this is a totally solved problem with something like ClyphX, and there are probably twenty implementations of something like this around maxforlive, at least one of which ought to be competent.

Thank you for your answers ! @SCHLAM What you screenshot seems normal to me. And about [poly~] I don't know how I would use it here, could you be more specific ?

@TYLER MAZAIKA Thank you for your message, I just tested ClyphX (the opensource version), and I really like it, a lot of very interesting functions, but it seems it becomes overwhelmed faster than my device, I got hi cpu load even with less than 500 parameters. pattrstorage changemode in my device allows for recalling only changed data, so it seems it is way more efficient if a lot of parameters are involved. It also seems that smoothing is more like several  jumps between two values and not a full range ramp, and I actually need it, especially for sends values.

Check and optimise existing m4l device