remote~ from JS

[mfrederickson]

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.

[amounra93]

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

[mfrederickson]

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: Select all

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()

[amounra93]

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