Lmms: Improved savefile layout for external resources

[JohannesLorenz]

Currently, LMMS saves "most" plugins into the mmp files, but not all. E.g. zynaddsubfx or 3osc are saved, but audiofileprocessor only saves a file name.

On one hand, this behaviour is practical, because savefiles stay small. On the other hand, this makes some projects unsharable, especially professional projects where audio file processor is used. With Lv2, there may be more plugins that save binary files and users may get fed up with not being able to load projects from LSP because they miss those binary files.

I'd suggest something like "Save" and "Save as Release", to save either for personal use and for distributed use.

If a project is saved for distributed use, there are at least two options:

1. :rocket: Save binary files as (large) CDATA in the XML: \x00\x01...
2. :eyes: Extend savefiles to folders. Binary files are still just referenced by name, and a file with the name is put into the folder
3. :heart: Something else?

1 has the advantage that still everything is just one file, but the files may get very large and you may need to scroll down a lot to scroll past a serialized wave file.
2 has the advantage that project files stay small, and thus easy to read. However, as the whole save-file is now a save-folder, you may need to zip it (like mmpz) to have it in one file. Zipped files are more hard to handle, e.g. in version control or in comparing them with others. Also, this is more implementation overhead.

What are your preferences? Also, what about a "Save as Release" menu item?

[ghost]

I've voted to have a folder layout because it's more flexible than the other options.

We can still have it in a single file when we use compression or use a "pak" file like in the game industrie, where we compress the entire folders to a single archive.

[musikBear]

yes, all bundled into one zipped file ready for export, but what on the other side?
How should the recipient of the zipped bundle handle that?
Should the recipient manually open and sort the content into the correct folders on his side, or should LMMS be able to 'unpack' to correct locations?

[T0NIT0RMX]

I voted option 2 "extend savefiles to folders"
Seems the best way to share sample with a mmpz file
Will the "Save" option still remain a regular save like we already have ? I ask this because I save A LOT of versions (like 200+ / songs) so I would really love to still have the possibility to have _light_ savefiles
And "save as release" seems maybe confusing, when I first read I thought "oh it's a new export option" so I would suggest something more like "save project with ressources" may be too long but you get the idea, something were _ressources_ appears, but then resource can make the user think it will save the VST too so..
Maybe a popup then to list what is saved and what is not saved ?

[kriskropd]

This seems like a special purpose export and would likely be way too bloated and slow for common use locally (autosaving something like this would be icky, I imagine). Maybe calling it an extended-mmpz binary to discern apart from normal mmpz files; one designed for sharing or archiving.

Ideally, it might include a familiar mmpz binary alongside a collection of the necessary samples inside a subfolder - all of which could be wrapped inside a common zipped archive file renamed to something specific for LMMS to recognize (similar to .CBZ or .CBR files). This would keep everything neat and tidy while still being accessible for parsing and manipulation (like copying all the samples to reuse in another project).

Being one to rely heavily on VSTs with licensing services and frameworks of their own, I imagine none of the VSTs would carry over with this idea and would disrupt expectations for any users who didn't know better. Additionally, we saw plugins and filters change interpretation of stored parameters sometime around v0.9 or v1.0, I believe - and issues like that might be preserved and even exaggerated with this proposed save system.

This could also cause a lot of issues in regard to sample licensing...

[Spekular]

Word files are zips, and IME Word's saving isn't noticeably "bloated and
slow". Also, mmpz is already compressed.

I think zipped-folder saving can happen independently of packing samples.
In that case there should be at small changes in speed or size at most, in
exchange for a potentially more flexible format.

>

[JohannesLorenz]

Should the recipient manually open and sort the content into the correct folders on his side, or should LMMS be able to 'unpack' to correct locations?

@musikBear The latter. If LMMS can save to folders, it must also be able to load from folders.

Will the "Save" option still remain a regular save like we already have ?

@T0NIT0RMX My plan was to do this just for savefiles with binary files (that are not delivered with LMMS itself). So it depends, if you have many projects with e.g. singing or recorded instruments, then yes.

Being one to rely heavily on VSTs

@kriskropd My concern was mostly about sharing LMMS projects. For the LMMS sharing platform (LSP), I think it's good practice to not use VSTs excessively (or even not at all), because many users won't have the VST plugins you have, they may not even have wine.

Btw I prefer being able to not pack the folders into zips, i.e. having both options, like with MMP and MMPZ. Imagine you want to put your songs under git version control...

[musikBear]

One more consideration on recipient side:
Should LMMS have an option to use all files in a zip-bundle directly, as in not unpack and move resources to correct location in the recipients installation, but simply use the files directly in the zip-archive, if that project-file is double-clicked loaded?
The benefit would be, that the various resources are not installed on the recipients HD, so no naming conflicts could occur

[JohannesLorenz]

Should LMMS have _an option_ to use all files in a zip-bundle _directly_, as in _not_ unpack

@musikBear Not only option. This is the only behaviour I'd implement for now. Unpacking can be implemented afterwards if anyone really needs that.

[musikBear]

@JohannesLorenz -You mean you implement the use the files directly in the zip-archive method? That is good start indeed! +:1:

[tresf]

There are two conversations happening here...

• What to do with presets that can't find their samples/plugins (wav, sf2, etc)
• How to make a portable project file

I strongly feel this is best tackled as a portable project file issue, which is described in part here #1257.

Bastardizing the presets support is going to get weird. Some soundfonts are huge. I can't see it going well unless it's a fully portable project, period.

[tresf]

This was my proposal back in the day, if anyone's interested: https://github.com/LMMS/lmms/issues/3981