[Feature Request]Is it possible to relocate wave files?

gynamics commented 1 year ago

Hello, first of all, thank you for your work, it is MusE that give me the chance to release my passion for music on linux!

I moved some wave files that are referenced by tens of projects, to a new directory. But I found that I have no method to relocate them, currently I have to add a symbol link at the old path to maintain the file path ... I know I should place them in my project for integrity, by the way, can I relocate them? After all, they should be separated from an arrangement, right?

gynamics commented 1 year ago

did it by doing regex replacement on project file, but not a safe solution. I will leave this feature request open for a while.

terminator356 commented 1 year ago

Hm, this might be a question for @spamatica, as he tends to do some of these file related issues. Maybe he added some mechanism that might help that I'm not aware of?

I see that absolute file paths are stored in the song. But even if we stored relative paths that would not help either. We need some way to selectively apply a relocation to some or all of the paths, since some of the paths might want to remain the same (references to system sounds etc.)

When loading a song, hopefully we do not discard the file path if the file is not found, that would allow us to implement an in-app re-locator. Otherwise we should fix that because otherwise we would have to make something that can do it before the song is actually loaded and potentially saved again with missing paths.

terminator356 commented 1 year ago

Tested: Oops, upon song loading we discard the file path and even the complete wave event if the wave file is not found. When the song is saved the complete wave event is missing :-(

That should be fixed. I'm 'persistent guy' - I made synths and plugins keep their settings if the plugins are missing, so that once the plugins are installed the song works again. :-) So this behaviour was overlooked and should be corrected if possible, in line with 'persistent' goals.

I want to also mention that I have known for years that the Wave Editor is sorely missing some features that would help here (after any 'persistent' fixes):

1) The ability to create a blank Wave Event and load it at will later with an actual wave file.

2) The ability to change an existing Wave Event's wave file, ie. load a different wave.

3) The ability to remove the wave file from a Wave Event, making it a blank Wave Event again.

4) The ability to delete a Wave Event from the containing Wave Part. Hm, I thought I'd added this one, but I think it's in another branch I'm working on...

These relatively easy additions would allow manual one-by-one wave file relocations for each Wave Event. (Reminder to one who tackles this: Be sure to affect all clone events in clone parts.)

As for a 'bulk' re-locator window that shows all wave files in a table or something: I should mention that our sorely underdeveloped Clip List Editor just might be the place for that. It would need to be re-worked to allow selection and changing and so on. But, the way I understood the intention, it was to become a true midi and audio 'clip' list where the clips could be dragged into the song. I had already started to do this in another older lagging (!) branch. But, I recall realizing that it would be desirable to show clips that are actually used in the song. So if that is the case then yeah, it might be a good window to start with this idea.

Whew... All for now. T.

spamatica commented 1 year ago

Tested: Oops, upon song loading we discard the file path and even the complete wave event if the wave file is not found. When the song is saved the complete wave event is missing :-(

Don't you get a question about locating the missing file first?

I know you are 'cover all bases' kinda guy Tim :) Personally I don't think it is out of order to lose information if you persist in editing even though the project was not complete.

Regarding changing the filenames using regex on the song file, sure it can be risky but it is a very powerful solution. I would have omitted the risk by simply storing the edited song file to a new file.

spamatica commented 1 year ago

Another take on this is that I really don't recommend sharing wave files between projects.

To my shock I see that we still do not tick the 'create project subfolder' by default! :-o We really should make this default as it makes it pretty much a non issue.

terminator356 commented 1 year ago

Don't you get a question about locating the missing file first?

No. Silent.

To my shock I see that we still do not tick the 'create project subfolder' by default! :-o

No complaints here if you change it. Although I do sometimes leave it off when working with multiple saves of songs in the same folder, by far the most times I do have to click it on.

terminator356 commented 1 year ago

Although I do sometimes leave it off when working with multiple saves of songs in the same folder, by far the most times I do have to click it on.

Hm, how about on by default, but if 'Save as' is clicked we turn it off, assuming the user would like to save the new copy of the song in the same folder.

gynamics commented 1 year ago

@terminator356 has specified things about wave edition, nice plan. And here some thoughts about path management to be complemented.

It is a disturbing problem to make a choice between relative path and absolute path. I suggest that we might choose both as well, and always use absolute path first when we try to use them. as following specifies:

if absolute path is valid, then use absolute path
if absolute path is missing, try to find it by relative path
if both absolute path and relative path are missing, report something and let the user handle this.

Besides, I hope there will be a unified path management method. Currently, it is lucky for me that absolute paths to wave files are stored in project file so that I got the chance to modify them manually, but at the same time I saw that synthesizer configurations are stored as binary data strings, and these configurations may include paths to samples, preset files, or plugin arrangements. That means, even if the wave files could be relocated, these configurations will still lost, but those configuration data are no less important than imported waveforms. I think there will be such a requirement for further project maintenance.

terminator356 commented 1 year ago

Good point about the plugin data. I neglected to consider that. It was a necessary evil to make them binary strings because as plain text the song files ended up being really really huge.

But even if they were plain text, it would still be a hassle for user to manually wade through it all and change paths. So there would have to be some way of telling plugins that their file paths had changed. I suspect that would be very difficult since each plugin handles such things differently. Likely the user would have to manually open each plugin and reload the desired files.

gynamics commented 1 year ago

Yes, it will surely be a hard work, but it is always there. Even if we do not consider details about path management, it has been a messy work to pass configuration data to hundreds of plugins to shape them back to the saved state. These plugins have various configuration management methods, we need some knowledge about these methods, even if we just want to pass a data piece to them. It seems that there is still a long way to go.

As for the storage form, it is reasonable to use binary format for saving spaces, if we had not done data compression, but, will gzip do it "obviously better" if we use binary format for data storage? I may hold this doubt.

terminator356 commented 1 year ago

Another good point about gzip. You may notice we have the option to save and load gzipped song files. Perhaps it was a bad idea to compress the plugin data in the plain text song files, and instead maybe we should have left it uncompressed so that the overall gzipped song file saving and loading could do its job. It would be up to the user whether to save their songs in the gzipped format or not. At least it would provide a way for them to view the plugin settings in plain text, by uncompressing the song file. As it stands there is currently NO way to actually view that data in plain text.

drautzburg commented 1 year ago

Would it help, if you steal some ideas from the way unix loads executeables and shared libraries, i.e.

Make wave filenames a bit more unique than "...TAKE_1", so name clashes are rare. Add a timestamp, a GUID or something like that.
Use a PATH to locate these files, where "." (the directory of the project file) is always included.

muse-sequencer / muse

[Feature Request]Is it possible to relocate wave files? #1097