Behaviour of delay and pipe objects in M4L vs plain vanilla Max
Hello,
I've just discovered that timing objects such as delay and pipe do not function as expected in M4L: when Live is stopped, delays are much longuer than expected (around 17 times bigger in our tests). However when Live is playing, delay doesn't introduce any delay at all!
Metro also doesn't function as expected.
So:
1. What alternatives exist for reliable delays, whenever Live is playing or not.
2. Is there any tutorial/forum thread I should read to adapt patchers with such objects from Max to M4L?
Thank you in advance.
It seems to me because the M4L device is using Live's Transport Object..? I found this page that might help: https://docs.cycling74.com/max5/vignettes/core/live_timing.html
This would make sense for tempo-based stuff but why do delay and pipe with argument in ms do not function? I do now understand that metro functions when Live is playing, but what about delay lines?
This is how I understand it:
Pipe and Delay also rely on the timing system of the transport object being active. While Live is in Play Mode the objects will operate as normal but when Live is in stop mode they cease to operate after the last calculation, I think..
The argument in ms is a millisecond and it needs an active timing system to perform the calculation, which is Lives internal transport.
The m4l patch will be slaved to Lives internal transport. I don't know if it can be run independently in Live... does someone know?
But also, a metro object in a m4l patch can carry on banging if it is active in Lives Stop Mode as well. Although, if that metro is trying to use the Pipe object, it will not be able to.
Here is a quick m4l patch I made that shows this..
When editing the patch, even if Live is playing, the pipe and delay do not function as expected.
Yes, I think the documentation mentions somewhere that timing in edit mode is not reliable. So unfortunately, for serious testing after edit you may need to save (and sometimes even reload) the device to run in performance mode.
Too bad.
Yes, that is not handy, but one could explain it by the fact that when one wants to edit
a device, Max.app starts and takes over.So Live and Max are both involved.
When device is running in plugin runtime mode, than Max.app is not running at all,
and all is controlled from Live.
I don't use Live at all, but observed that behaviour few times,
trying to help out with some smpte - sync stuff in another thread.
I expected m4l to run completely in a "shell" inserted into track,
no matter if being edited or not,
like a patch or subpatch in Max, but that's far from being so.
So programming and debugging in realtime - ???
max should allow to put itself in a mode which emulates the behavior of live.
that would be the least i´d expect from working in/for live´s max runtime.
it does not make sens at all that there is a bunch of objects which function differently in different runtimes.
Yeah, I similarly wish there were a Max-only environment in which I could still perform LiveAPI queries (even if only on a mock LiveAPI), or get timing info the same way Live reports it (e.g. beat durations where 1.0 is a quarter note). I long ago abandoned the workflow which used the 'Edit' button in M4L devices.