newtfish

Ive noticed some major problems with Lemur for Ipad and UDPReceive CPU. My CPU goes up to 50% by just moving one XY pad.

My path only has one object in it - UDPReceive .

Its worth noting that I have a very fast pc, 3930K CPU and 16gb ram. This also doesnt happen with touchosc.

How can this be, that Lemur uses up so much CPU in max? Is there a workaround? or a known problem?

lemur-cpu

I've both Lemur and TouchOSC on my iPad and just tested them. On my PC, the cpu use of both is negligible... I don't know what might be the problem...

sounds very strange. are you sure its MAX taking up the CPU? do you have Lemur daemon running also?

Its so strange, I cant get to the bottom of it.

The problem seems to be the multiball object.

Just one [udpreceive 8000] in a max patch (closed) and wiggle round the multiball, CPU shoots up between 15%-50%

When I open the max patch to edit it, if I move around the multiball, the patch becomes unresponsive.

I wish I could get to the bottom of this. Anyone else can test this phenomenon?

Lemur receives on port 8000 so i'm surprised that does anything - unless there is some really weird loop you've got going on somewhere... (do you have Lemur set up to send on port 8000? ) do you get the same behaviour with a different port?

Looks like ive finally got to the bottom of it. I was sending the OSC through 3 different regexp objects, when only one was needed. This caused the patch to slow down when max was opened. When I close max, (and its still open in the background), it continues to be unresponsive, even when everything has been removed from the patch. Implementing the regexp fix and restarting live fixed it.

Lemur does send out a LOT of OSC messages. You might want to try throttling the number that are acted upon in your patch. This is especially a problem when interfacing with the Live API in M4L. There are just too many messages for max to handle sometimes depending on how much processing you are doing per message. You might want to have a look at the odot objects by CNMAT for parsing OSC messages they might be more efficient than [regexp]

a good point - if you're not using the accelerometer data, turn it off in Lemur - it sounds out huge amounts of data

i'm also very surprised at regexp being the cause of the cpu - never had any issues with it and use it extensively

Just wondering if there are any ways that dont use external objects?

Ive tried slim and qlim but they seem to remove too much information from the OSC to be usable.

i do all my OSC processing with regexp, in a mixture of MAX and js...

What arguments are you using for speedlim and qlim? I use [qlim 20] everywhere in the patch I use for communicating with Live via OSC and that's fine. What regex string are you using to parse the OSC data? With regards to other options regexp and javascript are the only ways to do true parsing. Although I don't think javascript will offer you any performance gains. You could also use route to crudely match the address string. I understand the reluctance to move away from 'vanilla' code but in the case of OSC parsing I do think that the benefits outweigh the costs. I still don't quite understand why you're getting such a massive usage peak though. Can you post an example patch?

Sure heres the patch, Im sorting through the OSC with regex. Then looking up in a coll the id of the parameter in live. Then controlling the parameter with JS

(this patch requires you to have the IDs of the parameters, for this example use an AutoFilter and insert into the coll the IDs of the "Frequency" and "Resonance" parameter IDs in this format, where the id = nn).

There is a JS at the bottom which goes as follows:

    var a = arrayfromargs(arguments);

var api = new LiveAPI( this.patcher, path );

Then from the Lemur you want a multiball with the following custom OSC addresses for x and y:

for X - /Container/AutoFilter/Frequency/x

for Y - /Container/AutoFilter/Resonance/x

If I use "qlim 20" just after the udpreceive, then nothing makes it through the patch.

Im probably doing something really silly. Ive a strong suspicion that the JS simply cant handle 2 parameters at a time

Before, I had several regexp's sorting through the incoming OSC and max simply choked/crashed.

Im wondering if there is a way to have several JS patches and then route the different messages to them one at a time in a sort of round robin approach? (I only need to ensure around 4 parameters can be controlled at the same time).

if (jsarguments.length>1)
	myval = jsarguments[1];

function list()
{
	var a = arrayfromargs(arguments);

var path =  "id " + a[0] ;
var api = new LiveAPI( this.patcher, path );
api.set('value', a[1]); 

for X - /Container/AutoFilter/Frequency/x
for Y - /Container/AutoFilter/Resonance/x

Im wondering if there is a way to have several JS patches and then route the different messages to them one at a time in a sort of round robin approach? (I only need to ensure around 4 parameters can be controlled at the same time).


Weirdly, managing different streams to multiple scripts, using a counter to separate the streams works quite well.

Thanks for all your help Lee and CPHAS:)


I do all of my OSC processing with that crazy new object, [route] - it's all the rage ;)

jk, I do use regexp to strip away / first, but that's incredibly cheap.

You are creating a new LiveAPI object every time your function is called that could be what is causing your problem. Maybe you should try changing the path of the LiveAPI object rather than creating a new one.

@Wetterberg couldn't you use [fromsymbol] for that as well?

Lemur CPU?