orange_glass

I'm trying to get a message that is the row index of a playing clip. The tricky bit is getting a message upon each loop. I'm using a combination of playing_slot_index which will give info on the 1st loop and then a spurious observation of the playing_position.

I tried select 0 or select 0.0 on the playing position but 0.0 never matches and 0 (being a float) messages many times from 0 to 0.9.... So have resorted to a "if less than the last test" type fudge.

Sometimes I get 2 messages and sometimes one. Sometimes I'll get a message from the end of the previous playing clip. It's a bit hit and miss at the moment. I'm sure there must be a tidier way of doing this.

I'm trying to get a message that is the row index of a playing clip.  The tricky bit is getting a message upon each loop.  I'm using a combination of playing_slot_index which will give info on the 1st loop  and then a spurious observation of the playing_position.  

I tried select 0 or select 0.0 on the playing position but 0.0 never matches and 0 (being a float) messages many times from 0 to 0.9....  So have resorted to a "if less than the last test" type fudge.

Sometimes I get 2 messages and sometimes one.  Sometimes I'll get a message from the end of the previous playing clip.  It's a bit hit and miss at the moment.  I'm sure there must be a tidier way of doing this.

row-index-on-each-loop

Did some investigation. The playing_position property is calling back at about 10 times a second. That means an average latency of 50 ms. Too much! Your kludge "if less than the last test" is not good enough. As you know already.

The first start of a clip is reported correctly by the property playing_slot_index. I think discovering looping involves getting the looping property of the clip combined with the loop_length property. Then a timer can bang on restart.

I figure that repeating this loop will work for some time, but in the long run the synchronization will go astray. Stopping and restarting playing the song will not work either.

I will do some more testing tomorrow. Please hang on.

Thanks for looking into this. Are you saying that we have calculate the loop length and then do our own independent metronome? Could we not hook into Live's own transport? So if I know it's a 1 bar loop get a bang on every bar as long as my loop is playing? This would get mad complex if I had 1 & 1/2 bar length clips or had differing quantisation but I think as I'll only be dealing with simple 1 2 or 4 bar loops.

Actually thinking about it I could use a count object. When a clip launches it tells the system I need to loop in x beats, reset a counter and then when it counts 6 beats on live's transport, fire a bang.

Thanks for looking into this.  Are you saying that we have calculate the loop length and then do our own independent metronome?  Could we not hook into Live's own transport? So if I know it's a 1 bar loop get a bang on every bar as long as my loop is playing?  This would get mad complex if I had 1 & 1/2 bar length clips or had differing quantisation but I think as I'll only be dealing with simple 1 2 or 4 bar loops. 

Actually thinking about it I could use a count object.  When a clip launches it tells the system I need to loop in x beats, reset a counter and then when it counts 6 beats on live's transport, fire a bang.


I just found out that clips have a property loop_jump, which bangs each time a clip is started or loops to the start. I have filtered these bangs using the is_playing property. This patcher comes very close, although I have observed some double messages.

row index on each loop