sounder

i have a problem with m4l-devices that are synced to hosttempo like stepsequencers or lfo´s.

for example ml-px-18-sequencer stops after some time although ableton live is still running. after a few seconds

this happens with all synced m4l-devices.

2x2,66 GHz Quad Intel Xenon OSX 10.5.8 Live 8.1.1 MaxMsp 5.1.3

i have a problem with m4l-devices that are synced to hosttempo like stepsequencers or lfo´s.
for example ml-px-18-sequencer stops after some time although ableton live is still running. after a few seconds
it restarts again and runs in sync.....
this happens with all synced m4l-devices.

_____________
2x2,66 GHz Quad Intel Xenon OSX 10.5.8 Live 8.1.1 MaxMsp 5.1.3


sync-problem

Does it happen in both modes, performance and edit?

Yes broc it happens in both modes. i figured out, that it only happens when cycle in arrangemode is engaged...

It seems to happen at a certain level of complexity with multiple synced devices.

Or does it happen for you also with simple sets, ie. a single step sequencer?

I'm able to reproduce the issue.
It seems to happen at a certain level of complexity with multiple synced devices.

Or does it happen for you also with simple sets, ie. a single step sequencer?


May I please have a step by step of how you made this happen?

broc, yes it happens with a single device.

1. put a sequenced m4l device like ml-px-18 on a midi track in live

2. put a instrument on the same miditrack

3. go to arrange view and create a 1 bar loop and hit cycle

broc, yes it happens with a single device.
andrew:
1. put a sequenced m4l device like ml-px-18 on a midi track in live
2. put a instrument on the same miditrack
3. go to arrange view  and create a 1 bar loop and hit cycle
4. hit play 

Yeah I've run into this problem any official response on this?

I'm not able to reproduce any problems if I follow those steps. Maybe there's a bit more to it?

I almost hesitate to post because I can offer only anecdotal evidence but a M4L device I've made using Live's metro does this as well. It will stop sending MIDI all of a sudden and then start back up at its own leisure (usually 3-5 seconds later).

I never noticed it to be linked to arrangement vs. session view and my device doesn't use clips.

It's a pretty complex patch involving Java externals so it's hard to whittle down to something I can share but I'll see if I can isolate anything.

I almost hesitate to post because I can offer only anecdotal evidence but a M4L device I've made using Live's metro does this as well.  It will stop sending MIDI all of a sudden and then start back up at its own leisure (usually 3-5 seconds later).

I never noticed it to be linked to arrangement vs. session view and my device doesn't use clips.    

It's a pretty complex patch involving Java externals so it's hard to whittle down to something I can share but I'll see if I can isolate anything.


I have a Live set with multiple M4L devices using metro/transport control.

Sometimes one of the devices doesn't start from the beginning but comes in several bars later. So there is obviously a sync problem but not reproducible, unfortunately.

I have a Live set with multiple M4L devices using metro/transport control.
Sometimes one of the devices doesn't start from the beginning but comes in several bars later. So there is obviously a sync problem but not reproducible, unfortunately.


There was an issue with MIDI and threading which was evident with Java MIDI processing. Please make sure you have the latest versions of everything, we fixed it in 5.1.3 I think.

If you are still able to reproduce a problem with MIDI stalling, please send it in to support.