Search for samples in Project file's local directory

[unfa]

It's hard tot use samples when cooperating wth other users, when for some reason I don't want to mess up with the other person's "lmms/samples" directory contents.

I'd love to be albe to define sample paths that are local to the MMP/MMPZ file's dir.

For example my project paths is

/my/very/long/path/

But my partner has the same dir synced in:

/his/very/long/path/t

If we want to store the samples along with the project file (and we do) we need to make some tricky symlinks kung-fu to cheat LMMS that we both use the same path for our projects.

Blender for example defines a character sequence "//" or "" that meas the project file local dir.

This way One can ferenece a sample locally:

//sample1.flac

Instead of

/some/long/dir/sample1.flac

[tresf]

Related #441 #1257.

Internally to the project, we may be able to use something like project:/ to reference that a file is relative to a specific project, but the relative path calculation could very well collide with the existing LMMS_HOME concept, so I feel this may simply be better as an export feature as explained in #441, #1257.

[unfa]

Could it just work that when the paths starts with project:/ then LMMS omits LMMS_HOME path search - why this could be conflicting?

This project:/ prefix sounds like a solution to me :)

[tresf]

Could it just work that when the paths starts with project:/ then LMMS omits LMMS_HOME path search - why this could be conflicting? This project:/ prefix sounds like a solution to me :)

Although project:/ would hypothetically work for the loading of projects, it's the saving of them I think is where this gets hairy...

Take the given scenario, which assumes your lmms home directory is the default ~/lmms for illustrative purposes. I'll call this directory . for further simplification of this issue.

Project: projects/Proj1/Proj1.mmpz
Sample: samples/sample1.ogg

Since we relativize the paths on save, sample1.ogg is saved with the following path in our project file:

<audiofileprocessor src="sample1.ogg" [...] />

Had this been within the projects folder:

Project: projects/Proj1/Proj1.mmpz
Sample: projects/Proj1/samples/sample1.ogg

Now it is stored as absolute:

<audiofileprocessor src="/home/tres/lmms/projects/Proj1/samples/sample1.ogg" [...]/>

I suppose if we were to compare the path of the sample to the path of the project and if they both belong to the same tree, we could use a project:/ syntax. I guess that would work.

- <audiofileprocessor src="/home/tres/lmms/projects/Proj1/samples/sample1.ogg" [...]/>
//// 1. ON SAVE, CHECK TO MATCH PROJECT PARENT ABSOLUTE PATH, RENAME
//// 2. PROJECT ABSOLUTE:  /home/tres/lmms/projects/Proj1/Proj1.mmpz
//// 3. MATCH ON:          /home/tres/lmms/projects/Proj1/
+ - <audiofileprocessor src="project:/samples/sample1.ogg" [...]/>
//// NOTE:  Slightly confusing! "samples/" is generally assumed with AFP!!!!

Note, we'd also have to make the samples sidebar search in project:/samples/ or something sane, which could potentially make weird things happen when you have Proj1.mmpz and Proj2.mmpz in the same folder. If a project:/samples directory exists, it would list them, thus increasing the risk of paths breaking when you want to move each project into a respective sub-folder.

[Umcaruje]

@unfa you already made an issue about this some time ago: #2175. Couldn't this have been just a new comment on that issue?

[tresf]

@unfa you already made an issue about this some time ago: #2175. Couldn't this have been just a new comment on that issue?

Good catch. This one is more specific (well it is now, with the project layout research), closing the other. 👍

[SirBothersome]

I do wonder how this would affect backwards compatibility. If we change the filepath, wouldn't that mean every sample on a legacy project would be silent and have to be reassigned? Oh, and welcome back @unfa

[unfa]

Hi again, @SirBothersome

Yes the first issue is old, and I forgot about it. The problem carries on though.

Hmm. I tried making a sym link in lmms/samples/link leading to another dir with samples.
This was supposed to make sure that on both machines the samples can be found under lmms/samples/link/, even if the files are actually under different locations.
Somehow it doesn't work on the other machine.

I think that if we introduce a special string that has to start relative paths, all other can be tread as before - maintaining backwards compatibility.

For example project://sample.flac or ./sample.flac

[SirBothersome]

I feel like if we added a slush folder for random samples to be drag 'n dropped into this would sort of resolve the issue...

[tresf]

I feel like if we added a slush folder for random samples to be drag 'n dropped into this would sort of resolve the issue...

Did you read the proposal in #2982 (comment)? I'm not familiar with "slush folder" or "sort of resolve" are describing. Probably best to settle on a design that scales with the product and symlinks are generally a bad idea if one wants portability.

[SirBothersome]

By slush folder, I mean an empty directory within the native samples for the collab samples to be dragged and dropped into. This means that the samples in both of the projects would have the same file location, and wouldn't need to be manually assigned. By "sort of resolve" I mean, you'd still have to send the samples... and both users would have to go into the scary land of C;/Program Files/LMMS/data/samples/ I'd be perfectly comfortable with that, as I'm fairly familiar with the directory structure, but I feel like this could be a hassle for some. So it only sort of resolves the issue...

[tresf]

You're only confusing me more. If you need samples shared between projects, configure your LMMS WORKING DIRECTORY, which can then be shared and synced with your friends.

If you don't want to share out your entire folder, wait for some of these features to be implemented.

both users would have to go into the scary land of <install>/data/samples/

No.

[SirBothersome]

Fair enough. I shall hush my face on this issue.

[eagles051387]

What was suggested by @unfa would only work on Mac or Linux no?

Sent from my iPhone

On 22 Aug 2016, at 15:10, SirBothersome notifications@github.com wrote:

Fair enough. I shall hush my face on this issue.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[tresf]

What was suggested by @unfa would only work on Mac or Linux no?

Windows has symlinks (NTFS, so anything not FAT32), but they aren't really portable on any system; they generally aren't intuitive to end-users; we won't recommend them in user-space unless they have a very very good use-case, which I've yet to see.

2018-02-20 - Edit: NTFS symlinks also carry some other nuances, the primary one is that the operation often requires elevated permissions. From ss64.com:

Elevation
By default, only Administrators can create symbolic links. The security setting 'Create symbolic links' can be granted at: Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

Creating a symbolic link requires elevation, but from Windows 10 build 14972, symlinks can be created without needing to elevate the console as administrator - this does however require that you have Developer Mode enabled.

[lukas-w]

Consolidated into #4309.