Factory Preset Bug (with fix)

[chysn]

While developing a sysex editor/librarian for Prophet 5/10 Rev 4, I noticed that all of the voice names (not displayed on the the instrument, obviously, but in memory) are padded to the end with spaces (character 0x20). In many of the factory presets, including every single one of the "classic" Prophet-5 presets in Factory Group 5, they padded one space too far, which encroaches on storage of the Q Compensation parameter. For Q Comp, 0x20 corresponds to a setting of 2 on a range of 0-7.

This means that--if you have Q Compensation enabled on global page 3--you're hearing the factory presets incorrectly, with a bit of Q Compensation inadvertently applied. This probably hasn't been noticed before due to lack of Q Comp parameter support among commercial editors.

Attached is a ZIP archive containing all five factory groups with Q Compensation set to 0 for every program. If you send these to your Prophet, you'll go back to hearing the factory presets as they were intended, while still allowing you to use Q Comp on your own programs.

[strytten]

Thank you Chysn - this is a really interesting and important posting, and you have done us all a great service!

Funny, a few days ago I emailed the support for the editor librarian that I use asking about when they might be supporting the new data fields from the latest update, including Q Comp.

In the meantime, is it safe to assume that bulk dumps from the Prophet into an editor librarian and saved on the computer will include this latest data, even if I don't see it in the editor? In other words, I can continue programming, naming, and saving using these latest data fields and the only functionality I don't have is to see these latest data fields in the editor on my computer screen?

Thanks!

[g3o2]

Is it a big sonic difference in your opinion?

And thank you for sharing your findings here! 

[chysn]

In the meantime, is it safe to assume that bulk dumps from the Prophet into an editor librarian and saved on the computer will include this latest data, even if I don't see it in the editor? In other words, I can continue programming, naming, and saving using these latest data fields and the only functionality I don't have is to see these latest data fields in the editor on my computer screen?

Yeah, the fields shouldn't need to be supported in the software to be preserved on the instrument through sysex dumps. The programmers would need to actively work at doing things wrong to lose data.

Is it a big sonic difference in your opinion?

No, the difference between 0 and 2 is very subtle, even with lots of resonance. But also, my ears are 52 years old and are mediocre at best. This is all about data.

[LPF83]

This is a great find!  I hope Sequential will address it in a future update; have you informed them directly of the issue?

[chysn]

This is a great find!  I hope Sequential will address it in a future update; have you informed them directly of the issue?

No, I just noticed it today, and I'm sure nobody is around over there yet.

But it would be an easy enough fix, involving exactly what I did already with the factory programs. There's no need for any OS updates. Moving the Q Comp parameter backwards would just piss me off.

[LPF83]

This is a great find!  I hope Sequential will address it in a future update; have you informed them directly of the issue?

No, I just noticed it today, and I'm sure nobody is around over there yet.

But it would be an easy enough fix, involving exactly what I did already with the factory programs. There's no need for any OS updates. Moving the Q Comp parameter backwards would just piss me off.

I guess I was have been assuming the OS update is what they would need (or want) to do to fix the padding of the original presets.  Even if not necessary, just for the sake of consistency in customer communication (i.e. "Grab the latest update" is something their customers are already doing occasionally anyway, whereas the padding issue in the factory patches is kind of an edge case that's a little harder to explain, even if the process for correcting them is easy).

[g3o2]

Given that the user region is a copy of the factory region and that there is no way to edit the preset name on device, it is likely that this has affected any default patch or user copy created on device.

[chysn]

Given that the user region is a copy of the factory region and that there is no way to edit the preset name on device, it is likely that this has affected any default patch or user copy created on device.

Possibly, if your program was based on an affected program. You can check the Q Comp value by holding down the REV button.

I guess I was have been assuming the OS update is what they would need (or want) to do to fix the padding of the original presets.  Even if not necessary, just for the sake of consistency in customer communication (i.e. "Grab the latest update" is something their customers are already doing occasionally anyway, whereas the padding issue in the factory patches is kind of an edge case that's a little harder to explain, even if the process for correcting them is easy).

I think the best solution on Sequential's part would be to correct the factory program file at

https://sequential.com/wp-content/uploads/2020/11/Prophet-510-Factory-Programs-ReadMe1.02.zip

I don't have any way of knowing if this is a widespread issue. It's important to reiterate, the problem is in the factory preset file, not the Prophet-5 itself. I don't even know if they use this file for setting up new instruments.

If you have Q Compensation enabled, you can check by going to Factory #115, and holding down the REV button. The display will read RES, and the Q Comp setting will be one of the Program select buttons. In the program in the above file, the third Program button is lit, indicating Q Comp = 2.

If the first Program select button is on instead, then there's no issue on your instrument. But you'll definitely see the issue if you've used that file, or if that file is what they use at the factory.

I'd be interested to know if others see it, particularly if you haven't explicitly run the factory sysex file.

[Quatschmacher]

Given that the user region is a copy of the factory region and that there is no way to edit the preset name on device, it is likely that this has affected any default patch or user copy created on device.

Possibly, if your program was based on an affected program. You can check the Q Comp value by holding down the REV button.

I guess I was have been assuming the OS update is what they would need (or want) to do to fix the padding of the original presets.  Even if not necessary, just for the sake of consistency in customer communication (i.e. "Grab the latest update" is something their customers are already doing occasionally anyway, whereas the padding issue in the factory patches is kind of an edge case that's a little harder to explain, even if the process for correcting them is easy).

I think the best solution on Sequential's part would be to correct the factory program file at

https://sequential.com/wp-content/uploads/2020/11/Prophet-510-Factory-Programs-ReadMe1.02.zip

I don't have any way of knowing if this is a widespread issue. It's important to reiterate, the problem is in the factory preset file, not the Prophet-5 itself. I don't even know if they use this file for setting up new instruments.

If you have Q Compensation enabled, you can check by going to Factory #115, and holding down the REV button. The display will read RES, and the Q Comp setting will be one of the Program select buttons. In the program in the above file, the third Program button is lit, indicating Q Comp = 2.

If the first Program select button is on instead, then there's no issue on your instrument. But you'll definitely see the issue if you've used that file, or if that file is what they use at the factory.

I'd be interested to know if others see it, particularly if you haven't explicitly run the factory sysex file.

Please do submit your findings directly to sequential as it will help all of us. Many thanks for investigating this.

[LPF83]

Given that the user region is a copy of the factory region and that there is no way to edit the preset name on device, it is likely that this has affected any default patch or user copy created on device.

Possibly, if your program was based on an affected program. You can check the Q Comp value by holding down the REV button.

I guess I was have been assuming the OS update is what they would need (or want) to do to fix the padding of the original presets.  Even if not necessary, just for the sake of consistency in customer communication (i.e. "Grab the latest update" is something their customers are already doing occasionally anyway, whereas the padding issue in the factory patches is kind of an edge case that's a little harder to explain, even if the process for correcting them is easy).

I think the best solution on Sequential's part would be to correct the factory program file at

https://sequential.com/wp-content/uploads/2020/11/Prophet-510-Factory-Programs-ReadMe1.02.zip

I don't have any way of knowing if this is a widespread issue. It's important to reiterate, the problem is in the factory preset file, not the Prophet-5 itself. I don't even know if they use this file for setting up new instruments.

If you have Q Compensation enabled, you can check by going to Factory #115, and holding down the REV button. The display will read RES, and the Q Comp setting will be one of the Program select buttons. In the program in the above file, the third Program button is lit, indicating Q Comp = 2.

If the first Program select button is on instead, then there's no issue on your instrument. But you'll definitely see the issue if you've used that file, or if that file is what they use at the factory.

I'd be interested to know if others see it, particularly if you haven't explicitly run the factory sysex file.

I just tried the test, and got a different result, the first program button was lit indicating Q Comp = 0.  I decided to flip through some of the other factory presets, looking for a non zero value, but could not find any (starting from 111, I stopped about halfway through Group 3).  Hope this helps in some way.

About my earlier comment, I guess a better way to describe the wishlist item I had in mind would be that I'd like to see Sequential just release and support a unified updater that can be used to just update their instruments unconditionally to the latest version (or a specific version) as if it were shipped from the factory in that state.  I'm just contrasting that with separate OS and panel updates, the potential need to fix factory patch banks separately, all using a third party utility, etc.  I just think this would benefit them as much as the customer by limiting the number of edge cases they need to support and simplifying the approach to restoring things to be as intended...  That said I can't really complain much about my experiences with the existing processes -- I haven't yet bricked a unit or encountered a major problem with the process.

[chysn]

I just tried the test, and got a different result, the first program button was lit indicating Q Comp = 0.  I decided to flip through some of the other factory presets, looking for a non zero value, but could not find any (starting from 111, I stopped about halfway through Group 3).  Hope this helps in some way.

Thanks, that is helpful. And you have Q Comp enabled? It means that the issue is in the specific sysex file on the Support webpage, and wasn't necessarily loaded into a bunch of Prophet-5s at the factory. If you had this file in your Prophet, you'd see Q Comp = 2 pretty frequently, at least a couple per bank and all of group 5.

I guess a better way to describe the wishlist item I had in mind would be that I'd like to see Sequential just release and support a unified updater that can be used to just update their instruments unconditionally to the latest version (or a specific version) as if it were shipped from the factory in that state.

Yeah, that does seem to be the modern way to do it.

Please do submit your findings directly to sequential as it will help all of us. Many thanks for investigating this.

Yes, I will. Now that I can pinpoint the source of the issue (the downloadable file), it's easy enough to demonstrate what I'm seeing.

[mwl5]

Does the Q comp affect the tone regardless of what the resonance is set at for a patch? Was I incorrect in assuming the Q comp just helps increase bass as the resonance is turned up?

[chysn]

Does the Q comp affect the tone regardless of what the resonance is set at for a patch? Was I incorrect in assuming the Q comp just helps increase bass as the resonance is turned up?

It affects the tone in conjunction with cutoff and resonance. The Prophet-5 filters lose bass as resonance increases, so this compensates for that to the degree determined by the Q Comp parameter.

[chysn]

OK, as some of you suggested, I have written to Sequential Support re: this. It's in their hands now!

[waxdoctor]

Also the Velocity values in the Factory Group 5 differ in some patches and not all are on 127.
e.g. Factory 511 has 075 on mine.
(I know, the original P5 and its patches did not have Velo or AT, I know)

[chysn]

Also the Velocity values in the Factory Group 5 differ in some patches and not all are on 127.
e.g. Factory 511 has 075 on mine.
(I know, the original P5 and its patches did not have Velo or AT, I know)

Indeed. It doesn’t change the off-the-shelf sound, but that odd data is lurking there. When I can (next week), I will fix those up, too (all to 127) and update my sysex files on this topic.

Thanks for pointing that out.

[electronicsupersonic]

I see Soundtower's last update is Version 1.4.0 - September 12, 2023, did they respond when notified?

[chysn]

I see Soundtower's last update is Version 1.4.0 - September 12, 2023, did they respond when notified?

I’m not sure what you’re asking. This involves Soundtower exactly not at all.

[electronicsupersonic]

I see Soundtower's last update is Version 1.4.0 - September 12, 2023, did they respond when notified?

I’m not sure what you’re asking. This involves Soundtower exactly not at all.

Apologies if any confusion sprung from that, I was referring to the earlier post-

Funny, a few days ago I emailed the support for the editor librarian that I use asking about when they might be supporting the new data fields from the latest update, including Q Comp.

they might not be referring to ST either! I was just curious if that possible data condition might not be handled through it.