live.dial automation chokes MIDI, slows dowwwwnnnnn...

[capital]

i'm building a simple GUI for remote synth control.with a few live.dials and some buttons.

i've hit a problem with using automation.
when i automate two live.dials simultaneously it chokes up the midi queue.
seemingly all midi output is sloweddddd...

clocked drum machines slow down.
and when i press stop, all the MIDI out runs for a few bars(or more) until this queue is emptied then everything stops :p

i've tried two MIDI output devices (both firewire), OSX and Windows (all on the same MacBook).
it just keeps happening

any ideas ???

thanks.

---
Live 8.3.4
Macbook Pro, 2.4g i7.
OSX 10.7.5, Windows 7.

MIDI.audio i/o : edirol fa-101, yamaha go-44.
synth/drum machines : elektron machinedrum, korg monotribe(midi)

[broc]

Apparently your automation setup exceeds the standard midi bandwidth (which is ca. 1000 messages per second). You can reduce the number of messages by inserting [speedlim] but it will affect the resolution/smoothness of control.

[capital]

thanks. i was wondering about that..

where does this limit come from ? live, max, or MIDI.


any suggestions on how to implement this where there's a bunch of controllers ?
i guess i'd like to maintain as much resolution as possible, and i suppose i need to consider other plugins as well :p

[capital]

i've reduced each output so they only send "new" information. before, they were sending the same number again and again.

if i have five controllers sending information through the same speedlim, one ends up hogging all the output
now i'm trying to work out how to effectively randomising the order of input, so the same input doesn't end up having priority.

[capital]

the problemss i had to fix were : repeated information (continual sending of the same value), the controller on the leftest(i think) effectively hogging all the bandwidth when all were sent through the same speedlim, and the final values not always matching the automation value (when the output does not make it through the speedlim).

so i've limited data sent to "new" information.
can't remember if i finally used a select object or an if then

arranged for the seven unique controllers to rotate priority in the left to right order of events.
ie 1234567, 2345671, 3456712, 4567123 etc..
-did this by setting up a rotation of bang orders and triggering stored values

and set up a value check at the end of each value change.
-using the delay object, so when it stops sending anything, it'll do a comparison and resend the "real" value.

.. the other thing that i've added is a "midi resolution" so if multiple devices are used they don't all combine to choke up the midi queue again.
changing the speedlim parameters

edit..
well i thought the midi resolution was a good idea, but even with speedlim on 1000, having multiple devices open still chokes it badly.

[broc]

..but even with speedlim on 1000, having multiple devices open still chokes it badly.

So it seems the bottleneck is not on midi output but with the dial automation itself (cpu load?).

[capital]

i think i've got it sorted now, i had a lot of unnecessary things happening :p
(it was shunting 7000 bangs a second just to keep the output rotating. lol)

a bit more testing now, and a few more ideas to integrate !!! i haven't really played with Max for a few years. it's still fun !!

thanks

[wascal]

Hi, this sounds just like a problem I've been encountering - any chance you still have this M4L device?

[RobPaper]

wascal maybe you should post your m4l device that you have problems with? do you know how to codepaste it?