You have an excellent understanding of your responsibility in initializing the Arpeggios. The Arpeggios can be used "live" (no pun intended) or they can be recorded to MOXF sequencer. In order to use them "live" several conditions must be met to begin playback:
The Common Arp Switch must be armed
The Part(s) Arp Switch(es) must be armed
Additionally, a trigger event must occur (within the Arp Note Limits and Velocity Limits)

This means, as player, you are responsible for causing that trigger event... So your timing counts. The "technology" offers the following help:
_ the "Change Timing" parameter found among the ARP EDIT parameters
_ Arp Sync Quantize Value parameter found as a Arp Common Edit parameter

CHANGE TIMING: Determines the actual timing at which the Arpeggio Type is switched when you select another Type during Arpeggio playback. When set to “realtime,” the Arpeggio type is switched immediately. When set to “measure,” the Arpeggio type is switched at the top of the next measure.

SYNC QUANTIZE VALUE: SyncQtzValue (Sync Quantize Value)
Determines the actual timing at which the next Arpeggio playback starts when you trigger it while the Arpeggio of a certain Part is played back. When set to “off,” the next Arpeggio starts as soon as you trigger it. The number shown at right of each value indicates the resolution of the 1/4 note in clocks.
Settings: off, 60 (32nd note), 80 (16th note triplet), 120 (16th note), 160 (8th note triplet), 240 (8th note), 320 (1/4 note triplet), 480 (1/4 note)

The "change timing" setting is designed for when auditioning arpeggio phrase is context of other musical activity... you will want the new selection to fall in at the top of a measure (in sync) with already playing parts. The 'realtime' setting is for when you are auditioning the phrase without other tracks playing and just want the arp to change immediately. With this knowledge applied to your situation you can use this manually offset timing.

When you are feeding trigger/control information to an arpeggiator or arpeggiators control musical phrases, you can be anything BUT late. If you trigger a chord AFTER the beat it may sound like a catastrophe. Say you are executing a series of Arp changes - controlling a drum, bass and chordal instrument - at measure 9 you need to change from Arp1 to Arp2: you can be anything BUT late. By setting the SyncQtzValue setting to "480 (1/4 note)" (480 clock pulses) you can hit that SF button for the top of measure 9 anywhere within the Quarter Note preceding the downbeat of measure 9.
After Measure 8: beat 4, but before Measure 9: beat 1

The "SyncQtzValue" is designed to give the performer some 'wiggle' room when controlling Arpeggio phrases. So SyncQtzValue can be seen as a 'window' of time in which you pre-enter the next control command. By setting it as large as a 1/4 note - even the time challenged among us can find help from the technology... But the rule is ... You cannot be late... Because of the time continuum (time moving ever forward) you cannot fix hitting the chord control information after the downbeat. (Obviously).

The art of controlling automated accompaniment (like arpeggios) is in the slight anticipation that is necessary to "never be late"... While a quarter note is huge, it, of course, depends on the tempo... You may find smaller values useful as well.

If you are controlling arpeggio phrase and playing direct, this complicates things a bit because you need to be on time with your 'direct' playing. So setting the ARP's Note Limits (the Note Limits that determine "control") and the direct Part's PART Note Limit (the limits that determine what notes respond with sound) becomes very important.

Extra Credit
We understand the attraction of the real time nature of the arpeggio. But as an alternative, the arpeggios can be written in the sequencer. Phrases in the Pattern sequencer can be triggered and synchronized to tempo. And they can be started and restarted at any time using the special "Pattern Quantize" feature.
This feature determines the Quantize value for Section switching... Which can be set to the nearest selected value... You can execute wild stutter effects. Set to Pattern Quantize = 1/16 repeated pressing of the Pattern Section button will cause perfectly timed sixteenth note restarts.

Depending on how you are using the ARP's in real time, this alternative may or may not work for you. If you are using the "chord intelligence" feature of arpeggios, then fixing the arpeggio data by recording it to tracks will NOT work for you, but if you are just triggering phrases in a specific key and chord quality, then your phrases can work more like a bit a sampled audio. (Which is another option, if you have a Flash Board installed)!

Thank you for your response.

I haven't really gotten to the point of utilizing the SF buttons within this scheme, though that will come I'm sure since changing the arp type on the fly will certainly come in handy for some of the music we're performing. Nevertheless, so I'm understanding correctly,

• how does the CHANGE TIMING setting determine where the beginning of a measure falls.
• Am I correct that the first note (within the arp's limit settings) triggered after the Arp common switch is engaged will determine where beat one (even clock zero of beat one) is?
• What is the relationship between MOXF phrase timing and the MIDI clock?
• Do the two parameters you highlighted (Change Timing and SyncQtzValue) have any influence over triggering the start of the initial arpeggio type (and therefore the arpeggiator), or does it just govern the changes of arp types from the pre-selected arp launched with the arpeggiator? If so, what?

What I'm experiencing still is lag in the tempo-synced features. They seem to be in tempo for the most part, but enough milliseconds behind to be noticeable (at least to me), and I'm guessing that has more to do with latency. Since the more likely culprit for latency issues is the computer, I'll need to do some streamlining on the OS and DAW end of things. Also, I notice that the tempo that the MOXF reads from the external tempo is sometimes fractionally different from the tempo at which Ableton is running. I assume this is indicative of some inconsistencies somewhere in the timing of the computer outputting the MIDI clock signal. I assume this isn't unusual since latency is inherent to this sort of interfacing. Any tips on how to minimize it, though?

Thanks again for your insight. And thank you for the 'extra credit'. That's something I have planned to explore as well, especially since the workflow of building and performing with patterns is very similar to the workflow in Ableton's Session View.

Sincerely,
Steve

how does the CHANGE TIMING setting determine where the beginning of a measure falls.

By the content of the arpeggio phrase. The Change Timing is designed to allow auditioning of different phrases - with Change Timing set to "measure" you can ensure the new phrase will drop in in sync with other arp phrases that may already be playing.

Am I correct that the first note (within the arp's limit settings) triggered after the Arp common switch is engaged will determine where beat one (even clock zero of beat one) is?

Same as striking a Key normally will determine where in the flow of time your phrase begins. If you are late, your timing will be behind, if you are early your phrase will be ahead of the beat. It is always YOUR responsibility to place timing of notes. The difference here is ... It is more difficult to hide being late or early because the entire phrase is triggered according to your tardiness or anticipation.

What is the relationship between MOXF phrase timing and the MIDI clock?

If you are 12 clock ticks late, the Arp phrase will be consistently 12 clock ticks behind the beat, until you correct it. Like gears on a bicycle, if you drop into the right slot, everything is locked in time, miss the right slot then you remain off by that initial amount. The good news it is consistent, the bad news ... It's your responsibility!

Do the two parameters you highlighted (Change Timing and SyncQtzValue) have any influence over triggering the start of the initial arpeggio type (and therefore the arpeggiator), or does it just govern the changes of arp types from the pre-selected arp launched with the arpeggiator? If so, what?

They have to do with maintaining the synchronization once you start it properly. If you trigger ARP1 on time using the keyboard, switching to [SF2] ARP2 can be ensured by the SyncQtzValue - say it is set to 480 (quarter note) pressing [SF2] anywhere in the last beat before you want to change will ensure ARP2 will start perfectly at the top of the next quarter note. If that is beat 4 in 4/4 time, ARP2 will come in in time at the start of measure 1's downbeat.

What I'm experiencing still is lag in the tempo-synced features. They seem to be in tempo for the most part, but enough milliseconds behind to be noticeable (at least to me), and I'm guessing that has more to do with latency.

I'm guessing it has little or nothing at all to do with latency.

Also, I notice that the tempo that the MOXF reads from the external tempo is sometimes fractionally different from the tempo at which Ableton is running. I assume this is indicative of some inconsistencies somewhere in the timing of the computer outputting the MIDI clock signal. I assume this isn't unusual since latency is inherent to this sort of interfacing. Any tips on how to minimize it, though?

Sync is one of those absolutes, there is no such thing as almost sync'd, it either is or it is not... At least practically speaking. For example, the clocks can be sync'd and yet you can be experiencing chaos. Say you miss the downbeat triggering the arpeggio by 30 clock ticks... The MOXF if sync'd will remain absolutely faithfully 30 clocks off. It will not catch up, it will not slip farther behind... And this is precisely because it is sync'd.

This will sound wrong because like the sprockets on that bicycle chain, you've connected to the wrong sprocket slot. Every note of the arp phrase is 30 clocks late (precisely). Had your gear slipped into the proper slot (clock 000) it would not only be sync'd but it would sound correct. Arpeggios are different from Arranger Styles... Arranger Styles are designed to make the player "look good" - if your timing is a little off they force the playback to the prevailing tempo and the phrases to lock into the prevailing tempo. Arpeggios can be purposefully offset by the performer, you can start arpeggios an eighth note behind or ahead of the beat on purpose. This is a feature (although not one that you are interested in using)... You are interested in using them as static fixed data.

Here is what is going on... Clock sync in MIDI is making sure the devices are referencing musical timing in the same manner. Where YOU place notes is the wildcard. You can play on the beat, ahead of the beat, or behind the beat. And that is always YOUR responsibility. It is one you gladly accept in all but THIS situation. If you miss the beat nothing will point this out like a MIDI phrase you are starting manually with just one Note-On event.

Once you have the clocks sync'd they are sync'd, any timing anomalies are basically the fault of the performer.
You should use EXTERNAL instead of AUTO. Both are looking for a master clock source. The difference here is Auto allows the MOXF clock to run at the last received tempo, but run even if you stop the clock source. Designed for when you are selecting Arp Phrases, you do not have to start your DAW just to hear the Arp Phrase. EXTERNAL will prevent the MOXF from running when tithe DAW is stopped.

When you set Arp Hold = SYNC-OFF, the arpeggio timing continues so that you can lift your hand to stop triggering the tone engine, but when you re-engage the keys the phrase will pick up from where it would be at the time you re-engage. The phrase continues its original timing rather than resetting to the top of the phrase each time. If the arp was playing "Mary had a little lamb" with HOLD = Sync-Off a note-on at quarter note 1 and another at quarter note 4 would produce the words "Mary" and "lamb" only, instead of "Mary", "Mary"
This can be very useful, but only when you have the initial strike in the right gear sprocket. If you miss that initial timing by 30 clock ticks, re-engaging will be 30 clock ticks off.

We are saying the same thing - just in different ways. It's really simple. If you are manually playing a musical phrase and you are slightly late on the first note, you "make up" that late timing in the next couple of notes of your phrase (the law of falling behind and catching up), but if you are late triggering an Arpeggio "played" phrase, it will remain slightly off from that point forward.

If you are going to use ARP's live, it is always going to be your responsibility to trigger the phrases in time. Once you get them running in time, then the technology can help you keep it there, but only YOU can trigger that initial event ... (Or as you mention, you can place the trigger event in your external sequencer data).

Sorry, we don't know exactly how you are working, but we standby our recommendation of transferring arpeggio phrases into MOXF Pattern Phrases (Record the arp to the Pattern Sequencer of the MOXF) reason: the data can be perfectly corrected as to the clock tick it starts on, and real time control over start timing of Pattern Sections is quantizable. Not sure how you are using your DAW but if you are triggering audio phrases by touching pads or keys and they have some kind of mechanism to start always at the top of the next measure.... Anyone can do that, ARP's do not start with just an ON switch... They require ON plus musically intelligent input (chord or note). Pattern Phrases can be triggered more like audio clips. An ON command is all that is necessary.

Of course there is a trade-off musically... If you are creatively interacting with the Arp phrase, recording them as MIDI data does fix the phrases... And may kill your real time interactivity. Mileage will vary.

So what to do... Practice. And that is a serious answer, like playing in time, triggering ARP's is a form of playing in time. You can blame latency or the technology, but mostly it is very real time and the timing is a human responsibility thing... Like manipulating turntables, it is something the more you do it the better your skills at doing it.

You've confirmed for me that I was understanding things correctly. At least mostly, anyway,...I think.

I get that the performer has the responsibility of triggering the arp in time, and that practice makes...well, more likely to be accurate. Still, I don't want to think about the arp when I'm playing "live". I also don't want to be locked into having to play on a downbeat to hear the arp lined up to the measure. I may want to come in on the "and" of beat three instead. The sync-off HOLD setting is perfect for allowing me to do this so long as the arp has been triggered precisely prior to needing to play.

By having my DAW supply the clock and also the message to turn the arp switch on and then trigger the first note precisely on the downbeat, I'm having trouble understanding how the arp could be behind. I've taken human imprecision out of the equation. The daw is successfully turning the arp switch on, triggering the first note, which does indeed start the MOXF arp. I have verified this by letting the daw first turn the switch on and then trigger the first note and then I purposely play so far out of time that it would be obvious whether the arp had been launched by the computer or by me. In every case the arp is closer to the daw's timing, not mine. The sync-off setting helps make this clear too. If I play and the arp starts in the middle of the arp phrase, then I know that the arp was already running prior to my playing, showing that the daw actually did the switch and trigger the arp for me. This is what I want. At the top of the song, before I need to play my parts "live", I want ableton to start the MOXF arp discretely (I use a very short, low velocity note within the arp limits). By doing this, any subsequent notes I play should arp in perfect sync. Again, all the automated triggering is working but the timing often lags behind by milliseconds. This is not human error because I've taken the human element out. I can have ableton send a chord quantized to the downbeat to the MOXF arpeggiator after it has been triggered and it might be in time or milliseconds behind. No slipping, just ever so slightly behind. That's what makes me think latency is involved. If the computer, for whatever reason, is sending that trigger note slightly late (or it's arriving late to the MOXF) in relation to the click it's supplying, then wouldn't this account for the kind of lagging I'm sometimes hearing.

I've taken human imprecision out of the equation. The daw is successfully turning the arp switch on, triggering the first note, which does indeed start the MOXF arp.

I would manually turn the Arp Switch On. If I'm reading this correctly, on the downbeat you have a message (Sysex) to turn the Arp Switch On, and you have a Note-On and you think that all of that can happen simultaneously... I don't think so.

If you know you are going to use the arpeggio just start with it ON, remove that Sysex message. Sorry, I'll have to setup something similar to really understand what you are trying to do. But my first gut reaction is: eliminate System Exclusive messages, they are or can be notorious for causing timing glitches.

And there is never (thankfully) a way to take the human imprecision completely out of the equation. It is music, after all. 🙂

I have the sysex message sent a 1/16 or more (depends on the tempo) prior to the trigger key. That piece of it is working just fine. If the arp switch message came too late, the arp wouldn't trigger at all, but it does. Also the issue shows up whether I manually engage the Arp switch or let Ableton do it for me.

As for taking the human imprecision out, I agree with you, and I certainly don't want to even try to eliminate the human element. In part, that's why using the pattern phrases and SF buttons isn't quite what I want. The arpeggiator is there to do, at least to some extent, what a human can't (easily) do. I'm doing a number of other things when I perform live, so any task I can hand over to the technology is helpful. I have to be musically and technically creative in advance, if you will. 🙂

At the very least, exploring the technical aspects like these leads to a deep and thorough grasp of the capabilities of the keyboard and the many options it provides to be musical (and technically) creative. Thanks so much for your help in understanding the ins and outs of my instrument so I can maximize its functionality for the kinds of creative ways I want to use it.

Sincerely,
Steve

Thank you for the details you've provided. I'm going to go ahead and say I understand what you are attempting to do. The arpeggios are definitely interactive, and I understand a bit better that you need the technology to work with you because, as you say, you are doing a number of other things.

I will have to take a closer look at how the arpeggiators behave when asked to synchronize to an external clock and yet follow real time commands. In theory, it should be no different than the arpeggiators following the MOXF clock (which they do by design). So syncing the MOXF to your DAW should do the trick. I'm sure you've done this but make sure your DAW is actively sending clock and not just a Start command (I've found that many computer-based sequencers do not always default to sending clock... Often they are preserving every bit of CPU muscle until it is needed).

I will attempt to setup a situation where the Arp Hold is set to Sync-Off, and get it running in 'background sync' as you've explained. I'll let you know what I find. I've worked with enough gear to know one needs to actively test the 'theories'. Give me a few days, I've got a lot on my plate right at the moment...

My initial thought (before testing) is that there are still a few wildcards... If audio clips are involved, their relationship to MIDI Clock is always a wildcard, particularly when it comes to feel. An arpeggio phrase could be in sync but have the totally wrong feel against the audio. This can be interpreted as a timing error, when in fact, it is not. Because an arpeggio does not fit with a fixed piece of audio (or even a set piece of MIDI data) does not mean it is out of sync. It may simply not work, musically.

And while the timing and feel of arpeggios are flexible, one cannot guarantee that a particular arpeggio will "fit" in any given situation. I hope you can understand what I'm hinting at... I would suggest you (also) test some very basic, straight feeling musical examples between your software and the MOXF arpeggios.

At any rate it is an interesting experiment.

I have a similar problem and I have to say that I think there is a bug in the motif series here. I've read some other threads about this issue and Yamaha apparently can't reproduce it.

For me it's like this:
I control the XF8 from Cubase with several tracks, one of them using a guitar arp,
I am fairly sure that the basic sync settings work, since the tempo of the arp is in- or decreased following eventual tempo changes of the cubase project, I don't change tempo over time mind you, just the whole project.

The arp is recorded (or inserted manually) exactly at e.g. position 0.0.0.0. What happens? - The arp is slower then the actual song. It is easier to hear when the project tempo is slow, but is there in any case. Since the arp hold mode is set to "off", I can make activate the ARP in e.g. bar 12.0.0.0 and there it is tighter - i.e. the tempo of the arp is slightly higher. Still not as high as the cubase project, but higher than at position 0.0.0.0.

I don't see how this can be anything but a bug in the motif series, possibly due to the completely overloaded CPU, since the problem is worse in the beginning of a song. I obviously don't know if this is the root cause, but it seems likely to me.

Anyway - I've tried all kinds of options, though obviously not in all combinations, I should add that both my cubase and motif is pretty close to factory default and I've never tweaked anything until I ran into this.

So sorry to say this, but I doubt there is a solution here, other than a fork lift upgrade of the motif.

PS, just to be clear - the arp is starting at the correct time, it is tje tempo of the arp which is the problem.

Henrik,
You issue is not at all clear. Not sure at all a fork lift will help.

I control the XF8 from Cubase with several tracks, one of them using a guitar arp

You do realize the Arpeggiator is located between the XF8 Keyboard and the XF8 Tone Generator. When you say you control the "XF8 from Cubase" are you also triggering the arp via Cubase?

Or more directly, is LOCAL CONTROL On or Off?