After power outage, can't load project

[Watchful]

If you can clearly identify Melodyne in the XML, something like <PLUGIN type-"vst" uniqueId.... etc. ... name=Melodyne...>, delete the whole "paragraph" of information in between <PLUGIN> and </PLUGIN>. This will remove Melodyne from that track. Save your work and try to open it again.

You'll have to recreate your work, but I suspect you're right that it's the stretching piece that isn't working right. I have used Melodyne for years without any problems, but never for time stretching.

[jabe]

Good to hear that the track at fault has been isolated. It does appear, as you suggested, that the fault is not with the plug-in but something else. I'll have another look tomorrow and see if I can answer your other questions and concerns then. If you see this before I get back on again, could you post the entire text for the difficult track, and then I'll have a look and see if anything looks odd, and perhaps work out how we might comment out other bits of the track to identify the issue.

[TolmwN]

If you can clearly identify Melodyne in the XML, something like <PLUGIN type-"vst" uniqueId.... etc. ... name=Melodyne...>, delete the whole "paragraph" of information in between <PLUGIN> and </PLUGIN>. This will remove Melodyne from that track. Save your work and try to open it again.

You'll have to recreate your work, but I suspect you're right that it's the stretching piece that isn't working right. I have used Melodyne for years without any problems, but never for time stretching.

Hello Watchful! I tried doing as you instructed and removed Melodyne's paragraph from the track, but the edit crashed again upon launch, so it looks like the plugin is not the problem here indeed.
But as I said, luckily, in this specific case it's really not trouble for me to just remove the entire track, since that has already taken care of the crashing and the work I had put on that one track was not of much importance to the project.
In any case I'm still willing to find out what the actual problem is for the sake of knowledge and for others to benefit.
I wonder if by somehow disabling Melodyne's stretching that would solve it.

[Watchful]

Good luck! You're in great hands with Jabe.

[TolmwN]

Good to hear that the track at fault has been isolated. It does appear, as you suggested, that the fault is not with the plug-in but something else. I'll have another look tomorrow and see if I can answer your other questions and concerns then. If you see this before I get back on again, could you post the entire text for the difficult track, and then I'll have a look and see if anything looks odd, and perhaps work out how we might comment out other bits of the track to identify the issue.

Alright jabe, I'm sending you the track's text in PM.

[jabe]

Jabe, not to confuse TolmwN, but assuming this fixes the problem, we could recommend commenting out the <PLUGIN> </PLUGIN> reference to Melodyne. That way, we don't lose the work in the track itself--it just disables the Melodyne plugin.

Again, I'd recommend this as a second step as it's a little more work, as your suggestion is an easier, broader fix.

Indeed. It's a process and the initial part was to identify the track with the problem.

[jabe]

If you can clearly identify Melodyne in the XML, something like <PLUGIN type-"vst" uniqueId.... etc. ... name=Melodyne...>, delete the whole "paragraph" of information in between <PLUGIN> and </PLUGIN>. This will remove Melodyne from that track. Save your work and try to open it again.

You'll have to recreate your work, but I suspect you're right that it's the stretching piece that isn't working right. I have used Melodyne for years without any problems, but never for time stretching.

If we just comment out the <PLUGIN> stuff, rather than deleting it, it's easier to go back to it if it turns out that it's not the cause of the issue.

[Watchful]

No, sorry, I meant when you know that instance of the plugin was the culprit...I've had to do that when a reverb plugin I used years ago went bad and I needed to recover the projects I used it in. There was no point for me to keep a bad plugin in the project if all it did was crash upon loading.

[jabe]

Good to hear that the track at fault has been isolated. It does appear, as you suggested, that the fault is not with the plug-in but something else. I'll have another look tomorrow and see if I can answer your other questions and concerns then. If you see this before I get back on again, could you post the entire text for the difficult track, and then I'll have a look and see if anything looks odd, and perhaps work out how we might comment out other bits of the track to identify the issue.

Alright jabe, I'm sending you the track's text in PM.

Thanks for the file. I've had a look (I'll look more tomorrow) and haven't spotted anything suspicious.

I normally expect just one point of failure when investigating tech problems. That's not a certainty, but it might as well be considered to be.

I think that the way to go from here is to try commenting out plug-ins and audio clips on the track.

You only have four plug-ins, so it won't take much time to find out if a plug-in is at fault. I suggest you comment out two of them and try to load the file. If it loads, one of the other two plug-ins is at fault. If it fails, comment out the other two instead. I suspect the load will fail in both cases, but if not, it'll be easy for you to work out which plug-in is causing the problem.

It can get a bit tedious doing this one plug-in or audioclip at a time. There are techniques to cut down the number of edits and attempted loads. One way to do this is to comment out half the audioclips and try the load. If the load fails, one of the others is at fault, so comment out half of the ones not commented out first half(it should be safe to uncomment the first lot. Repeat this until you only have one possible guilty audioclip (and comment that out on its own, just to make sure).

I counted that you have 22 audioclips. First trial gets rid of 11 possibles. Second eminiates another 5 or 6. Third gets rid of another 2 or 3. Fourth or fifth try narrows it down to just one.

If it loads with just the one audioclip commented out, perhaps you could add a new track within Waveform, and then edit the dodgy audioclip into that track, perhaps with edited tweaks to the parameters, if you can work out what they are...

I await your results! Will also have another look at your file later.

[TolmwN]

Thanks for the file. I've had a look (I'll look more tomorrow) and haven't spotted anything suspicious.

I normally expect just one point of failure when investigating tech problems. That's not a certainty, but it might as well be considered to be.

I think that the way to go from here is to try commenting out plug-ins and audio clips on the track.

You only have four plug-ins, so it won't take much time to find out if a plug-in is at fault. I suggest you comment out two of them and try to load the file. If it loads, one of the other two plug-ins is at fault. If it fails, comment out the other two instead. I suspect the load will fail in both cases, but if not, it'll be easy for you to work out which plug-in is causing the problem.

It can get a bit tedious doing this one plug-in or audioclip at a time. There are techniques to cut down the number of edits and attempted loads. One way to do this is to comment out half the audioclips and try the load. If the load fails, one of the others is at fault, so comment out half of the ones not commented out first half(it should be safe to uncomment the first lot. Repeat this until you only have one possible guilty audioclip (and comment that out on its own, just to make sure).

I counted that you have 22 audioclips. First trial gets rid of 11 possibles. Second eminiates another 5 or 6. Third gets rid of another 2 or 3. Fourth or fifth try narrows it down to just one.

If it loads with just the one audioclip commented out, perhaps you could add a new track within Waveform, and then edit the dodgy audioclip into that track, perhaps with edited tweaks to the parameters, if you can work out what they are...

I await your results! Will also have another look at your file later.

So, after eliminating and testing different groups of audioclips each time, I narrowed the problem down to a few of them which, from what I recall, were the ones modified by both the Melodyne plugin AND the Melodyne time-stretching tool.

Now, since these audioclips were the only affected by the time-stretching tool, but were at the same time affected by the plugin too, I can't tell if it's the time-stretching alone that caused the problem or the combination of the two (though when I commented out the plugin and left the time-stretching in, the project still crashed, so I doubt it's the combination that caused it), but what I CAN tell is that the plugin alone did not cause it.
And that's because the rest of the audioclips, which I don't need to eliminate in order for the project to work, all include the plugin's modifications.

After all I think we managed to get to the bottom of it.

[jabe]

Good stuff and well done for following it through to the end.

It seems at least that there's not a large amount of work lost, which is a good place to get to, even if it has taken up a chunk of time. On the plus side, let's hope this thread helps someone else in the future. I did wonder whether by replacing the code that specifies using Melodyne for the time-stretching, you could try specify another time-stretching option. You might need to make another project and add clips to it, using a variety of time-stretching options, and then look in that project's files to see how the time-stretching is coded.

[TolmwN]

Good stuff and well done for following it through to the end.

It seems at least that there's not a large amount of work lost, which is a good place to get to, even if it has taken up a chunk of time. On the plus side, let's hope this thread helps someone else in the future. I did wonder whether by replacing the code that specifies using Melodyne for the time-stretching, you could try specify another time-stretching option. You might need to make another project and add clips to it, using a variety of time-stretching options, and then look in that project's files to see how the time-stretching is coded.

Here's the news, I did what you suggested in this last reply and I guess I detected Melodyne's time-stretching option's code in the XML. It was called elastiqueMode="5".

I replaced "5" with "6", because a different time-stretching option that I detected was called elastiqueMode="6", and when I opened the project it opened normally, no crashes.
The audioclips which were using Melodyne's time-stretching were now using the other time-stretching option, but unfortunately their content is missing completely, so they are basically empty.

I did the same thing in an entirely different, fresh project which I created on the spot, replacing the Melodyne time-stretching option with a different one, opened it, and the option had changed but the content was not missing, unlike in the project which had the crashing problem.

So I assume that this erasure of the audioclips' contents in the case of the project which had the crashing problem is in fact part of that problem in general.
Now, I'm not sure if the problem itself has to do with some kind of mistake I did (like moving a file at some point and not remembering it, or anything similar) and then the rest of the issues followed, or it was just a bug of the program, or a malfunction that was caused by some combination of tools within the project, but it is what it is.

In my case I was lucky that the content which was lost was kind of unimportant to my project, and the rest which was important was all saved, so thank you again for your help there.
When we first commented out the entire faulty track, I was already able to continue where I left off when the problem occurred.
In someone else's case it could be trickier but I hope they find this info useful.

[jabe]

Here's the news, I did what you suggested in this last reply and I guess I detected Melodyne's time-stretching option's code in the XML. It was called elastiqueMode="5".

I replaced "5" with "6", because a different time-stretching option that I detected was called elastiqueMode="6", and when I opened the project it opened normally, no crashes.
The audioclips which were using Melodyne's time-stretching were now using the other time-stretching option, but unfortunately their content is missing completely, so they are basically empty.

I did the same thing in an entirely different, fresh project which I created on the spot, replacing the Melodyne time-stretching option with a different one, opened it, and the option had changed but the content was not missing, unlike in the project which had the crashing problem.

...

Interesting. I think we took it about as far as we could. If the content has somehow disappeared from the project folder, it's not a mystery we'd be able to solve.

Let's hope nobody gets the same problem on something really important but if they do hopefully what we've noted here can help them. Thanks for your trust and reporting.