Hi Tres, thanks for testing. I didn't tested this relative path patch on Windows platform yet.
Mike,Thank you!The directory structure for LMMS is supposed to use the LMMS Working Directory for it's samples, plugins and presets.For example, if the project is saved in C:\Users\Administrator\Desktop\project.mmpzand the LMMS Working Directory is:C:\lmms\And a VST is stored in:C:\lmms\plugins\vst\plugin.dllThen the mmpz should reflect "src=plugins\vst\plugin.dll" (or something along those lines). The version you sent shows "src=C:\lmms\plugins\vst\plugin.dll".The correct behavior can be observed with OGG and WAV samples (they show the path relative to the working directory).
I was unable to reproduce this behavior with VSTs in the latest version you sent.-Tres--On Sat, Feb 16, 2013 at 1:51 AM, Mike Choi <email@example.com> wrote:
Hi,In forther version of that patch all VST paths in project save files should be relative, I made now Win64 build, but only just for this VST plugin directory.Best regards,Mike C.On Sat, Feb 16, 2013 at 6:49 AM, Mike Choi <firstname.lastname@example.org> wrote:
Hi,Yes thats right, I think Qt has a quite good tools for dealing symlinks and equvalents on different platforms, anyway I am considering rather a solution using xml files, something like load preference, where you could tick which plugin will be preffered to load if specified version from project file is not found. I'd like to use plugin size and also its name to identify specific versions so I think there is no need to rename those plugins.I will see how it goes, maybe If there'll be only one VST of specific name it could be preffered to load for instance, maybe if user select this as an option.
Thanks, Best regardsMike C.On Fri, Feb 15, 2013 at 4:42 AM, Tres Finocchiaro <email@example.com> wrote:
I'm confused a bit.Since the 32-bit VSTs are working now in 64-bit Windows, so this will cover 90% of use-case scenarios, where a project is shared across different platforms.
If a 64-bit VST is used, I would recommend anyone name the plugin (i.e. plugin.dll) plugin_x64.dll, since it would be incompatible with Mac, Linux and 32bit windows.There is no scenario I can see where SymLinks would be needed, since SymLinks would only benefit Windows 64-bit users and they are frowned upon in the NTFS file system anyways.I was simply hoping the path to the DLL would be relative and not a full path in the mmp file. The same logic that properly handles samples of type OGGs, WAVs, SF2s that are placed in the samples folder.-Tres--On Thu, Feb 14, 2013 at 10:05 AM, Mike Choi <firstname.lastname@example.org> wrote:
Hi Tres,Sorry I just could make it today to create that 64bit build for tests due maintenance on my virtualization server, anyway I think this test will not be so important if there will be completely new way of handling those links, but maybe I can make it this friday.Best regardsMike C.On Wed, Feb 13, 2013 at 10:22 PM, Tres Finocchiaro <email@example.com> wrote:
Thanks kindly again Mike.If you happen to create a Win64 build, I'd be happy to test it.I'm not sure what you mean by version conflicts, but I would be happy to discuss.Here is my use-case scenario:I'm currently working with a team of multiple musicians through Google Drive on Windows 32, 64 and Ubuntu.With 0.4.14-rc1 we are able to use the "samples" folder for SF2 and we're all able to use soundfonts across different architectures and platforms. This is a beautiful thing.As we are exploring reproducing certain sounds with VSTs instead (due to natural instrument limitations), we came across this.In our case, Google Drive synchronizes it's entire directory structure to C:\Users\username\Google Drive\lmms\, just like RSYNC. We can open LMMS and instantly have all of the samples and soundfonts contributed by the group.-Tres--On Tue, Feb 12, 2013 at 6:17 PM, Mike Choi <firstname.lastname@example.org> wrote:
Hi,I think it would be good to agree on a general way how those relative paths should be handled (If this is not done already). I would say its not good idea e.g. to search for VST plugins in more common folders, to avoid version conflicts, but maybe someone has better idea?I pushed test commit which stores this path to plugin as relative if VSTi is opened from default VST plugin folder. I think it should remain compatible with old project saves or vice versa, at least for 0.4.13, I will check for older releases.You can get it from GIT: origin/stable-0.4-mc-working.Thanks, Best regardsMike C.On Tue, Feb 12, 2013 at 9:38 PM, Mike Choi <email@example.com> wrote:
Hi,I will try to look on this, BTW do you have problems with latest build from your previous post as well?I just cant check from windows platform, only wine until Wednesday.Best regards-Mike C.On Tue, Feb 12, 2013 at 3:36 PM, Tres Finocchiaro <firstname.lastname@example.org> wrote:
------------------------------------------------------------------------------Developers,I noticed VST DLLs, even when placed in the "samples" folder are stored with absolute (not relative) paths.I have a bug open in the tracker to fix this for the "plugins" folder, but this is the first I've seen this behavior with the "samples" folder.Could this be a 0.4.14 fix, or would it be better to address this as part of the entire relative paths code fix further down the road?-Tres--On Fri, Feb 8, 2013 at 7:07 PM, Tres Finocchiaro <email@example.com> wrote:
I'm using several VSTs from the same author (these ones).If I add more than one VST to the project (no notes selected), playback is unbearable. There's clicks, delays, and CPU spikes.If I remove all but 1 VST, playback is fine.I'd like to report this as a bug with 0.4.14-rc1 but I wanted to hear back from those that use VSTs more, especially those on Windows platforms.-Tres--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
Lmms-users mailing list