remote~ from JS

Questions and discussion about building and using Max for Live devices
Post Reply
mfrederickson
Posts: 18
Joined: Mon Nov 09, 2009 1:43 am

remote~ from JS

Post by mfrederickson » Tue Jan 22, 2013 5:04 pm

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
Posts: 431
Joined: Sat Jan 24, 2009 8:16 pm
Location: Arcata, CA
Contact:

Re: remote~ from JS

Post by amounra93 » Tue Jan 22, 2013 7:02 pm

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
Last edited by amounra93 on Thu Jan 24, 2013 7:01 pm, edited 1 time in total.
http://www.aumhaa.com for Monomod and other m4l goodies.

mfrederickson
Posts: 18
Joined: Mon Nov 09, 2009 1:43 am

Re: remote~ from JS

Post by mfrederickson » Thu Jan 24, 2013 6:46 am

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
Posts: 431
Joined: Sat Jan 24, 2009 8:16 pm
Location: Arcata, CA
Contact:

Re: remote~ from JS

Post by amounra93 » Thu Jan 24, 2013 7:00 pm

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.

Post Reply