Tres: I will try to make a 64bit build tomorrow if will have a time
To all: Thanks for all suggestions.
I think it is a good thing that user is free to store and open each VST plugin from whatever location he wants to.
And for this I think symlinks, shortcuts or whatever each OS provides could be used, so how about combining this in
a way, that symlink name would contain for example actual plugin size and its name?
Links would be updated when plugin folder would be manually re-scanned or new plugin opened.
And I think it should not be problem also to drop dependency on each VST plugin, if participial version would not be found or parameter or knob count woud differ so I think it should not be a problem too leave this parametric settings in mmp mmpz etc as it is now.
On Wed, Feb 13, 2013 at 10:22 PM, Tres Finocchiaro <firstname.lastname@example.org>
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.
On Tue, Feb 12, 2013 at 6:17 PM, Mike Choi <email@example.com>
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 regards
On Tue, Feb 12, 2013 at 9:38 PM, Mike Choi <firstname.lastname@example.org>
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.
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?
On Fri, Feb 8, 2013 at 7:07 PM, Tres Finocchiaro <email@example.com>
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.
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