big data flow from midi device // slow handling ??

[julienb]

hello,
as some know, I'm testing my protodeck controller with a m4L patch as interface with Live.

The hardware side is fast, tested, improved etc.
I tested it with midiOX and even if I turn pots VERY fast, no data loss etc etc.
(for those interested, I use multiplexed potentiometers and the scan frequency is ... 1000Hz)
so, no midi flow problem. I'm sure about that.

so.. the point:


I mapped my pots by selecting midi flows like that:



and here is one of the sub-patch:



I feed the input with a midi in, tested too.

The problem:
when I turn the pots very fast, inside the patch, it works fine. the value change quickly (a little bit slower than my midi flow... not really slower, but with some fast jump... but it is fine)
BUT, in live............. strange things occur!

- if I turn it fast from minimum to maximum, without stopping it before the end of the potentiometer way, the value in Live changes but very sluggishly and, at the end of the potentiometer way, the value jump back to a lower value.
- if I turn it slower, it doesn't do that.


big lag time between the patch and Live through the API ????

I cannot understand why it does that.

I'd prefer to use live.remote~ but there are some issues unexplainable with that and I'm not sure it is the best way.

another thing I could do: midi mapping in live directly.
but I'd like to have all my config in one file: the patch. not here, there, there and there, you know?!


any ideas? experiences? suggestions?
maybe I don't use live.object correctly or my patch is a bad nOOb patch

[amounra93]

I've had similar problems....add a "speedlim 20 @defer 1" before the live.object "set value $1" input and see if your performance improves. Mine did I there are going to be some speed limitations with which we'll have to live with when calling API objects.

[julienb]

ok!
thanks
I'll test it asap.

I'm not sure about the bottleneck..
indeed, I send my midi messages to my (midi in) that is handled by live, and then, by the patch...
so...

btw, I could build my mapping directly inside Live...
but I wouldn't want any live set dependancies, only patch dependendies..

[amounra93]

The bottleneck isn't Live, its Max's access through the API. Lemme know how it works out for you

[julienb]

The bottleneck isn't Live, its Max's access through the API. Lemme know how it works out for you

no problem. this is the 1ast thing I'll do when I'll be home!

[pukunui]

I expect you're hitting your head on the current performance ceiling of live.object and the API. Why doesn't live.remote~ work for you? Otherwise the speedlim solution is a good idea.

Cheers


Andrew

[julienb]

I expect you're hitting your head on the current performance ceiling of live.object and the API. Why doesn't live.remote~ work for you? Otherwise the speedlim solution is a good idea.

Cheers


Andrew

Andrew, I'll test firstly with speedlimit.
but for sure live.remote~ is the way.
as said before, I had some problems with live.remote~ (here) but if it is my only way... I'll dig it!!

[julienb]

the speedlimit seems to be fine... it is a workaround...

live.remote~
I'm digging BUT this simple patch doesn't work here:

Code: Select all

----------begin_max5_patcher----------
541.3ocuU1rbaBCDG+LYl7NnQmc8fjLAH2ZeM5jwiLnDqTjjGjrqayz9rW8g
wVIw1A5.4.Hzpkk+6Osr5kauIAtRsmogf6AeGjj7h0Rh2lyRRmgDnftupgp8
NBerQI2JfyNrlZqogYL+ZCKDF25TCbF.thJeBBdnywGURijJ7tA+ZKm1bLF1
3yE1XZWAMOsyJu16pZ0yegfO4KW14a5IecAWy+sO3nnXXUJWZ0mW5nNqanlp
0b4SKaYUlfryJruD.GFxvt6nx4omjuMRgT0GJr25et8F2ncXVuwmMNqXsWFe
bY+fG3apl5yRPb94HH5rDbz3GJ0yuRhafTLg7i8Sa9bLYLr8dE.a36XysBa8
kQqiq9qdUTFAuBBb7.EIPp7E9JsxOhTjwmTJZsfo0.Gs.NtsTyL.AUaXsKMs
zpe.D781mqY63ULvNUyVKhtLWGLOWL97L7OKITGdMfh9uA5D24Cme1deEeV8
9JJm7deW6e2VlPYX+ENrRIb4vJkvWgCGZdQbuKH+tOhCougCA+rIi7cGo5+X
tEdCczpssUckOcGzAh9h0LsgKoFtRF4kKoi8ZMutlIeUCcAudixdVxAkbW97
L2VbleKdQX+NZBAEZYmhc94mAd3x6y8NebcNAndkOngjOHaiyrim2DOaTjs6
zxoXa.40IAShgMdrTcwjV7PvnWoZzXo5E8Q09BogwZRnnHOzPKZ16jsyfc3e
LrwbGC
-----------end_max5_patcher-----------

what is my problem, guys ?!

I tries with integer value from 0 to 127, with float from 0. to 127., with float from 0. to 1.
nothing changes here

I can open another thread ...

[pukunui]

live.remote~ does not currently work very well in the editor - did you try this in a saved device in MFL?

-A

[julienb]

live.remote~ does not currently work very well in the editor - did you try this in a saved device in MFL?

-A

indeed.
I just figured out this!

saved device?
I have a big patch that is my only interface/device with my hardware
I just saved the patch, staying in the editor, and it works, indeed..

we have to save after each mods.. that is the way!

[julienb]

so, the big benchmark has been made!

by replacing live.object / set value by live.remote~ ... it works just FINE & FAST !!!!!
no need of speedlimit etc.

I turn my pots VERY fast, 2 at the same time even 4 (thanks to my girlfriend cause I only have 2 hands!)......... NO problemo !

really!!!

[amounra93]

so what exacty is the difference between live.object and live.remote~ in their functionality? Its not really clear to me what differs....

[julienb]

so what exacty is the difference between live.object and live.remote~ in their functionality? Its not really clear to me what differs....

live.remote is for live perf speed. no undo neither automation is possible when a parameter is connected to a live remote.

live.object is for automation use
and I tested it a lot with a real physical hardware...
modulating parameter with that is impossible in live perf. (I guess it isnt made for that so ...)

[peboer]

I reached similar conclusions wrt to live.object vs. live.remote~. One thing I noted in another thread is that live.remote~ vs. control of volume via midi learn is really different. I found that MIDI learned volume is way more responsive than live.remote~.