Some strange behavior of the MOXF, discussed in this thread,…
http://www.motifator.com/index.php/forum/viewthread/476515/
...got me looking at PRE6 G01 “Hip Voice” on the Motif XF, and I found some equally strange behavior. Filter Type for Element 2 of that Preset Voice is chameleon-like - it takes on the value for that parameter of the previously selected Voice.

Try this, right after powering up the XF…
Select PRE6 G01 “Hip Voice”
Press [EDIT] > [2] > [F3](Filter) > [SF1](Type)
Make note of Type setting (I see LPF18)
Press [EXIT]

Select PRE6 G03 “Night Watch”
Select PRE6 G01 “Hip Voice”
Press [EDIT]
Make note of Type setting (I see LPF12)
Press [EXIT]

Select PRE6 G04 “Pluck Bells”
Select PRE6 G01 “Hip Voice”
Press [EDIT]
Make note of Type setting (I see LPF24A)
Press [EXIT]

The changes occur without editing PRE6 G01 “Hip Voice” at all, just by selecting other Voices and then returning to PRE6 G01 “Hip Voice”.

In addition, if you change the PRE6 G01 Filter Type, and then press [EDIT]/COMPARE (button LED blinking), normally the original Type will be displayed. With the PRE6 G01 “Hip Voice”, the COMPARE function doesn’t change what’s displayed for Element 2 Filter Type.

I checked my XS, and it does the same thing, so this bug has been unsquashed for a while.

Interestingly, if PRE6 G01 is copied to a User Voice location, the weird behavior disappears.

I’m not sure if it is a bug. I think the soundchip is actually capable of more filter characteristics than the 18 user-selectable types. Maybe during development there was a plan for more filtertypes which was discarded in the final product but the voice programmers had to create the presets on an early prototype and burn the ROMs for the final product. So for the soundchip it is perfectly valid voice data but the final UI has no representation anymore for these values. As it doesn’t lead to a OS crash it might just haven’t been recognized yet.

I also found it only by accident when I was interested in how this sound was built. If I had the XF instead of the Moxf, it wouldn’t even look strange ;)

It seems that the Moxf OS shows these dashes for unknown/illegal values and keeps the actual value in memory while the XF seems to display the last known value (from the previous selected voice) in this case. Seems that the XF instead somehow stores the value which is displayed.

Does the filter in your user voice still sound like that special filter or more like the vanilla type which is displayed?

Would be interesting to see how the ES behaves if it has that preset too.

Just wait until someone finds that secret 8 Operator FM synth hidden in that thing :D

Fnord - 11 January 2016 05:03 PM

I’m not sure if it is a bug.[...]

When a Parameter changes in a Voice based only on which Voice was previously selected, that certainly seems like a bug to me. When changing the Value of a Parameter, and then having [EDIT]/COMPARE not cause it to revert to the original value, that also seems like a bug to me, regardless of what the development history might have been.

Normal Voice Filter Type can be changed by SysEx…
F0 43 1n 7F 12 42 0e 00 dd F7
where:
n = Device number = 0~Fh (1~16), typically 0
e = Element number = 0~7h (1~8)
dd = data = 00~15h, as below
00 LPF24D
01 LPF24A
02 LPF18
03 LPF18s
04 LPF12
05 LPF6
06 HPF24D
07 HPF12
08 BPF12D
09 No change in display or noted audibly when message sent
0A BPFw
0B BPF6
0C BEF12
0D BEF6
0E Dual LPF
0F Dual HPF
10 Dual BPF
11 Dual BEF
12 No change in display or noted audibly when message sent
13 LPF12+BPF6
14 No change in display or noted audibly when message sent
15 thru

Data values 00~15h would allow for 22 Filter Types. However, there are only 19, and it appears that values 09, 12, and 14 have no effect.

If you want to experiment with the MOXF, the SysEx above should work by changing the 5th byte (Model ID) from 12 to the two bytes 1C 00.

 

Fnord -

Does the filter in your user voice still sound like that special filter or more like the vanilla type which is displayed?

On the XF, I haven’t heard the “special filter” you’ve been describing.

Ok, for the XF you’re right. If a parameter value shows something different every time you select that same preset I’d call that a bug too.
If the engineers can edit voice parameters in a way we user can’t do, it should at least be shown in a way we could recognize. Although it feels a bit sad, that there are some things the Motifs can do which we users can’t reach. :(

I also grabbed the data list and hacked in that SysEx string in the Sequencer back then when I first discovered that penomenon. I had the same behaviour as you had. Seems that invalid/unknown values are replaced with the nearest valid value on SysEx receive. I didn’t try all values up to 7Fh so far but i would bet that the high values are all converted to “thru” or just ignored.

Btw. I just stored my special user voice to a X6V File and loaded that single voice back to another user location. Unfortunately the Moxf does a validity check on load at last and my new voice had the filter replaced with a BPF12.
So although you can trick the Moxf to create a user voice with “extended” parameters, you can’t save and reload it properly.

I even tried to manipulate the File with a Hex editor. Not the filtertype, as I don’t know where that is stored but the voice name just for fun. This is plain ascii and easy to find. So I changed a few characters to values over 7Fh which are out of range.
When I do this at the index area of the file, I get funny graphical characters as voice name in the loading preview.

When I change the voice name characters in the actual voice data area to invalid values, they are converted to tildes (~) on load which is the highest valid character value. So I guess the same would happen to other parameters.

At least there seem to be no checksums in the file as it did load properly.

Fnord - 11 January 2016 09:36 PM

[...]I also grabbed the data list and hacked in that SysEx string in the Sequencer back then when I first discovered that penomenon. I had the same behaviour as you had. Seems that invalid/unknown values are replaced with the nearest valid value on SysEx receive.

My experience with the XF is that messages with invalid Filter Type values are just ignored, not replaced with a valid value.

However, the XF’s response to such things is inconsistent. In some cases other than Filter Type, out-of-bounds values are replaced with the maximum valid value.

Then there’s stuff like this, right from the front panel…
http://www.motifator.com/index.php/forum/viewthread/463622/

 

Fnord - 11 January 2016 09:36 PM

I didn’t try all values up to 7Fh so far but i would bet that the high values are all converted to “thru” or just ignored.

I had already tried several (but certainly not all  :-) ) values in the 16h~7Fh range, and apparently none were recognized.