Open qubodup opened 5 years ago
In the future, LMMS will be able to handle relative paths for VSTs. Then all you would have to do is ensure that your VSTs are in the same location relative to your VST home folder as whoever you collaborate with.
There's also an open issue for the VSTs being "forgotten", so hopefully they won't do that either.
Do these two changes fix your problem? If so we can close this as a duplicate of those two combined.
LMMS will be able to handle relative paths for VSTs [1] There's also an open issue for the VSTs being "forgotten", so hopefully they won't do that either [2] Do these two changes fix your problem?
Can't find the tickets (there are a lot about relative paths it seems) so I can't tell. Concluding from the given description: [1] does not solve the issue of chaotic folders that completely ignore lmms' vst folder location [2] might solve it - if it allows to change the vst location to replace it, without forgetting any of the configuration - which is what blender/olive/shotcut do - see above.
Looking back at this ticket, I can see that it's better closed than alive (it's chaotic). If you can find them, please link back to the tickets you were referring to (github auto-mentions this ticket in the linked issues). Maybe the suggestions in this ticket will be useful there.
The issues in question are #4646 and #4850
I'm not sure what you mean by "chaotic folders that completely ignore lmms' vst folder location". If a user saves their VSTs in some random location that isn't specified somewhere in LMMS, they can't reasonably expect the project to be easily portable. With the above two issues solved they can either:
Save VSTs in their LMMS specified VST directory*, resulting in a project file with relative paths (fairly portable).
Save VSTs "chaotically", and deal with the fact that they'll have to relocate them if they move the project or VSTs.
*or any other LMMS directory, actually. Sample directory soundfont directory, etc.
On Sun, Sep 8, 2019, 16:01 qubodup notifications@github.com wrote:
LMMS will be able to handle relative paths for VSTs There's also an open issue for the VSTs being "forgotten", so hopefully they won't do that either Do these two changes fix your problem? Can't find the tickets (there are a lot about relative paths it seems) so I can't tell. Concluding from the given description: [1] does not solve the issue of chaotic folders that completely ignore lmms' vst folder location [2] might solve it - if it allows to change the vst location to replace it, without forgetting any of the configuration - which is what blender/olive/shotcut do - see above.
Looking back at this ticket, I can see that it's better closed than alive (it's chaotic). If you can find them, please link back to the tickets you were referring to (github auto-mentions this ticket in the linked issues). Maybe the suggestions in this ticket will be useful there.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/5177?email_source=notifications&email_token=ACEBLGREXYSY2HGD7YE3FMLQIUASZA5CNFSM4IUTLL42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FQSNA#issuecomment-529205556, or mute the thread https://github.com/notifications/unsubscribe-auth/ACEBLGVMAOR73FVL5A335OTQIUASZANCNFSM4IUTLL4Q .
I'm not sure what you mean
I mean for example C:/Users/[username]/Desktop/Plugin lmms/
containing all the VSTs on the computer where the song was made.
I suggest that lmms could allow any projects to be "fixed" [edit: fixed means that the user can adjust the missing file paths] in a new environment to allow collaboration notwithstanding unorganized folder discipline by composers. LMMS could list the missing files and give the user the option to manually select a correct location, as seen above (olive, shotcut).
Optionally it could allow the user to select a folder and try to auto-match missing files by name, as mentioned above (blender).
VST2 plugins all come with a FourCC identifier. Ideally we would implement VST scanning (#1837), then we can save the identifier for each VST in the project file and just look it up in the scanned VST database when the project is loaded. This way there's no need for collaborating users to have the same folder layout or anything.
allow the user to select a folder and try to auto-match missing files by name, as mentioned above (blender).
That's the enhancement request and the title should be modified to reflect it. It's about giving the user the ability to fix the problem, and .dll
is just how it may appear on Windows. It would have the same benefits on Linux, MacOS.
Option to allow fetching of missing files.
.dll
, .dylib
, .so
, etc).wav
, .ogg
, .sf2
, etc)I would recommend that on the popup screen, we add some form of ... link or Fix button that opens a utility for helping with this.
It's hard (impossible?) to collaborate casually on lmms projects.
I'm trying to edit https://lmms.io/lsp/?action=show&file=15367
I downloaded the dlls listed in the error report (see https://github.com/LMMS/lmms/issues/5176 )
I placed the DLLs in one folder and told LMMS that it is the VST folder.
LMMS reports the same error.
I suppose if the project file was edit-able, I could modify XML paths to fix this. However the file is shared as mmpz https://lmms.io/forum/viewtopic.php?t=4727#p15089
Blender and Video editing software is no stranger to this kind of problem. Blender has a nice "find missing files" feature, which asks to find a folder and auto-searches recursively https://blender.stackexchange.com/questions/5368/why-are-all-the-textures-in-my-file-pink
Olive video editor for example marks missing media and allows to manually "replace" it
Shotcut video editor has a warning pop-up that allows to resolve in a similar manner:
The big problem with LMMS is that if I open an mmpz with missing files and save it, the saved mmp will forget about the missing files and assume all the VeSTige instruments are just supposed to be empty.
"users should use standardized VST folders" is an anti-beginner workaround I'm afraid.
(Considering samples the issue currently is probably unsolveable when moving between unix/windows?)
For the time being: perhaps there is a mmpz to mmp converter that doesn't change the content?