LMMS • Forums

Gps wrote: ↑

May 16th, 2021, 3:46 pm

On windows 10 I have to take the .bak part away.

? --woot, my LMMS 1.2.2 open .bak file from double clicking in win-explorer
I rarely use it, but i can.
Have you added association to .bak, for LMMS?

I wonder if your not default filesystem is causing this.

Exactly........

musikbear wrote: ↑

May 16th, 2021, 4:30 pm

Gps wrote: ↑

May 16th, 2021, 3:46 pm

On windows 10 I have to take the .bak part away.

? --woot, my LMMS 1.2.2 open .bak file from double clicking in win-explorer
I rarely use it, but i can.
Have you added association to .bak, for LMMS?

I have not tried LMMS on windows for quite some time now, good to hear this has changed.

Think is was on windows 7.

The answer to the question about a "not default filesystem" affecting the running of any application is, it depends. Some programs are built with a certain path for, example, their shared libraries, cache directories (if any), config files, etc. Tcl/Tk is one example. It expects its system files to be in a specific place (e.g., shared libs). But I have a some external libs, including my own, under ~/tcl/lib and ~/tcl for others (in case someone here doesn't know, ~ is your $HOME directory, which, on this laptop, is c:/jim ... I'm going to start using that for most of the rest of this post). For those Tcl and Tk libs in ~/tcl and ~/tcl/lib/ all I need to do in any Tcl script is include one line telling Tcl and Tk where to look for packages I'm requiring.

LMMS certainly expects its own compiled binary stuff to be in the places where they were put during installation (when it gives you the option of where to install it).. The other files, VST, MIDI, etc., are located where you configure them to BE located in Settings-->Directories (click on Edit--->Settings and then choose that file folder icon). THAT is where LMMS will look for VST, MIDI, etc., files. You can use that to configure LMMS to look for VST files on a server on Mars if you have a link to a file server on Mars (granted, you'd have some terrible delays). In other words, LMMS looks where you TELL it to look. If you aren't familiar with how to use different paths to VST, etc., it's all in the documentation on lmms.io. Just check that out and it will become quite clear for you.

And to further explain that using the paths you specify in LMMS, even if not the default paths, works, actual VST files are working just fine, as I've been saying all along. They would NOT be if LMMS let you use your own custom paths and then insisted that your own custom paths be restricted to its defaults. But why would any open source app do something so stupid? Answer: it wouldn't. Someone could try to inflict an idiotic rule like that, but you'd then have a flood of other devs demanding that bug, and yes, it would be a bug---a self-inflicted bug, but a bug just the same, be fixed IMMEDIATELY.

The so-called "non default" paths that I'm using are all defined in LMMS's settings-->directories, thus making them the default for my system. If that's not clear enough, see https://docs.lmms.io/user-manual/gettin ... irectories.

A "non default" path would be one where I set the path for VST plugins to /foo/bar/VsT-UseThis and then instead, I put everything in /home/jim/VSTplugins (tired of typing M$ paths). But if I put them in /foo/bar/VsT-UseThis, as (hypothetically) configured in LMMS, that would then be the default. In other words, the default is what YOU configure in LMMS. That's why that whole section of settings is there in the first place.

I think I deleted this part when taking out a big chunk of this.... Note that I am NOT saying that nothing is working. The actual VST files are working fine, installed in the path that I configured in LMMS's settings. It's ONLY the MSE "VSTs" that aren't working. For that to be true, LMMS is clearly looking where it's configured to look. It just doesn't seem to like one of two types of so-called (by VST sites) VST files.

So can we please, IF this topic is going to be continued, look at those MSE "VST" files that are not working, and try and find out why they aren't working? As opposed to wasting time on why LMMS allows you to configure directory paths for where you put different types of files and then demands that you follow those "factory default" settings? If you want to continue that argument, please point out the specific source file(s) and the line(s) in said file(s) where it forces you to use hard-coded paths and ignores your own paths as defined in LMMS's directory settings. I will then submit that as a bug.

I am trying to help you, but I am stunned that those vst works on Linux through wine but not on your pc.
In general more vst do work on windows then on Linux.

Any windows users around, willing to test this vst ?

Gps, I have tested it! It works!
From what you imply, Jinx, it seems to me you're trying to open the MSEs with the LMMS VST host.
The MSEs simply seem to contain instrument information. Therefore, trying to run the MSE from the VST dialogue will not work.
What you need to do is first ensure the instrument folder and the .dll are in the same folder. This may seem obvious, but is important anyways. the dll should not be IN the instrument folder- for anyone who tries this out in the future. It should be beside it.
In LMMS, from the VST host, open the DLL, not the MSE.
The .dll is the vst, and it will look at the MSEs and itself load the instruments.
I apologize if you already did this, but I hope I help.
(Now that I read your first message, I realise you already tried opening the DLL.)

(Also, about your points: it isn't Windoez deciding that .mmps are documents, it's LMMS deciding they're documents. Also, it isn't Windoez getting 'confused' about extensions, because it blindly sends the extension to whichever app it is configured to run with. If it is unconfigured, it will probably throw a dialogue box asking for configuration. In this case, it is the Sonatina VST's job to interpret the MSEs correctly.)

Jinx wrote: ↑

May 17th, 2021, 1:09 pm

configure directory paths for where you put different types of files and then demands that you follow those "factory default" settings?

I would like to see a screenshot of your Settings| Path
Just like this one

Make sure the path for Samples is in the screen shot

As requested. Ok, that didn't work. It just posted the path to the image.

Monospace wrote: ↑

May 17th, 2021, 2:40 pm

Gps, I have tested it! It works!
From what you imply, Jinx, it seems to me you're trying to open the MSEs with the LMMS VST host.
The MSEs simply seem to contain instrument information. Therefore, trying to run the MSE from the VST dialogue will not work.
What you need to do is first ensure the instrument folder and the .dll are in the same folder. This may seem obvious, but is important anyways. the dll should not be IN the instrument folder- for anyone who tries this out in the future. It should be beside it.
In LMMS, from the VST host, open the DLL, not the MSE.
The .dll is the vst, and it will look at the MSEs and itself load the instruments.
I apologize if you already did this, but I hope I help.
(Now that I read your first message, I realise you already tried opening the DLL.)

(Also, about your points: it isn't Windoez deciding that .mmps are documents, it's LMMS deciding they're documents. Also, it isn't Windoez getting 'confused' about extensions, because it blindly sends the extension to whichever app it is configured to run with. If it is unconfigured, it will probably throw a dialogue box asking for configuration. In this case, it is the Sonatina VST's job to interpret the MSEs correctly.)

Thank you So its not a windows problem.
Now we need to find what goes wrong at Jinx.

Jinx wrote: ↑

May 18th, 2021, 11:47 am

As requested. Ok, that didn't work. It just posted the path to the image.

In the Info-post, http://lmms.io/forum/viewtopic.php?f=1&t=4740
-there is a guide for posting pictures

Here's a text version of what the settings-->Directories listing shows. I used code markup to keep the table lined up.

Headers copied verbatim, values copy\\paste:

One modification: Using two columns instead of one (where possible)