lmms
lmms copied to clipboard
LMMS
Better Workflow
I'm creating a meta issue for better UI/UX workflow. This list should be updated frequently because it's the source of many of our new bug reports. If a new bug report arrives that seems workflow related AND won't be closed by a quick patch it can be marked as a duplicate and placed here.
Since workflow is so important to users -- something they can directly relate with -- this can also help serve as a futuremap if the developer team is to start milestoning certain enhancements (something we don't do a great job of currently)
Lastly, it can serve as a birds-eye-view (so to speak) of what our users really want. ❤️
💥 = Bug 🚀 = Good first issue for new developers
See also:
Tracks
-
Song Editor/Beat+Bassline Editor
- [ ] Better transport/playback/playhead behavior
- [ ] Position indicator and line behavior inconsistent between Song-Editor, Piano-Roll, Beat/Bassline and Automation Editor #857, #2123, #3052
- [ ] Global playback/transport #1357 [Milestone: 1.3]
- [x] Project should remember the last-used playhead behavior per #4192, #4556
- [ ] Better keyboard shortcut behavior when mixer is in focus #1140 (related: #1488)
- [ ] Better keyboard shorts in general #1144 (related: #1488) [Milestone: 1.3]
- [x] Proposal to use
>>as default playhead behavior #3740 - [x] Stop and return
|<<versus "pause" default behavior #3740 [Milestone: 1.3] - [ ] Link JACK transport with LMMS transport #4412
- [ ] Stop button should stop ALL sounds #1535 [Milestone: 1.3]
- [ ] Playback should stop at the end of a track #4643
- [x] Better track color support #1006 #1160 #1176 #2332 (in progress: #5573)
- [ ] Colored patterns #6650
- [ ] Rename Song Editor/Beat+Bassline Editors #121 [Milestone: 1.3]
- [ ] Add Beat/Bassline pattern previews #4845
- [ ] Ability to cut/join patterns in the sequencer #3829 #3633 (#5396)
- [x] Show mixer channel on each instrument (#2563, #6411) (via #6831)
- [ ] Volume control on individual B&B tracks #2218
- [ ] Disabling or changing the Song Editor's Bar Grid #2171
- [x] 🚀💥 Wrong cursor when moving blocks in song editor #879 #5996
- [x] UI/UX inconsistency: Beat and bassline pattern shown in instrument track #3060
- [ ] Changing Beat-/Bassline colours depending on their name #229
- [ ] Stretch/Shrink/Shorten Patterns via SongEditor #1658 [Milestone: 1.3]
- [ ] Inconsistent/confusing toolbar layout #4829
- [ ] Make instrument change undoable #1262 [Milestone: 1.3]
- [ ] Better workflow when adding BB #2014
- [ ] Annotations/markers/bookmarks (including Piano Roll) #156 #380 #5248 [Milestone: 1.3]
- [ ] 🚀 Open pattern to specific bar #3305
- [ ] Vertical Zoom in Song Editor #3763
- [ ] Pre-delay/leading track support #87 [Milestone: 1.3]
- [ ] Song editor group operations #1212
- [ ] Edit Automations directly in song editor #5541
- [ ] Group tracks in song editor #735
- [ ] Stop-gap measure: Hide/Show automation tracks #5726
- [ ] Save full toolbar state #6930
- [ ] Better transport/playback/playhead behavior
-
Piano Roll Editor
- [ ] Better placement of pasted notes #4836
- [ ] Add "quick clone" of notes #3015 (related #1844)
- [x] Ability to cut/join patterns in the piano roll editor #746 [Milestone: 1.3]
- [ ] 🚀Setting velocity on left-most note accidentally clicks changes to pan (similar to #4860)
- [ ] Draw note length in Piano Roll #3101
- [ ] Highlighting note lines with color #3027
- [x] Vertical Zoom Support in Piano Roll #2294 (via #5442)
- [x] 💥 Note automation in pianoroll is over Panning/Volume bar #1156
- [ ] In piano roll view, change to another track without losing the time position #2093
- [ ] Make step sequencer step size configurable #4823
- [ ] Faster chord creation #4361 #4079 #3673 #615 [Milestone: 1.3]
- [ ] Add a button to enable a piano-roll TCO #4209
- [ ] Finer note pitch bend precision #4234
- [x] Pitch bend recording directly to piano roll #3724 #6297
- [ ] Note "pattern" builder #688
- [ ] Note "humanization" #1165 [Milestone: 1.3]
- [ ] User added scales. #241
- [ ] Save full toolbar and loop marker state #6931
-
Automation Editor
- [ ] 🚀Hard click/select zero/bottom of automation editor #4860
- [ ] Support for automation presets #119 [Milestone: 1.3]
- [ ] Improved Vertical Zoom in Automation Editor #4313
- [ ] Connect to multiple Automation TCOs simultaneously #4132
- [ ] Ability to have both curved and straight lines in Automation Editor #4097
- [ ] Automation set/clear record button #2083
Instruments
-
Internal
- [ ] New: Add a new drum pad instrument #4877
- [ ] AudioFileProcessor: Allow sample loading from OS' drag-and-drop #2120
- [ ] AudioFileProcessor: Pitching/librubberband support #1734
- [ ] SampleTrack: Better SampleTrack support #1471 (
meta) [Milestone: 1.3] - [ ] **ZynAddSubFX: Use the empty ENV/LFO tab to control Zyn's envelopes #1965
- [ ] 🚀 All: Some instruments are too loud by default #113 [Milestone: 1.3]
- [ ] Instrument plug-ins tab memory. #3646
-
External
- [ ] Make frequently used VSTs easier to access #4853
Mixer and Effects
- [x] Rename "FX Mixer" to "Mixer" #3300
- [ ] 🚀 Pan knob #1974
- [ ] Wet/dry knob #4403
- [ ] Input gain control #118
- [ ] 🚀
dBindicators #1213 #4458- [ ] Snapping/faster/better fader/slider #3098
- [ ] Better default fader/slider location #3253
- [ ] Better default meters in mixer #75 [Milestone: 1.3]
- [ ] Mixer/channel presets #1680 [Milestone: 1.3]
- [ ] Mixer/channel templates #4023
- [ ] Support multiple selections #4644
- [ ] Drag & drop track assignment #2011 #3150 [Milestone: 1.3]
- [ ] Drag & drop reordering #605 #4655 [Milestone: 1.3]
- [ ] Make the Mixer window vertical resizable #3258
- Better visual indication of assignment
- [x] Show channel assignment on Song Editor #2563 (via #6831)
- [ ] Connections for selected instrument #1216
- [ ] Channels with no connection at all #1224
- [x] Assignable (or automatic) color support #1665 #2704 [Milestone: 1.3]
- [ ] More intuitive routing #1823 #4187
- [ ] Routing overview/dedicated window #1986 #3294 #4181
- [ ] Auto-sort option #605 [Milestone: 1.3]
- [ ] Grouping #606 #4402 #4650 #4644
- [ ] Option to show title instead of channel #3239
- [ ] Remove tooltips #3257
- [ ] Smart solo #6193
- [ ] 🚀Consistent wording/icons #3242
- [ ] Make the EQ (Equalizer) plugin resizable #1904 #4644
- [ ] 🚀Clone/Duplicate Effect (#1278, #5913) [Milestone: 1.3]
- [ ] Peak Controller needs logscales #188
- [ ] illogical controller for level on Calf Equalzer 12 bands ladspa #2052 [Milestone: 1.3]
- [ ] Automatically name peak controllers by source #332
Files and Folders
- [ ] Make "My Home" user definable in settings #1130
- [x] Arrow keys should preview samples in the file browser #871
- [ ] 🚀 Refreshing the File Browser should not collapse all folders #2121
- [ ] Default VeSTige File? #434
- [ ] Better Save As/Open/Browse Dialog #1834
Misc/Overall
- [ ] More PPQN? #1530 [Milestone: 1.3]
- [ ] Coding conventions #1826 [Milestone: 1.3]
- [ ] Export multiple regions to separate files #1931
I think this https://github.com/LMMS/lmms/issues/4554 is very, very related to this topic. Especially for lmms users with external controllers like me.
Because for now lmms workflow with external controllers isn't as good as it should be.
@qnebra you sent me a PM on Discord and I want to be more clear. Your bug affects workflow (all bugs do), but it's not a "nice to have" feature, it's a legitimate bug and should be tracked as such.
Quoting the bug you've linked:
it works, only if you disconnect "volume" from "mod wheel".
I want to keep the legitimate bugs open in our tracker so that they're easier for developers to find, assign and work on. The features above are related to items -- in most cases -- completely missing from LMMS and are better left in a meta issue so that there's a bird's eye view of demand and related issue. I hope that helps!
@tresf I like the idea of having meta issues (although tags might also do a good job for this particular problem), but the current way of doing this does not look "right" to me. ~Why close issues linked here and mark them as duplicates?~ The "normal" way I am used to is to use labelling to distinguish between feature requests and bugs, so they can coexist in an issue tracker and are only closed when implemented.
Edit: Seems like I misunderstood things a little bit, thought all issues linked here are closed.
@tresf I like the idea of having meta issues (although tags might also do a good job for this particular problem), but the current way of doing this does not look "right" to me. Why close issues linked here and mark them as duplicates? The "normal" way I am used to is to use labelling to distinguish between feature requests and bugs, so they can coexist in an issue tracker and are only closed when implemented.
Edit: Seems like I misunderstood things a little bit, thought all issues linked here are closed.
@claell Thanks for the feedback. I'm not aware of another way to cleanup 800 bug reports. Even with the above 100 bug reports, there are still over 600 still open that we need to sort through. Notice many already have 2, 3, or 4 duplicates! Other projects (like Ubuntu) simply blindly close out bug reports when they EOL a product, I feel this technique is better and I hope this approach is better received.
Moving forward, we'll have better bug submission standards which should help avoid duplicates as well as encourage people to open PRs instead of bug reports for minor changes.
Hm, maybe I am just not really understanding what this is for.
In general my opinion:
If these 800 bug reports / feature requests are actually not solved already then they shouldn't be closed, but maybe they are solved already or not relevant anymore. But maybe they are so "small" that it is not worth to have issues for every single one of them.
I guess the real problem is that on the development side there is too less "power" to keep up with the speed of new issues appearing.
there are still over 600 still open that we need to sort through
Maybe a better tagging can be used (or leave them open). I am not a fan of closing not solved issues, but maybe that is the most effective way.
Other projects (like Ubuntu) simply blindly close out bug reports when they EOL a product, I feel this technique is better and I hope this approach is better received.
Maybe I misunderstood this a bit, but I think there is nothing EOL here?
Still better than blindly closing things, so thanks for taking the effort to go through all these issues.
Maybe I misunderstood this a bit, but I think there is nothing EOL here?
Neither is there (EOL) with Ubuntu, that's the point. Most trackers force bug submitters to file against a "supported" OS version and then close them out blindly (no human review at all) when the OS reaches EOL. Many trackers do this. Trackers like JIRA can do this and they put the burden back onto the submitter (they notice the bug was closed incorrectly, they have to reproduce and re-file).
The problem with LMMS isn't the bugs though, it's actually the enhancements. The bug tracker is being misused as a wishlist and for a product with only a few maintainers and over 2 million users, this is a problem. Rather than tracking these requests as "open" it's more honest to ourselves to focus on what the project needs first.
For example... Take this rant into consideration... I'm typing this RIGHT NOW just off the top of my head...
The playback position head of a track sucks. The stop button should jump back to beginning, always!The pause should ALWAYS PAUSE, NOT STOP. The cursor should be consistent across ALL editors. Why isn't there a cursor in the Beat/Bassline editor? Why can't I click "pause" from the mixer? Why isn't there a visual indicator of the channel the track I'm working on is routed through?
These issues are fundamental flaws (or limitations) with the UI and the inconsistencies introduced over years and years of volunteer work. They were never design choices, but they can, will and have spun into dozens of bug reports all pretty much stating "do it like Ableton does" :)
Our permanent solution is to provide very strict submission guidelines (with a separate template for enhancement and bugs).
I am not a fan of closing not solved issues, but maybe that is the most effective way.
The first step to cleaning up ~~junk~~ a mess is to put it in a big pile and decide what to throw out. That's what we're doing and we need help. :)
Neither is there (EOL) with Ubuntu, that's the point. Most trackers force bug submitters to file against a "supported" OS version and then close them out blindly (no human review at all) when the OS reaches EOL. Many trackers do this. Trackers like JIRA can do this and they put the burden back onto the submitter (they notice the bug was closed incorrectly, they have to reproduce and re-file).
I haven't experienced this with bugs on Ubuntu, so I don't really understand what you mean, but I guess it is not that important.
misused as a wishlist
Well, of course you can decide what to use the issue tracker for, but in most projects the issue tracker is actually used as a wishlist without problems. I wouldn't speak of a misuse in that case. This just results in many open issues, but there is nothing bad about that imho, because you can filter for bug tagged issues.
Rather than tracking these requests as "open" it's more honest to ourselves to focus on what the project needs first.
Imho focusing can be done without closing them.
Our permanent solution is to provide very strict submission guidelines (with a separate template for enhancement and bugs).
Sounds reasonable. I created #4889 to create them.
I created #4889 to create them.
Thanks. @lukas-w already created a PR for this. Can you provide your assistance there so that it's centralized? Also, please search before creating new issues. 😉
Imho focusing can be done without closing them.
... and do what exactly? Pick a "good" bug, paste the other ideas into it and make it appear like it was written by the OP? We've been doing this right along and it's actually worse. The pruning is happening and it's going to make the tracker easier for the developers. If there's one that really needs reopening, please request it. Ideally, we'd have more people helping with these in general but they require a holistic understanding of the software, which is usually best corralled by a developer, tester, or power user.
but in most projects the issue tracker is actually used as a wishlist without problems
Not true. Projects with a large user-base and low-quality submissions (like openjdk) just block end-users from submitting.
I haven't experienced this with bugs on Ubuntu, so I don't really understand what you mean, but I guess it is not that important.
It may be a bad example but trackers do this, I just don't have an example, and I'm losing time to find one.
Also, please search before creating new issues.
I know, I know, only searched the issues, not the PRs :smile:
... and do what exactly? Pick a "good" bug, paste the other ideas into it and make it appear like it was written by the OP? We've been doing this right along and it's actually worse.
Why is picking a "good" bug needed? Imho the workflow is the following:
- User creates a feature request
- Feature request gets labelled correctly and edited if problematic
- Result: Good feature request
- Duplicate feature request is opened, can be closed with reference to good feature request
- Maybe problematic and result of this meta issue: The second feature request is actually better or requests more functionality than the original one. Solution to this would be to either reduce the second one to the added functionality or indeed add the additional functionality to the first feature request, which should not cause problems, but I did not experience what you did, so that might be different in practical situations.
- Result: Many small feature requests, might get overwhelming, so put them in meta issues and / or use tagging
Not true. Projects with a large user-base and low-quality submissions (like openjdk) just block end-users from submitting.
I said in most projects, in your example that might be true. So maybe we are both true in our points, while your point is probably more relevant.
It may be a bad example but trackers do this, I just don't have an example, and I'm losing time to find one.
No problem.
Many small feature requests, might get overwhelming, so put them in meta issues and / or use tagging
This bug report is a step in that direction. We've already closed about 100 bugs. We need to do 600 more and then we can talk about how big this mess is and what to with new meta issues moving forward. We're reading every bug report in the process and trying to find a home for it. Many of these bugs were opened by developers, and they're OK with this too. Cleanup always looks worse before it looks better. :)
Yes, but I meant without closing them :smile:
Reasons for leaving them open:
- There will be probably be discussion there if a developer decides to implement a feature from this list
- That way the issues can also be found when going through open issues
- It just feels wrong to me to close not implemented issues with maybe relevant discussions
Cons:
- Maybe they seem to clutter the issue list, but that should not be a problem with tagging
- If the issues are kept open they might need some polish, but I think that is worth it and I am also offering my help with that
There will be probably be discussion there if a developer decides to implement a feature from this list
We don't lock bugs, this can still happen.
That way the issues can also be found when going through open issues
No one goes through 800 issues. I agree it's hard to decipher open from closed, but that's solved in "what to with new meta issues moving forward" portion above.
It just feels wrong to me to close not implemented issues with maybe relevant discussions
Agreed but as a maintainer, it feels worse to have a bug tracker that at its current growth rate will have thousands of bugs, many being duplicate or describing a feature that won't be coded for years to come. It's misrepresentative of the contributors and the tracker is meant for developers.
We don't lock bugs, this can still happen.
I know, but usually closed issues aren't discussed that much.
No one goes through 800 issues
I know but with decent tagging there won't be 800 issues to go through but only a few. For example if someone searched open issues with the tag starter.
thousands of bugs
I don't see the difference of having them "pseudo"-closed or opened to this problem.
many being duplicate
Than they can be closed?
describing a feature that won't be coded for years to come
That is normal and should not be bad. Also I think one could introduce a tag for that to filter them out, if possible or put all relevant issues into milestones to get rid of "utopic feature requests" for the current development process.
the tracker is meant for developers.
Should be the priority, but not only. And I really don't see what is improved for the developers when closing those issues in comparison to leaving them open. To me that is maybe only a psychologic effect.
don't see what is improved [...] only a psychologic effect.
This is just more arguing of the same point. The reasons are clearly outlined and explained.
The reasons are clearly outlined and explained.
Well as far as I know, you never really explained what is bad about open feature requests, also I elaborated, why they are not bad. But ok, you can decide and it actually is not that bad to close them, so I won't ask for explanation any further and accept that you want to have this in that way.
Still my offer for help stands. This will probably require to add me to the LMMS team, which might be a bit fast from your perspective. If you need any references, some sort of interview etc. let me know.
What I would do / propose is to go through the remaining open issues and assign feature requests with more detailed tags like piano-roll, song editor, mixer and effects etc. Those tags might not be perfect at start, but can be renamed or agglomerated in a later effort. That would allow you to filter through those tags in order to agglomerate those issues in this meta issue.
What I would do / propose is to go through the remaining open issues and assign feature requests with more detailed tags like piano-roll, song editor, mixer and effects etc. Those tags might not be perfect at start, but can be renamed or agglomerated in a later effort. That would allow you to filter through those tags in order to agglomerate those issues in this meta issue.
Tags can help find a particular issue if that's what you're looking for, but they're not holistic. Holistic coding requires knowledge of the codebase and corralling of issues. With 800 issues falling into 10, 20 or 50 different categories, tags can become busy work that results in the same mess.
Still my offer for help stands
Observed efforts are concerning. For example, choosing to rename internal names/files (#4890, more work for developers). Furthemore, making an issue -- this issue, an organized effort to consolidate bug reports -- a home for endless conversation ~~is detrimental~~ has historically proven detrimental to productivity.
We can discuss more on Discord. Familiarizing yourself with the team would help.
Tags can help find a particular issue
Yes and they can also help sorting issues, find duplicates etc.
but they're not holistic.
I don't understand what you mean with that.
corralling of issues.
I'd be interested in a source for that statement.
falling into 10, 20 or 50 different categories, tags can become busy work
Well, it will be work, but that work has to be done anyway. And regarding your repeated "mess" statements, have a look at
https://gitlab.com/gitlab-org/gitlab-ce/issues
and how they handle their bunch of issues. To me it looks like it works for them and I don't see a reason why it shouldn't work here.
concerning
Sad to hear that.
choosing to rename internal names/files
I asked @SecondFlight before, so please stick to the facts.
a home for endless conversation has historically proven detrimental to productivity.
Again, please stick to the facts. I contacted you via Discord just because I did not like to discuss this in this GitHub issue. You told me the discussion should be ~continued on GitHub~ public, I assumed you wanted it here and you never complained before. I don't like how you now give this back to me and insult me like this was my fault.
We can discuss more on Discord.
Alright.
You told me the discussion should be continued on GitHub, here we go
No, I said "public".
I asked @SecondFlight before, so please stick to the facts.
I'm not sure what this is in reference to. Regardless, these types of ad hominem replies quickly become toxic. Feedback about the renames were made in the relevant bug reports.
In regards to holistic and corralling, it's about overall view of the project (how it's progressed, how it will progress, what the necessary resources are to continue progressing). It's about combining related items as well as... and this part is very important... the unnecessary specificity of requests that are trivial (i.e. Items that explain basic improvements that are common sense to any UI developer, just lack the hours and hours of coding, debugging and testing to roll into a future release. Furthermore, items that have no intention to be worked on are pointless to be in "open" state. Different projects have different opinions on this, but I'm not sure GitLab is a good example. 1. They're commercial, we're not. 2. They have 33K issues, one of which is that with that many issues, searches result in a 500 error. Ouch.
Anyway, we're not trying to discourage help, but spending this much time arguing the Open/Closed state of a bug that the project actually cares about is a classic example of Parkinson's law of triviality.
This is great!!. Having all the problems listed and organized is the best. although I have been able to observe some even greater problems:
- There are many errors and improvements and the list is increasing.
- There are few collaborators and developers.
- All those improvements will require a great development time to implement them all.
- Each improvement will bring new errors.
- The improvements are being released in test versions (RC), instead of periodic updates (1.2.1, 1.2.2, etc.)
- Each release has a lot of accumulated improvements, and this brings even more problems.
- The release of stable 1.2 was delayed.
I know that stability and launch are not the central theme of this thread, but if these affect stability, therefore affect the work flow, therefore in my humble opinion, I suggest:
- Discuss more thoroughly which improvements are more urgent than others.
- Discuss which improvements will require more development time than others.
- Organize the improvements in order of priority.
- Do not accumulate too many improvements for a single release.
- Examine the stability of some improvements tested in '' master '' and if they are stable, merge them to '' stable ''.
- Create a goal with improvements for the next update, milestone 1.2.1.
- Do not accumulate too many improvements for 1.2.1.
I understand that no improvement is '' simple '' to develop and that it will take time, but if the project is organized in this way, the improvement of work flow and all the development of lms will be faster. over time the list will increase but if we take into account the order of priority of the improvements, it will be better for everyone. regards
I appreciate your input, but please allow me to correct some of what you've said, as your premise is largely inaccurate:
There are many errors and improvements and the list is increasing.
Indeed, this is what the list is meant to help with. Our issue tracker is unbelievably bogged down, mostly with well-meaning enhancement requests. The primary goal of this list is to concentrate the mess into one place and allow us to close issues with lower priority. This list is getting bigger, but each time an item is added to this list, it is closed on the tracker.
The improvements are being released in test versions (RC)
This is not true. There have not been new features added to the release candidates in over a year. All changes to the RCs are bug fixes.
The release of stable 1.2 was delayed.
This is because there have been a lot of bugs worth fixing.
This list is not a list of must-have features that we plan to implement. This list simply represents an effort to clean up our tracker. Every feature on this list has been open in our tracker for some time, but the act of moving these features here doesn't mean we plan to implement all or even any of them.
Organize the improvements in order of priority.
This is a good idea. At the end of the day, priority will be decided by whoever actually does the work of implementing a feature. We won't complain if another developer doesn't agree with our priority and implements a low-priority feature or bugfix. Still, I think prioritizing issues is a great idea.
Not sure if this is the right place to comment for this, but I wanted to better organize, format, and generally prettify the Coding Conventions page for easier reading. Are we still wanting to have that page? I do see some other PRs now for clang-format and clang-tidy, but I'm not sure where things are going with it.
I did go ahead and make a prettified version here (with extra stuff at the top to make sure I covered things) in case we want to update. I figured using RFC style requirement keywords would be best to describe what rules could be bent or not.
Not sure if this is the right place to comment for this
Thanks. It's not, really.
This thread is for software workflow (not developer workflow). Probably better for the "how to keep programmers" threads.
The organization of topics in the new version is nice. The capitalization and italics for words like NOT (does the RFC recommend this sillyness?) aren't needed (I don't even see this weirdness in license agreements, where there's legal action). Anyway, the fact that you've taken the initiative to help the project means something to us, you can start editing it any time. Just ping someone one #devonly on Discord for access, linking this comment.
Not sure if this is the right place to comment for this
Thanks. It's not, really.
I was going to comment on the closed Coding Conventions issue, but I'm not sure how y'all like commenting on closed issues, and you stated from that one that this superseded it.
The capitalization and italics for words like NOT (does the RFC recommend this sillyness?) aren't needed (I don't even see this weirdness in license agreements, where there's legal action).
That was my choice, RFC only states they are "often capitalized". I wanted to put emphasis on them to make them stand out. It can easily be removed. 😁
Anyway, the fact that you've taken the initiative to help the project means something to us, you can start editing it any time. Just ping someone one #devonly on Discord for access, linking this comment.
Sounds good! Thanks.
a comment on
Make "My Home" user definable in settings #1130
Presets saved as xpf-files has path to the instrument hard-coded in the file. It does not matter for LMMS-instruments, but it does for VST-presets
plugin="H:/LMMS/presets/VST/DSK techsynth PRO/DSK TechSynth PRO.dll"
This is a problem when
- migrating to a new pc
- collabs between several users
Why not have that path dynamically linked to a path in Settings, then this problem would be gone
Presets saved as xpf-files has path to the instrument hard-coded in the file. It does not matter for LMMS-instruments, but it does for VST-presets plugin="H:/LMMS/presets/VST/DSK techsynth PRO/DSK TechSynth PRO.dll"
The VST relative path logic is only coded for the samples directory. Please use that instead of the presets directory. A DLL is not a preset and shouldn't be organized as such.
The VST relative path logic is only coded for the samples directory
@tresf You mean that VST-instruments dll-files is meant to be in the Samples directory? Eg :..\Documents\lmms*samples* There? Sorry but that is not intuitive for me. SF2' could be regarded as a kind of 'samples', but VST-dll's files, UI-files and banks?
What is the logic behind that idea, and when (version) did implement that ?
I wrote it a while ago because the relativize logic was already written for samples, scaled well to SF2 and and there was no dedicated "plugins" folder yet so we added the logic to VSTs as a stop gap.
Note, VST effects use a different folder that's configured in the settings