All times are UTC

 
 



Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: remote~ from JS
PostPosted: Tue Jan 22, 2013 5:04 pm 

Joined: Mon Nov 09, 2009 1:43 am
Posts: 16
When sending a lot of tempo set api calls, or parameter set calls to Live quickly, sometimes Live updates with a significant lag - it seems like it's getting my messages, then adding them all to a queue that's getting processed when we're back in the UI thread or something.

With that observation:

1) Could this be because I'm setting a property rather than automating tempo at signal rate with remote~? Could the queue slowing things down indeed the undo queue? If so, is there any way to use remote~ from JS? If not, would it be best to have a remote~ max obj outside of JS that I send to from the JS object?

2) Does anyone at Ableton, Cycling, or the developer community have a feel for what a good time rate limit between API calls might be not to incur such lag? I'm about to start profiling this, so I will report my findings.


Top
 Profile  
 
 Post subject: Re: remote~ from JS
PostPosted: Tue Jan 22, 2013 7:02 pm 

Joined: Sat Jan 24, 2009 8:16 pm
Posts: 430
Location: Arcata, CA
I don't use remote~ myself, so I can't testify to its efficacy. However:

Js API calls are all low-priority (deferred), so, yeah, that's why you're seeing things queued and released. In addition, all of your js is happening in a single thread. I try to limit as much as possible the js-API interaction to what is absolutely necessary, using [speedlims] or other processes to make sure I'm not doubling data flow that's not necessary.

There isn't a way to use [remote~] as an actual js object instance, but you can always script the [remote~] and send it a message from js.

The Python thread timer barrier is 60ms when the transport is running, and other internal C++ operations (e.g. installed listeners of API objects) only get updated every 60ms, so I'm guessing 60ms might be a good interval. That said, I don't have any evidence that Live isn't able to update the params more often than that....but do you really need to? I usually [speedlim] things at 100ms myself.

Hope that's useful.

a

_________________
http://www.aumhaa.com for Monomod and other m4l goodies.


Last edited by amounra93 on Thu Jan 24, 2013 7:01 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: remote~ from JS
PostPosted: Thu Jan 24, 2013 6:46 am 

Joined: Mon Nov 09, 2009 1:43 am
Posts: 16
This was a great help, and glad to hear someone else has put a bunch of thought into this.

I've just decided to downsample my signal, as I'm not doing LFO or any other modulation that truly necessitates signal rate. I'm running my logic in an external Python app I wrote, which sends commands over OSC to a simple Max patch which receives and dispatches API calls in JS.

In case it could be of service to you or anyone here, I wrote a handy little Python decorator called speedlim. Decorate with it, and you will only be able to call the decorates function once within a set threshold time.

For example, despite being in an infinite loop that does nothing else, the code below will print 'LIMITED' once per second:
Code:
import time

# After how many seconds should another
# call of the decorated function be allowed
# to execute?
throttle = 1

functionCallTimes = {}

def speedlim(f):
    def decorate(self):
        fKey = (f.__module__, f.__name__)
        lastCallTime = functionCallTimes.get(fKey)
        executeFunc = False
        if lastCallTime is None:
            executeFunc = True
        else:
            if (time.time() - lastCallTime) >= throttle:
                executeFunc = True
        if executeFunc is True:
            functionCallTimes[fKey] = time.time()
            f(self)
    return decorate

class MTF(object):
    def __init__(self):
        pass

    @speedlim
    def limited(self):
        print 'LIMITED'

m = MTF()

while True:
    m.limited()


Top
 Profile  
 
 Post subject: Re: remote~ from JS
PostPosted: Thu Jan 24, 2013 7:00 pm 

Joined: Sat Jan 24, 2009 8:16 pm
Posts: 430
Location: Arcata, CA
Glad it helped....I know it seems like a wasteland out here in Python/m4l land sometimes.

Hey, that's cool :) I'm just getting into decorators, so it's timely and convenient that you posted that. Cheers !

a

_________________
http://www.aumhaa.com for Monomod and other m4l goodies.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC

 
 

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group