Skip to main content

How to restore a broken project? = How to move data between projects?

Posted

I have been working on a somewhat larger Synfire project over some time now, but seemingly that project is broken now. I report below a number of quirks that came up in this project, but which do not exist for me in newly started Synfire projects.

So, in the hope to rescue my piece I am considering to just restore the data of my project (all phrases, harmonies etc), but move it all into either a fresh clean project or perhaps several shorter Synfire sub-projects.

We had discussions in the past on how to deal with projects arranged in multiple sub-projects (e.g., on container import, also related is multiple structures in an arrangement). I take from this discussion that the best way currently to move data between projects is likely to first copy the data into some library and then from their to a new project. For example, doing so preserves the link to the underlying harmony and the rack instruments.

However, I noted that articulations are lost this way. Articulations are preserved when draging (flat) containers into the embedded library. However, when this library is then exported to make it accessible elsewhere, the articulations are seemingly lost. Perhaps not such a big deal -- I will manually restore that (like the whole container hierarchy).

Any better workflow I may have missed?

 

For completeness and the record, here are some issues my larger project now has.

 - MusicXML export is broken for this file (MuseScore reports an error). MusicXML export still worked just the day before yesterday (I could confirm that older backups still work). Synfire still confirms that all events in the project are quantised, and I did not change any export settings. Switching any containers I edited afterwards to inactive does not help.

Side note: Synfire saves backups frequently (seemingly every few seconds are possible), and the limited number of stored backups means that the time span covered by Synfires automatic backups is pretty short. So, we better preserve older backups otherwise.

 - The output parameter of later figures in this larger project is empty, as reported yesterday (works for earlier containers, though)

 - The Open Plugin Editor button of the instrument properties in the structure tab does not do anything anymore (similar buttons elsewhere still work though, and this button also still works in other projects)

 - Overall the project gets somewhat sluggish. For example, switching between containers can take several seconds.

 - Synfire lost the mapping of some track to its preset and reports this whenever I start the project.

 - Likely my fault: the arrangement rack is unnecesssarily messy. It contains some instruments that are not even used by the project, and several copies of others (e.g., for using the same instrument with different pan positions I introduced multiple instances of it)

 


Sat, 2022-12-31 - 16:48 Permalink

You can send me the file (support at cognitone com) and I will look inside its data and repair it.

That will also be a an opportunity to identify issues that went undetected.

Sat, 2022-12-31 - 16:56 Permalink

Articulations are considered not portable and are thus removed from phrases collected in a library.

That policy probably needs a review. At least with the embedded library, everything but the mixing parameters (volume, pan, pause) should be kept. Otherwise it can't reliably serve as a clipboard. Thanks for bringing this up.

Background: Much of the intuitive copy/paste and drag/drop commands have some complex considerations going on behind the scenes. Like which parameters to replace, to keep or combine in which ways. Depending on what the data source is and the target (and the target position), different rules apply to make things as intutitive as possible.

Sat, 2022-12-31 - 17:00 Permalink

Thank you very much for offering to look into these issues. This is highly appreciated!

I just sent you the problematic project file.

Sun, 2023-01-01 - 22:07 Permalink

Update: I noted that the data shown by the output parameter is at times outdated. I can edit the respective figure such that different tones are played, but the output parameter is not always updated then. Sometimes it might be updated after several further edit operations. (And calling Container > Render does not update this data.)

Sun, 2023-01-01 - 22:12 Permalink

Update: actually, the problem is a worse. Playing a figure individually (via the audio feedback) and playing the corresponding section with normal playback can result in different pitches. Ouch! The output parameter shows the pitches played by the normal playback. So, the problem might not be the output parameter here, but something else.

I should perhaps add that I did not notice such behaviour before. A restart of the software does not change this behaviour for the figure where it occured.

Sun, 2023-01-01 - 22:38 Permalink

A simple workaround is to just keep editing the figure in question or surrounding figures, until the output parameter is updated again and both representations are back in sync.

Mon, 2023-01-02 - 14:20 Permalink

Yes, the output parameter cache is not flushed at some point where it should. Not sure yet where that point is.

It is rare that instant feedback during editing sounds different than during playback. But it happens. With every tiny edit step, the entire track needs to be rendered from start to end and only the notes created by the selected segment are sent to the instrument. For yet unknown reasons, this tracking sometimes messes up.

Thu, 2023-01-19 - 20:07 Permalink

After the latest update, my main problems are fixed now. I can open the exported MusicXML files again (MuseScore reports a problem, but the file is opened) and also the output parameter of later contains is drawn again. Thanks a lot for that!