BTW I was looking that in project files, there is usually absolute path stored for sf2 or samples, if they are opened from custom locations.
Hi,I uploaded 64bit Windows build for VeSTige relative patch tests, sorry I had a problem to compile it for windows yesterday, anyway after a small fix this should work.Best regardsMike C.On Tue, Feb 19, 2013 at 2:53 AM, Mike Choi <firstname.lastname@example.org> wrote:
Hello,I pushed new patch into GIT branch origin/stable-0.4-mc-working which should add ability from below to store VST plugin relative information (for Vestige) into lmms project files, except creating patches, knob parametr import from project files, last paragraph.There is also a new button in lmms Settings (see screenshot) to re-scan VST directory and to store all plugin information into xml config file, you can re-scan e.g. whole hard drive, but there is no checking whether file is actually VST plugin, actual check would require utilizing wine windows functions and would be much slower, only '.dlls' are taken into account now, no '.exe' or other.I will try make 64bit executable for test tomorrow.Best regardsMike C.On Mon, Feb 18, 2013 at 12:25 PM, Mike Choi <email@example.com> wrote:
Hi Tres, thanks for testing. I didn't tested this relative path patch on Windows platform yet.BTW I have now a basic version working which stores into project only name of VST plugin, e.g. 'plugin.dll' and its size, and rest is taken from XML config, which is being updated automatically as you open new plugins, also you can select here or mark some plugin version preferred, if there is some conflict or other version fails to load.I'd like to test it today on windows, also what is left to do is I'd like to add a re-scan button, which will recursively scan folders for VST plugins and store all information from here into that XML config (which is now stored in lmms default work dir).I also plan to add ability to make presets out this project file or to reload all knob settings from that file, but possibly as some future patch.Best regardsMike C.On Mon, Feb 18, 2013 at 1:57 AM, Tres Finocchiaro <firstname.lastname@example.org> wrote: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