Perfect Max4live quantization
Currently building a patch that moves play positions within clips. I am using the change in integers of a play position of another clip as the mechanism to bang ‘information’ to change the play position of the clip playing. Thus allowing a change in play position to be quantized to each bar.
Doesn’t seem to work very well at all, and wondered if anyone had any suggestions about the matter.
perhaps u can use
[phasor~ @frequency 1 0 0 bars.beats.units @lock 1]
to provide clock-lock !
Unfortunately this is a well documented problem with the Live API.
I was one of the people working on the Live Clip Chopper app for monome and launchpad, moving the playing position when hitting pads so you could chop up samples live.
Development pretty much stopped as the move_playing_pos function is pretty unreliable. Also as I was you are using the playing_postion of a clip to decide when or what value you use for move_playing_pos.
The problem is, I think, that the playing_position information can only be gotten or observed at scheduler rate and then the move_playing_pos function can also only be called at scheduler rate, not at audio rate like live.remote~.
So you just can’t get the data quick enough and at sample accurate speed meaning the calls to the move_playing_pos function aren’t accurate enough to jump with precision. You get random variance in the amount it jumps.
Putting the audio clip into RAM enable mode helps, and so should lowering your Audio Buffer size in Abletons preferences.
For the moment it seems move_playing_pos isn’t really usable. A few people, including myself, are working on solutions using max objects such as play~, wave~, and groove~ to build work arounds. Basically building your own little sampler that functions like an audio track in live, allows you to jump to any point in the sample, to reverse the audio, or change the playback speed of the sample independent of the master tempo without having to use the mouse.
its really nice that you mentioned this Myr .i dont know about the other person but im removing it from my to do list ! thank you . i can save my time .
but do you mean that we cant JUMP precisely to the specific position ? so maybe we can move the start point then INSTEAD ? .. other way would be an AUDIO effect that sample incoming audio and do the desired sequence .
Myr thanks so much for the information. Def. hope cycling/ableton can fix this issue. Maybe i’ll take a look at those objects and if its not over my head I’ll mess around as well.
Love you’re work on Live Clip Chopper, I am messing around with m4l and a monome as well, seemingly running into the same kinda problems.
Anyways good luck on the progress, I’m sure I’ll hear about it, can’t wait til a solution is found!
I have also tried and failed to get the move_play_pos to work properly or as desired. From what I have read and learned the move is not quantized/does not relate to the current tempo or grid. Therefore it is not very useful or precise. Myr, I look forward to any progress you make. I also am going to explore alternative solutions.