Notifications
Clear all
Topic starter
For benchmarking and research purposes I created the following MIDI file:
It is panned fully to the left and has 127 Main Volume.
There are 101 notes, each 1 second long with 1 second between them.
For each note, Expression begins at 100 and goes down to 0.
A custom sample was created for this test by hand. It has default new-sample parameters except that there is no filter, the release time is 0, all effects are disabled, etc. It is included as an attachment to this post.
The resulting WAV file, exported directly to USB, is shown:
That’s an OS bug. You can get similar results by tapping a key over and over as well, so it is unrelated to the MIDI interface. Because of that, I can explain some of what you see there.
Sometimes with this sample you can release it and the sound continues to play but shifted and garbled somehow.
This is how it looks in the WAV file.
The sample plays regularly until release, then it goes silent for a few samples and then starts up again in a garbled way. This particular WAV file was created with MIDI playback precision, so it is not a matter of bouncing a finger on the keys etc.
When the next note plays, this garbled mess becomes one of 3 things:
#1: Fixed.
#2: Quieter, as if the garble is cancelling out some of the samples from the note being held.
#3: Louder, as if the garble is adding to some of the samples of the note being held.
If my descriptions for how I created the performance and the MIDI are not enough, I can send the actual files. But all you need to do is load this sample, disable effects (reverb etc.) and tap the keyboard. I believe it had this issue with and without filters and with and without effects, but for reproduction purposes that is how I made the sound file. Otherwise the parameters are default and the note only plays at maximum velocity.
Firmware is 2.00.3.
I am not able to modify that at this time.
L. Spiro
Posted : 28/05/2019 4:38 am
Hello Shawn,
why do You not update Your system to Version 2,50?
It will be a good way to see if it is happen again.
Whenn yes, now You will be in the position to say it is a bug.
I think Yamaha go not backward in there Firmware. And at this time 2,50 is the actual version.
I hope the newer Firmware will give the solution.
Rainer
Posted : 28/05/2019 4:58 pm
Topic starter
As mentioned I can’t update just at the moment. For now this is a notification that definitely something is wrong in 2.00.3, and it is probably also wrong in the current version and it is easy to test (use the sample I provided).
It’s easy to reproduce if they have any interest in investigating it, so there is definitely no reason for me to sit and wait several months before I get the latest firmware to post about this.
And it is pretty major. You would think they would want to know about it as soon as possible, even if the version is old.
L. Spiro
Posted : 28/05/2019 6:27 pm
During this time, the other owners of the Montage make... music 😉
Posted : 29/05/2019 4:04 am
Hi Shawn. Why would it take you several months to update the montage please?
Posted : 29/05/2019 4:28 am
Swan,
Excellent test!
Posted : 29/05/2019 3:11 pm
Topic starter
Phil, my current project is exhaustive in the raw number of songs involved (over 3,000 done, more than 6,000 to go) and requires numerous of them to stay in an editable state on the synthesizer itself.
They have to be finalized in groups of around 30-100, meaning that if I decide to change a parameter on 1 of them I have to change it on all of them in that group and re-record.
Backups convert writable performances into read-only performances. I can’t possibly allow that right in the middle of this huge project, as it would require me to reconstruct all of the songs back into an editable copy, parameter-by-parameter, for every track on every one of hundreds and thousands of songs…
This is not happening. I will update when I am done.
L. Spiro
Posted : 30/05/2019 9:46 am
Hi L. Spiro, sounds like a really interesting project. Thousands of songs???
But please note, that a backup does _not_ convert anything to read-only. If you store the user data to disk and then load it into a library, then yes it is read-only. But if you do a full backup and reload that all the performances are stored to the same locations and user performances are writable!
Posted : 30/05/2019 6:25 pm
Topic starter
Hello Stefan.
I meant it would be read-only if anything went wrong and I had to format and re-apply the firmware (because this would require applying my backup at the end).
If they are asking me to make a backup, then necessarily there must be some risk. I am not willing to take even such a small risk with this kind of project.
In any case, it simply isn’t necessary for now. Since I actually am an engineer, let me just pretend that I work at Yamaha instead of at Apple.
So here I am, a senior Yamaha engineer, and I get a report that my synthesizer doesn’t synthesize correctly. The firmware is old, sure, but the evidence is compelling, the issue is serious, and the person who reported it provided a sample and a quick description of how to set up the test (create new performance with sample in element 0, pan element 0 hard left (likely optional), disable reverb and effects, set the release time to 0 (likely optional), and start tapping the keys with your finger).
So as a responsible Yamaha engineer, I try it out in the latest firmware (it takes seconds to set up because I already have current firmware on my machine(s)), and then I pursue exactly 1 (not 0, not 2, not X from a different set of options; these right here are the only 2 possible branches) of the options that follow: #1: I saw the bug happen. We are done. Now I begin investigating. Or; #2: I did not see the bug. I report that I tried it and did not see the issue on the latest firmware and this eventually gets fed back to the person who reported the bug so that said person can offer to send you more files or so that said person knows about this result and keeps it in mind to report again in the future should said person eventually get to update (we would invite said person to report back once said person updates and tests again).
All engineers want as much data as possible when a bug report is submitted, but at the highest level of engineering you eventually get 2 types of people: Those who are overly strict about what they accept before being sent to hunt down a bug and those who will start to hunt bugs when given reasonable first-step actions to take when bug data is lacking.
People who are overly strict got that way out of laziness. While it’s true that no one wants to chase a bug that “might have been fixed in the latest version,” what makes a responsible programmer is his or her willingness to spend only a few seconds to check if it does in fact exist on the latest version. Those who are unwilling to do this are that way because they have discovered that their overly strict stance sounds reasonable to most people and they are able to use it simply as an excuse to avoid doing the slightest bit of extra work.
I reported the bug with the information I was able to provide because I want to assume that Yamaha engineers are as responsible as I am.
Speaking from experience as a very prominent and high-status programmer, if I saw this bug cross my desk with only the information provided, given the huge potential impact of this very severe bug, there is absolutely no chance I would use the lack of accompanying information as an excuse not to look into it (beginning by checking the sample on the latest version).
I didn’t hire the Yamaha engineers who need to investigate this.
Are they as responsible engineers as myself? I guess we are waiting to see.
L. Spiro
Posted : 01/06/2019 2:41 am
Yes unfortunately I've seen a tone of pushback and ridicule for providing sound data of how to reproduce an issue along with sound data of the issue observance. Sometimes by Yamaha - many times by users (as in this thread - as if being able to articulate something you've noticed somehow means you're not using your instrument to create music).
Note that today we have multiple channels of feedback. Here - for more generic usability issues (primarily middle-of-the-road usage), customer service by phone/email, and ideascale which is run by the R&D department. They have published email contact information there - but an idea to fix a bug is as good as any. I'm not saying you should or should have posted to ideascale - just mentioning it's a channel for you to do what you want with.
Current Yamaha Synthesizers: Montage Classic 7, Motif XF6, S90XS, MO6, EX5R
Posted : 01/06/2019 4:03 pm
Hello Stefan.
I meant it would be read-only if anything went wrong and I had to format and re-apply the firmware (because this would require applying my backup at the end).
If they are asking me to make a backup, then necessarily there must be some risk. I am not willing to take even such a small risk with this kind of project. In any case, it simply isn’t necessary for now. Since I actually am an engineer, let me just pretend that I work at Yamaha instead of at Apple.
Fully understandable that you do not want to take such a risk at this point. I am probably in a similar position that you are so I understand which risks to take (or not to take) at what time. Since it is not important for you at this point to get that bug fixed, simply sticking with the old version is the right way. I am still not sure what you mean by "it would be read-only if anything went wrong". I just wanted to point out that in case it was important for you that you can do a full backup and reload later as read-writable.
So here I am, a senior Yamaha engineer, and I get a report that my synthesizer doesn’t synthesize correctly. The firmware is old, sure, but the evidence is compelling, the issue is serious, and the person who reported it provided a sample and a quick description of how to set up the test (create new performance with sample in element 0, pan element 0 hard left (likely optional), disable reverb and effects, set the release time to 0 (likely optional), and start tapping the keys with your finger).
So as a responsible Yamaha engineer, I try it out in the latest firmware (it takes seconds to set up because I already have current firmware on my machine(s)), and then I pursue exactly 1 (not 0, not 2, not X from a different set of options; these right here are the only 2 possible branches) of the options that follow: #1: I saw the bug happen. We are done. Now I begin investigating. Or; #2: I did not see the bug. I report that I tried it and did not see the issue on the latest firmware and this eventually gets fed back to the person who reported the bug so that said person can offer to send you more files or so that said person knows about this result and keeps it in mind to report again in the future should said person eventually get to update (we would invite said person to report back once said person updates and tests again).
All engineers want as much data as possible when a bug report is submitted, but at the highest level of engineering you eventually get 2 types of people: Those who are overly strict about what they accept before being sent to hunt down a bug and those who will start to hunt bugs when given reasonable first-step actions to take when bug data is lacking.People who are overly strict got that way out of laziness. While it’s true that no one wants to chase a bug that “might have been fixed in the latest version,” what makes a responsible programmer is his or her willingness to spend only a few seconds to check if it does in fact exist on the latest version. Those who are unwilling to do this are that way because they have discovered that their overly strict stance sounds reasonable to most people and they are able to use it simply as an excuse to avoid doing the slightest bit of extra work.
I reported the bug with the information I was able to provide because I want to assume that Yamaha engineers are as responsible as I am.
Speaking from experience as a very prominent and high-status programmer, if I saw this bug cross my desk with only the information provided, given the huge potential impact of this very severe bug, there is absolutely no chance I would use the lack of accompanying information as an excuse not to look into it (beginning by checking the sample on the latest version).I didn’t hire the Yamaha engineers who need to investigate this.
Are they as responsible engineers as myself? I guess we are waiting to see.L. Spiro
I am not at all sure that any engineer monitors this forum. At some point in the past I reported a clear bug in this forum with clear reproduction information. There was push back on that saying it was not a bug. But wonder oh wonder, it was actually fixed (and mentioned in the release notes) in the next update (some point after 2.0). But the Yamaha forum people said they did not report it to engineering... So there is some hope that someone from engineering monitors the forum. Still, considering that the last firmware update is a long time ago it could be that it may take a long time to get fixed.
Note that I tried to report the bug given the information above ("create new performance with sample in element 0, pan element 0 hard left (likely optional), disable reverb and effects, set the release time to 0 (likely optional), and start tapping the keys with your finger"). I recorded the trigger on MIDI and also additionally moved expression from 0 to 100% and back during the second. I let this play for a long time while writing the answer but I did not see any problem. So not sure if it is fixed with 2.5 (which I have installed) or if that information is not complete enough to be able to reproduce the problem, or if it related to your sample. If you could send me the sample and the MIDI file in some way, I would try it out...
NOTE: The tone.rar you attached is 191 bytes long, so it cannot contain a sample. In fact for me it is empty. Please check that. I used the default sample sound instead.
Posted : 01/06/2019 4:41 pm
Topic starter
It might be the sample, as it is basically a maximally “aggressive” sound I can use for testing and measuring.
If it did not upload, that definitely is a problem I need to address.
[Wow; I verified the sample by playing it in Windows Media Player and it crashed too, after playing it in a loop a few times.]
This sample really might be the key to all of this.
Tone.wav Here it is again.
I just verified that all you have to do is load the sample.
It screws up the MONTAGE all by itself. You can change the pan, release time, and reverb settings just to hear it more clearly, but basically literally all you have to do is create an init, load this into element 0, and start tapping a key over and over.
You will start to hear the sound become inconsistent etc.
This is when you will decide to make the changes above just to hear the issue more clearly, but it is not necessary.
NEW INSTRUCTIONS:
#1: Load sample into new performance.
#2: Hit the keys. (It happens more noticeably on middle C, where it plays the sample back at its normal rate.)
#3: Hear bug.
L. Spiro
Posted : 02/06/2019 8:40 pm
