live.step synchronisation / index# issues…

May 15, 2010 at 3:16pm

live.step synchronisation / index# issues…

hi,

i have tried and studied and searched, i am slightly stumped. could anyone (emmanuel?!) shed any light on the best way to synchronise two live.steps?

i want to drive everything with the ‘index #’ output, but the output events seem very confusing to me. i cannot devise a system where the mouse and programmatic filling / editing of data sync across both guis. it would be great (hint hint) if the live.step had the same ‘link’ functionality as live.grid, for example.

EDIT: at first i tried filling a jit.matrix with all data, but this seemed overkill, so i just try and send on deferlow immediately data is changed in one live.step. the problem is trying to drive it with ‘index’, not the filling itself.

below is some extracted code in case anyone has the time / inclination to help:

– Pasted Max Patch, click to expand. –

thanks.

#50377
May 15, 2010 at 9:14pm

I’m not sure I get what you mean, but maybe you can use copy/paste.

– Pasted Max Patch, click to expand. –
#180782
May 16, 2010 at 12:40pm

emmanuel, as ever, thanks very very much. great demo.

embarrassingly, i had got it in my head that copy/paste was only to an internal buffer of the one live.step (for copy/paste of sequences) and not global as you demonstrated, and stupidly i had not tested this.

naturally i have more irritating, possibly stupid questions, so if you have the time i would appreciate you indulging me…

1. is pasting to only the changed mode more efficient than a global paste?

2. am i right to assume that if the live.step is running, i should [deferlow] the pasting to the other live.step?

3. of course programmatic (not mouse interaction) changes to ‘zoom’ and ‘loop’ do not update the ‘changed’ message (dumpout), so dealing with these globally is ok / efficient enough whilst live.step is being run?

4. i am still really confused as to when ‘index #’ fires and to be honest as to what ‘index #’ IS ?! a brief sentence of clarification?

5. on that note – how does the LEFT output work? – if i want to ADD the sequence NUMBER to a step parameter, how do i know which sequence ‘list’ to add it to? (using RIGHT output ‘index #’ does not work?)

apologies, that is a lot of questions i know. i modified your patch to explain what i mean by these questions:

– Pasted Max Patch, click to expand. –

thanks again.

#180783
May 17, 2010 at 1:38pm

1. is pasting to only the changed mode more efficient than a global paste?

That’s more information to copy… but I highly doubt that you’ll notice the difference.

2. am i right to assume that if the live.step is running, i should [deferlow] the pasting to the other live.step?

You don’t see any reason for adding a deferlow object.

3. of course programmatic (not mouse interaction) changes to ‘zoom’ and ‘loop’ do not update the ‘changed’ message (dumpout), so dealing with these globally is ok / efficient enough whilst live.step is being run?

Yep. If you send a message to change the zoom, you know that you’re changing the zoom, so it’s up to you to do the appropriate thing to change it for the 2 live.step objects.

4. i am still really confused as to when ‘index #’ fires and to be honest as to what ‘index #’ IS ?! a brief sentence of clarification?

The index comes out each time that there’s a message that is sent to the object, or that you change something with the mouse, with the index of the target sequence that you edit. If you look at the Editing sequences subpatcher from live.step‘s help file, you’ll see that when sending an integer to the live.step while the target_seq is set to 0 (aka All), the values coming out live.step are “tagged” with the number of the sequence.

5. on that note – how does the LEFT output work? – if i want to ADD the sequence NUMBER to a step parameter, how do i know which sequence ‘list’ to add it to? (using RIGHT output ‘index #’ does not work?)

I’m confused, I think all you want to do is to use the rightmost outlet to get the sequence index.

#180784
May 17, 2010 at 5:44pm

emmanuel, thanks for response.

re point 5 i was being an idiot.

thanks very very much for all the help.

#180785

You must be logged in to reply to this topic.