Page 1 of 1

a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 12:37 pm
by julienb
Hello,

my patch (which I began to describe here) works fine.

BUT, I notice a LOT of errors in the max window.

At loading time, a lot of live.path have to request IDs through the API.
I guess this made some temporary bottleneck that give errors.
I guess requests are schedulded, and delayed and live.remote~/live.object are a little bit confused and complain to the max window.


So the question is: should I defer things? or manage all these requests differently?
Is there a way to do that easily (I have a lot of subpatchers, inside other subpatchers etc)

Indeed, I have a lot of parameters to map in both way (from and to Live)
So I cannot really do differently.


any ideas? suggestions?

all the best,

Re: a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 2:34 pm
by gavspav
You probably know this but if you can get the errors to appear when editing your patch, you can highlight the errors in the Max Window and click on 'show object' which lets you know which api call is throwing the error.

Then you might be able to track down the reason.

If you already know that then sorry.

I've been thinking that alot of id numbers always seem to be the same relative to one another eg with the launchpad if you know one id number, you can usually work out the rest without having to do the Live.path thing.

It'd be good to find out more about the way Live allocates id numbers because if their is consistency, at least within devices, then this could help alot.

Re: a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 3:35 pm
by julienb
gavspav wrote:You probably know this but if you can get the errors to appear when editing your patch, you can highlight the errors in the Max Window and click on 'show object' which lets you know which api call is throwing the error.

Then you might be able to track down the reason.

If you already know that then sorry.

I've been thinking that alot of id numbers always seem to be the same relative to one another eg with the launchpad if you know one id number, you can usually work out the rest without having to do the Live.path thing.

It'd be good to find out more about the way Live allocates id numbers because if their is consistency, at least within devices, then this could help alot.
hi gavspav,
I knew that but it is not a problem, it is better to write about things, in the case where people forgets things :)

So I have to precise/add something: if I click on the errors, I can find ... almost all the live.path.
But path are correct! (indeed, it works fine for remoting, observing, get/set object)
So the answer could be: "don't touch anything, it works!"

I did a last thing: I put a print object in order to provide a "button for the max window" easy clickable.
so I can see exactly at the loading time the errors in the Max Runtime Window
and...

I only see 12 errors messages.
not about 200 as I saw... I made a confusion between Max Runtime Window when the patch is in "playing mode" and the Max Window when it is in "Edit mode", in which I guess each edit mode/playing mode transition reload all loadbang/loadmess and makes things like resetting etc etc.

So only 12 errors messages:
Live.path Invalid syntax

all these path are correct and verified 100 times.

... I'm digging
(thanks gavspav)

Re: a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 3:42 pm
by julienb
still digging, I cannot understand
:-(

as example, I put a rack device with 2 chains in the return_track 0
I address the path : [live.path live_set return_tracks 0 devices 0 parameters 9]
it means: the parameters 9 of the 1st device in the 1st return track (A)

I have to write it works (I can observe it) but it complains...

why? :?: :?: :?:

Re: a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 4:13 pm
by julienb
ok.
all the path that give error are all related to return_tracks track type.
I repeat : it works & it gives an error at loading time (1 error per live.path object)

very strange...

I have to add something: the parameter addressed is both observed (for feedback to my hardware) & controlled.
Of course, there isn't a kind of feedback loop (feedback aren't sent by the controlling part! only by the observing part)


btw, it works, but at optimization time, I just wanted to correct almost everything :)

Re: a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 6:53 pm
by Palmer Eldritch
Hi julienb,

You are not alone with this problem :} http://forum.ableton.com/viewtopic.php?f=35&t=133682

Re: a lot of live.path requests at loading: work but give errors

Posted: Fri Jan 15, 2010 7:10 pm
by julienb
right!
it is all the same.

the most strange thing is that it works, but there are some complains.

I didn't have any infos from cycling74 or Ableton :-(

Re: a lot of live.path requests at loading: work but give errors

Posted: Mon Feb 01, 2010 12:36 pm
by pyrolator
julienb wrote: I guess requests are schedulded, and delayed and live.remote~/live.object are a little bit confused and complain to the max window.


So the question is: should I defer things? or manage all these requests differently?
Is there a way to do that easily (I have a lot of subpatchers, inside other subpatchers etc)
Hi Julien,

I am also digging....:-)

I am working on an installation with two touch-screens, where some of the basic functions of Live can be controlled by "touch-friendly" sliders (size!).
The bottleneck seems to be the configuration with live.path an the live.remote objects.
I clearly define the path-message, because the track-numbers and plugins do not change within the setup, but when I give all the live.path-messages at once at the startup of the m4l-device I get a lot of error-messages in the max-window, and the order of the sliders and objects I want to controll are mixed up.
First I tried to send the loadbang thru some pipe-objects to get an order, but this doesn´t help.
Strange enough: When I set the live.path in the moment of touching the slider on the screen, it all works, but not when it is triggered by a loadbang at the loading of the setup..... any idea?

best
pyro

Re: a lot of live.path requests at loading: work but give errors

Posted: Mon Feb 01, 2010 1:45 pm
by julienb
hello,

the main advice I can write here is: you'd prefer to use live.path request as less as possible!
I mean, the main bottleneck is this kinf of requests.
in my protodeck's interface, I use coll for storing live.path result as many as possible.
I designed a patch architecture using this rule.
and my patch is very improved now.

Re: a lot of live.path requests at loading: work but give errors

Posted: Sat Feb 06, 2010 7:29 pm
by julienb
after the update of 5.1.2 max version, these strange errors I wrote about in this post gives complains yet BUT real errors too!

I mean:
imagine my rack in the first place of the master tracks.
the live.path of chain selector is required.

[live.path live_set master_track devices 0 parameters 9] worked but gave errors.
now, it doesn't work anymore :-(

strange no?

any ideas???
how can I observe that .......................?

Re: a lot of live.path requests at loading: work but give errors

Posted: Sun Feb 07, 2010 9:41 am
by julienb
FIXED IT!

it worked.
But the result of the observer has changed since previous version!
It fires float instead of int !
Ok, it was enough to know it :twisted: