Hi, I’m not sure if this is a bug or if there’s a workaround for this, but I have a slight problem with the arpegiator behaviour on my MOX6. I have not had it for long so hopefully I’ve missed something. Thanks.

CONDITIONS
[EDIT][COMMON][GENERAL][PLY MODE]
mono/poly = mono

[ARPEDIT][TYPE]
Type = Any arp that repeats the same note (e.g. 6213 or 6217)

[ARPEDIT][PLAY FX]
GateTimeRate = >~120%

EXPECTED BEHAVIOUR (or, what I would like to happen)
As the gate time is increased, the time between note-off and note-on decreases until they hit each other, cancel out, and the note hangs. Imagine a nice uninterrupted synth-lead sound. 

WHAT HAPPENS
The gate-time reaches a threshold around 120% then starts cutting notes short, as if it has plummeted to 0% again. Notes never hang. Note-off has overtaken the note-on and notes are effectively being choked by the previous note.

thrash3 - 23 October 2011 07:29 PM

Hi, I’m not sure if this is a bug or if there’s a workaround for this, but I have a slight problem with the arpegiator behaviour on my MOX6. I have not had it for long so hopefully I’ve missed something. Thanks.

CONDITIONS
[EDIT][COMMON][GENERAL][PLY MODE]
mono/poly = mono

[ARPEDIT][TYPE]
Type = Any arp that repeats the same note (e.g. 6213 or 6217)

[ARPEDIT][PLAY FX]
GateTimeRate = >~120%


EXPECTED BEHAVIOUR (or, what I would like to happen)
As the gate time is increased, the time between note-off and note-on decreases until they hit each other, cancel out, and the note hangs. Imagine a nice uninterrupted synth-lead sound. 


WHAT HAPPENS
The gate-time reaches a threshold around 120% then starts cutting notes short, as if it has plummeted to 0% again. Notes never hang. Note-off has overtaken the note-on and notes are effectively being choked by the previous note.

You are misunderstanding the arp gate function. If you increase the gate time rate you are indeed extending the length of the notes, but if you set output to mono then the
attacks of the notes are always going to retrigger when the note release and the note attack reach the same point.. Thus you end up with the stuttering.

The solution - forget about this if you want something like a sustaining mono note.
You need to do that via an event in a sequence (holding the note as long as you want it to hold). Or simply play the part live.

I’m going to call it a bug. I don’t think the note-off should overlap the note-on of the next note causing it to stutter like that. It’s unintuitive and sounds weird. Though it’s probably just an artefact of the way the arp works and wont be fixed.

The best workaround I’ve found is to put it in POLY mode and be careful not to increase the gate or release time too high.

thrash3 - 25 October 2011 08:12 AM

I’m going to call it a bug. I don’t think the note-off should overlap the note-on of the next note causing it to stutter like that. It’s unintuitive and sounds weird. Though it’s probably just an artefact of the way the arp works and wont be fixed.

The best workaround I’ve found is to put it in POLY mode and be careful not to increase the gate or release time too high.

I guess you still don’t understand what is happening. The arpeggio is
essentially re-triggering notes. If the mode is set to mono there is no way it can possibly “overlap” a release into the attack of the next
note. Think of this as a series of wooden rectangular blocks laid end
to end. The blocks represent notes. You can’t “melt” one wooden block into
another. You could shorten each block so there’s more space between each
block, but once you have all the blocks expanded so that they touch each
other, that’s it. You have no more room to extend the blocks.

If you programmed a repeating line on ANY synth in mono mode, you’re not
going to get a “smooth smear” or constant note. You’re going to hear the notes being re-triggered.

Yes, this is the way the arp works. There’s no “bug”. Sorry if you are
unhappy with the way it works, however, as you seem to realize yourself,
it isn’t going to be “fixed”.

Please try this:

1. set any voice to mono mode
2. Set the arp to 6213
3. hold down a note
4. increase gate-time to 120

What happens?

thrash3 - 25 October 2011 04:08 PM

Please try this:

1. set any voice to mono mode
2. Set the arp to 6213
3. hold down a note
4. increase gate-time to 120

What happens?

Would love to try that but I am in Asia working as keyboard tech/programmer for David Foster and don’t have a MOX at my disposal.

That said, the mono behavior of the MOX will be the same as the XS and XF. I stand by what I said - there is no bug, you just don’t get how it’s working. You won’t get any kind of legato behavior with an arpeggio that repeats the same note over and over.

I mean, you can keep on trying but it isn’t going to happen. So I suggest looking for alternative methods to accomplish what you want.

I’ve been programming synths for nearly 30 years, 20 with Yamaha. Here’s
my approach when I try something and it doesn’t produce the result I want - I go, “ok, it won’t do that” and I move on to find another solution. When you’re in the middle of a show in front of 20,000 people
and something needs quick attention, you don’t have the luxury of posting a thread on some forum and venting...you have to fix the problem
right then and there.

In your case, if I were you, I’d either program the part I want into the
sequence, bypassing any arpeggio and just entering the notes I want, or
I’d play the part live. Never waste time focusing on what “can’t” be done.

Imagine you’re playing in front of 20,000 people and your beautiful long arp notes start choking because you accidentally tweak the gate-time a notch too high.

If you programmed a repeating line on ANY synth in mono mode, you’re not
going to get a “smooth smear” or constant note. You’re going to hear the notes being re-triggered.

I came across this bug trying to re-create an MS2000 patch which does this. Yes, the notes are probably being re-triggered and maybe there’s a tiny glitch, but it’s inaudible and sounds like legato.

I agree thrash3 cause the behaviour of GateTimeRate parameter defined like (Reference Manual, page 28):

“Determines how much the Gate Time (length) of the Arpeggio notes is offset from the original value.
Settings: 0% – 200%”

doesn’t fit the manual and when something like this happens it’s called bug.
From 0% to 100% the parameter fits the manual but from 100% to 200% it doesn’t. I don’t understand what happens when GateTimeRate >= 120% , is 120% like 0%? and then , is 123% like 4%?

Dave the behaviour from 0% to 200% should be countinous! Not different from 120% in advance!

You can be all your live programming keyboards and you are wrong. In fact, during many centuries wise men didn’t think the Earth was round cause they had right calculations about some things and finally they’re wrong in spite of those calculations were right.

nauform - 26 October 2011 01:34 PM

I agree thrash3 cause the behaviour of GateTimeRate parameter defined like (Reference Manual, page 28):

“Determines how much the Gate Time (length) of the Arpeggio notes is offset from the original value.
Settings: 0% – 200%”

doesn’t fit the manual and when something like this happens it’s called bug.
From 0% to 100% the parameter fits the manual but from 100% to 200% it doesn’t. I don’t understand what happens when GateTimeRate >= 120% , is 120% like 0%? and then , is 123% like 4%?

Dave the behaviour from 0% to 200% should be countinous! Not different from 120% in advance!

You can be all your live programming keyboards and you are wrong. In fact, during many centuries wise men didn’t think the Earth was round cause they had right calculations about some things and finally they’re wrong in spite of those calculations were right.

Aaah....you guys go have fun and figure it out. Happy programming!

The man who increased twice what only was possible once. Happy bugging!