I have a question in conjunction with the current status of the “Assignable Function” buttons AF1 and AF2.

Is there any possibility to “store” a specific status (e.g. AF1 = on; AF2 = off) along with all other parameters applicable to a user voice / performance / master preset?

Any kind of parameter status (e.g. for “Assignable Knobs” AS1 and AS2) can be stored / called up having any desired value within the full range, but it seems that not even a simple on/off status setting is memorized for the “Assignable Function” buttons. After selecting any voice, performanance or master, both AF1 and AF2 are always set to off, regardless which status they had when the related user preset was stored before.

Did I miss something? I couldn’t find a way to achieve that goal, not even after looking into the “Utility” parameter section. Thanks in advance.

Edit: just to be more specific on my approach: in my case I’m just talking about presets where the AF buttons are used as “latch” (hold) type buttons, not for momentary use (where you must press and hold an AF button as long as you want to apply the functionality).

B.Minor - 11 December 2014 07:13 AM

I have a question in conjunction with the current status of the “Assignable Function” buttons AF1 and AF2.

Is there any possibility to “store” a specific status (e.g. AF1 = on; AF2 = off) along with all other parameters applicable to a user voice / performance / master preset? [...]

Short answer: No.

Longer answer:
If parameters related to AF button operation must be set a certain way when the Voice/Performance/Master is first selected, then reprogram so the “off” state of the button(s) causes that to happen.

Detailed answer (about XF, but applies to MOXF):
See this thread which includes a link to this other thread.

5pinDIN:
Short answer: No.

Somehow I knew somebody would say that 8-(

5pinDIN:
Longer answer:
If parameters related to AF button operation must be set a certain way when the Voice/Performance/Master is first selected, then reprogram so the “off” state of the button(s) causes that to happen.

Thanks 5pinDIN for the linked references. I also fully understand the request to “inverse” the parameter setup in such a way that the desired “startup” functionality is already achieved with all AF switches set to “off” after selecting a new preset. However, this will not always work for certain situations where AF switches are assigned to several elements at the same times in order to achieve different simultaneous effects. Let me explain why:

Currently the following set of AF settings is available for assignment to voice elements:

- all AF off (all Assignable Functions off)
- AF1 On (Assignable Function 1 on)
- AF2 On (Assignable Function 2 on)

In order to “inverse” the way the AF switches currently impact the same sounds, I’d have to use the following command set:

- all AF on (all Assignable Functions on)
- AF1 off (Assignable Function 1 off)
- AF2 off (Assignable Function 2 off)

Unfortunately exactly this mentioned set of commands is NOT available on the Motif series, that’s why there was my request to have them rather switched on by default.

However, I guess I’ll have to re-think everything in order to get a similar result without messing up everything. As mentioned, I’m not sure I can find an acceptable solution for the same functionality without having the mentioned set of AF parameters available, but I’ll try my best. Thanks a lot.

You’re welcome.

Exactly what you need to accomplish, and factors such as number of unused Elements in a Voice, etc., will determine whether you can obtain a satisfactory result.

This issue isn’t new. You might find these interesting:
http://www.motifator.com/index.php/forum/viewthread/452161/
http://www.motifator.com/index.php/forum/viewthread/470304/

I have not done this myself, but can’t patterns save button/knob movements?  I know many preset patterns turn AF1/AF2 on/off while they play.  Perhaps you can create a pattern with no note data, just record the AF1/AF2 on the first tick.  Once playing, you will need to turn off the arpeggio, otherwise the AF buttons will reset at the beginning of each repeat.

5pinDIN:
Exactly what you need to accomplish, and factors such as number of unused Elements in a Voice, etc., will determine whether you can obtain a satisfactory result.

This issue isn’t new. You might find these interesting:
http://www.motifator.com/index.php/forum/viewthread/452161/
http://www.motifator.com/index.php/forum/viewthread/470304/

5pinDIN, thanks again for your referenced threads - appreciate it. I’ve already been thinking about exactly the approach you described in the second thread. Using additional 2 elements would be the only chance to have a “workaround” here for my voices.

Unfortunately I wanted to apply those functionalities to my customized piano voices, for which each element is either used for “normal” piano waveforms, “string release” waveforms or even “hammer noise” waveforms, meaning that there are simply no unused elements available. Choosing this approach to overcome the lack of missing “AF parameters” would only mean that I’d have to sacrifice at least 2 elements currently containing piano waveforms - and therefore I’d also lose some velocity zones which is not acceptable in my case. Or I’d have to work with performances exclusively, always having at least two voices “coupled” together. That’s why I already excluded that approach from my previous considerations.

So, I guess I can only add my voice to the “Wish List for Motif” which is the original title of your linked thread ;-)

SSquared,
I have not done this myself, but can’t patterns save button/knob movements?  I know many preset patterns turn AF1/AF2 on/off while they play.  Perhaps you can create a pattern with no note data, just record the AF1/AF2 on the first tick.  Once playing, you will need to turn off the arpeggio, otherwise the AF buttons will reset at the beginning of each repeat.

SSquared, I really like your approach - I haven’t thought about that before. If I understood correctly, you’re proposing to record a pattern first in which the commands for turning on the AF buttons are already included, e.g., in the first bar. That sounds really promising!

However, do you think those MIDI events (which probably might be in SysEx format - I haven’t checked yet) would “survive” the conversion to a certain “User Arpeggio” which then is allocated to the desired piano voices and which is starting automatically when pressing the first key after preset selection? Or would this approach only be applicable to song/pattern mode where I’d have to start/stop the sequencer manually by using the “transport” buttons?

Having the “AF on” commands “embedded” natively inside a user arpeggio would really save my day…

I hoped they would survive to a User Arpeggio, but I have not tried it myself.  I have not really spent much time at all with the sequencer, only one time just to verify I could make a user arpeggio, then never used it again.  But I know there are several preset arps using this feature.

The one drawback with this approach (if it does work), is remembering to turn off the arpeggio.  I know I can forget details like that.

My initial thought was to use an external device that will both select the voice AND turn on AF1 and/or AF2.  I sometimes use the app “TB MIDI Stuff” on my iPad for editing/controlling my synth.  You can define a control that will both select a specific sound and send a control change at the same time.  (AF1 - CC #86, AF2 - CC #87).  But I didn’t know if this was an option for you and you probably prefer an on-board option.

SSquared, thanks for your information and for sharing your experiences.

At the weekend I’d have to find out which kind of MIDI messages actually can turn on/off AF buttons, e.g. by recording the physical button strikes to a MOXF pattern and then playing it back again, in order to see if that approach would work at all. However, I think the cc86 and cc87 MIDI messages are only considered to manipulate the parameters which are currently assigned to AF1/AF2 in a certain control set (e.g. filters or effects), presuming the (latched) AF buttons have already been switched “on” in advance, but I’m not sure about that. The main task will be just to find a way to “activate” these AF buttons automatically. I only hope this task won’t turn out as one of these bad examples where the dragon bites its own tail and begets and nourishes itself.

As I don’t have an iPad to play around with, I’ll better choose the on-board method to do all experiments “in the box”. The challenging thing for me will be to manage that transformation from a recorded MOXF pattern to a user arpeggio (I also haven’t done that before). Twiddly.Bits mention in one of their promotional videos that it’s super-easy to convert any pattern source material into user arpeggios (I also don’t own any of their products), but this is still no guarantee that all recorded events (probably including messages in SysEx format) would also end up in such a “converted” arpeggio track.

I’m curious if that “Job -> Put Track to Arpeggio” command will really work out, or if anything else than pure MIDI notes or MIDI control messages is filtered out by default in the MOXF during the conversion. However, I already read some alarming sentences from the Arpeggios Explored Part I tutorial, explaining which kind of data an arpeggio can hold:

[...] They can include note data and/or controller data [...]

Hmmm, if AF button on/off commands really turn out to be in SysEx format (I’ll have to check first), I guess I can forget that approach completely.

Or I am totally wrong and the cc86 and cc87 MIDI control messages do really nothing more than to switch these two AF buttons on and off, meaning they can only hold the values 0 and 127. If so, then it might really work as you proposed, SSquared! I must have a look at the specs when I’m at home…

B.Minor - 12 December 2014 04:56 AM

[...]Or I am totally wrong and the cc86 and cc87 MIDI control messages do really nothing more than to switch these two AF buttons on and off, meaning they can only hold the values 0 and 127. If so, then it might really work as you proposed, SSquared! I must have a look at the specs when I’m at home…

Written about the XF, but should apply to the MOXF:
http://www.motifator.com/index.php/forum/viewthread/473003/

See (3-1-3) CONTROL CHANGE on page 120 of the MOXF Data List.

B.Minor, yes, I use CC #86/#87 and I believe send 0 or 127 to turn it on/off from the iPad app.  In case you are wondering why I would control AF1/2 from an external app (instead of directly from the keyboard), I made the template for my Motif Rack-XS.

SSquared, thanks for your confirmation on the general approach.

5pinDIN, thanks for directly pointing me to the relevant section in the MIDI data list.

Just for my curiosity: Following your information and looking at the MIDI specification for the cc86 and cc87 “assignable controllers”, does it mean that any values between 1 and 126 (which are actually part of the listed range) don’t really matter for triggering any MOXF functionalities? Or is this eventually a similar situation as for the (momentary) sustain pedal (cc64) behavior (e.g. in case an FC4 is used), where 0 to 63 may be interpreted as “off” and 64 to 127 as “on”?

I’m just asking, as I found out in this thread that even foot switch (FS - cc88) resources could internally be “abused” inside the MOXF in order to make meaningful use of any value between 0 and 127, even if this controller is defined as a “switch” - like the AFs are in fact.

Btw., I haven’t tried to record/convert my pattern/arpeggio yet (I will do this later this weekend when I’m at my keyboard). However, I guess I will also have to make the arpeggio (containing these cc86/cc87 events assigned to a voice) run only once when first triggered (instead of letting the events repeat frequently). I hope that can be achieved somehow. I let you know later…

Again, thanks guys for your contribution.

B.Minor - 12 December 2014 03:30 PM

5pinDIN, thanks for directly pointing me to the relevant section in the MIDI data list.

You’re welcome.

 

B.Minor -

Just for my curiosity: Following your information and looking at the MIDI specification for the cc86 and cc87 “assignable controllers”, does it mean that any values between 1 and 126 (which are actually part of the listed range) don’t really matter for triggering any MOXF functionalities? Or is this eventually a similar situation as for the (momentary) sustain pedal (cc64) behavior (e.g. in case an FC4 is used), where 0 to 63 may be interpreted as “off” and 64 to 127 as “on”? [...]

When the AF buttons are operated, the Motifs output the values 0(off) and 127(on), and they respond to those values. Offhand, I don’t know how the MOXF interprets any intermediate values for CC86 and CC87. Obviously, it wouldn’t be difficult to experiment and find out.

I’d like to warm up this old thread because I have one more question related to this topic. After having the discussed solution in place for quite a while, one important piece of information is still missing which would make life much easier.

Initially SSquared provided the great idea to use an Arpeggio track (created from a recorded Pattern) to switch on the AF1/AF2 buttons automatically as required whenever the first note of a newly selected Voice/Performance/Master is played. However, instead of dealing with CC# events, 5pinDIN finally provided a very elegant way in this thread to activate/deactivate any AF button combination by applying simple SysEx commands which I successfully tested on my MOXF:

AF1 off / AF2 off:
F0 43 10 7F 1C 00 70 05 00 00 00 F7

AF1 on / AF2 off:
F0 43 10 7F 1C 00 70 05 00 01 00 F7

AF1 off / AF2 on:
F0 43 10 7F 1C 00 70 05 00 02 00 F7

AF1 on / AF2 on:
F0 43 10 7F 1C 00 70 05 00 03 00 F7

This approach will work in any MOXF mode - so far so good. Now, the only thing that would be missing is that the running Arpeggio stops by itself after some time instead of periodically re-triggering the same AF1/AF2-related commands at the beginning of its loop again and again. In other words, I’d be looking for a solution to put a related (and maybe undocumented) SysEx command into the track which stops itself. If you will, it’s like if the Arp track is “committing suicide” after about one bar of playing. However, I only hope that such a command would *NOT* automatically “reset” the AF1/AF2 switch status as well…

I found some evidence that there was at least a way for the Motif XF to control Arps 1 to 4 - as part of a Performance - via SysEx commands:
http://faq.yamaha.com/us/en/article/music-production/synthesizers/sy-motif_xf_wh/motif_xf8_wh/10839/8480/

But what if we’re talking about pure Voice mode only (which is my preferred one) where only one single Arp is active? Do you think that approach could also work there by applying the related command for “Part 1” (and by changing the ID to MOXF accordingly)? Or do you know any other SysEx command that could do such a job?

One more thing: I don’t want to go the path assigning “Arp on/off” to the foot switch, as I need its resources to control other things. An assignment via UTILITY menu is not what I’m really looking for, as I’d like to have all related functionality embedded in this one and only Arp track. Do you think this is achievable? Thanks a lot in advance.

I’m not sure which (if any) of the following will help, but here it is…

Emulates pressing the ARP ON/OFF button while in Voice mode:
F0 43 10 7F 1C 00 40 30 0E 00 F7 Arp off
F0 43 10 7F 1C 00 40 30 0E 01 F7 Arp on

F0 43 10 7F 1C 00 40 30 14 00 F7 Arp Loop off
F0 43 10 7F 1C 00 40 30 14 01 F7 Arp Loop on

F0 43 10 7F 1C 00 40 30 15 00 F7 Arp Hold sync-off
F0 43 10 7F 1C 00 40 30 15 01 F7 Arp Hold off
F0 43 10 7F 1C 00 40 30 15 02 F7 Arp Hold on

None of the above SysEx messages should affect the on/off status of the MOXF AF buttons. I’ve verified that they work as expected on my XF (with proper model ID byte, etc., of course).

None of the above are undocumented - all are from the MOXF Data List.

I hope that helps, although I’m going to leave further investigation to you.

Hey, thanks a lot, 5pinDIN! Somehow I must have missed that in the data list. I’ll report back if it worked out.

B.Minor - 18 November 2016 08:10 AM

Hey, thanks a lot, 5pinDIN! Somehow I must have missed that in the data list. I’ll report back if it worked out.

You’re welcome, but, sorry, I had the third and eighth bytes incorrect in the above SysEx messages. I’ve corrected them.

Apparently I’ve got to get more sleep  :-)  . The recent change from “daylight saving time” has played havoc with me.

EDIT: I also had a typo in the ninth byte of the first two messages, corrected as well. My brain hurts.