LMMS Futuremap

[diizy]

I didn't want to call this a roadmap because this isn't any kind of official decision or anything.

I'm just making this thread to gather together all the ideas and long-term goals that we have for LMMS, and if applicable, an expected timeframe when it could possibly be implemented.

These are all things that have been discussed about in the mailing list or github. I can update this list in the future and everyone is also welcome to suggest more additions to the list.

Architecture, compatibility, backends and plugins

• LinuxVST support: for this we would need someone who understands how the VST format works (particularily on Linux). We already have support for VST through wine, so implementing this could be modeled on that, or alternatively, some existing LinuxVST host could be ported into an LMMS plugin
• LV2 support: grejppi (and Harry van Haaren?) have are already worked on this. This can possibly be done in the 1.2 timeframe.
• Better Jack support: (Better JACK support #1467) this is a kind of umbrella entry for various Jack-related things: Jack-inputs (for recording, eventually), Jack-outputs... Jack-transport support, freewheeling? But the main thing would be to get the basic Jack backend working flawlessly.
• Support for session management
• DSSI support

Optimizations in threading and internal architecture
(This is all going to be somewhat technical stuff, not very understandable for someone who's unfamiliar with the LMMS inner workings)

• Complete support for sample-exact models
• NotePlayHandle: modify the way note offset is implemented: Don't hold the offset for the lifetime of the NPH, instead negate it in the first period. This would be necessary to allow instruments to make use of sample-exact models. implemented in master
• Threading optimizations. Make the core rendering function more efficient.
• Convert the AudioPort -> FxMixer connection to use a pull model. The recently implemented FxRoute construct could be extended to AudioPorts so that FxChannels can read directly from them the same way the read from other FxChannels.
• Implement automatic latency compensation: LADSPA plugins have an unofficial, de-facto standard way of announcing latency, which is supported by many other LADSPA hosts. VST-effects have an actual standard interface for announcing their latency. We can use these to figure out the relative latencies of all streams and at each point where streams are mixed, compensate for the latency difference by delaying the least-delayed streams. Total latency would then be the maximum between all streams. Additionally a manual latency adjustment widget could maybe be added to instrument tracks.

UI and functionality improvements

• Implement tempo tracks (this should be done in the 1.2 timeframe)
• Refine sampletracks to work correctly: play from any position, be tempo-aware, connect to FX-channels (same as above)
• Sampletrack recording (possibly for 1.3 - 2.0)
• Time signature reworked: convert current time sig widget to work more as a "grid" setting which doesn't affect pattern lengths but only the song editor snapping. Add a separate time sig property to all patterns, so that each pattern can have their own internal time sig, and different time-sigs can be mixed in the same project. (no time-estimate for this, but possibly before 2.0)
• Better editing features (partially implemented already in 1.2 branch)
• Allow merging/splitting of notes in piano roll, and patterns in song editor
• Note effects: a major feature, no time estimate. A way to create effect plugins that work per note for native multistreamed instruments. Would replace the ENV/LFO tab, and the plugins would have inline GUIs so the notefx would be a more flexible and modular version of the current ENV/LFO tab. For compatibility, the legacy ENV/LFO tab's functionality could be implemented as a note fx plugin, and we could also have improved and different envelopes/LFOs for notes. (User could choose between vector envelopes, regular ADSR, or combine them any way they want...)
• Per-note controls: an architectural change that allows native instrument plugins to expose per-note controls that can be controlled from piano roll the same way as per-note volume, pitch and panning are. No time estimate... all theoretical for now.
• Export format: allow saving projects in an "export format", where all the external resources (samples, soundfonts, sampletracks) get packed in with the project. To ease collaboration among other things.
• Live play improvements: allow muting piano roll preview, add loop controls: move loop fwd/back, double/halve loop length, duplicate/erase loop
• Select samplerate for playback
• MIDI export (see below, no timeframe)
• Per-FxChannel export: allow exporting a project so that you can pick output from any FxChannel, including master, and write them to different files. All can be rendered simultaneously. (somewhere between 1.2-2.0 hopefully)
• Non-integer tempos
• Group tracks (assign tracks to collapsible/expandable groups to conserve editor space)

GUI and visual/theming improvements

• More themes that are maintained and offered with LMMS
• Better theme selection in settings, possibly also: on-the-fly theme changes?
• Add metadata to themes (maybe this would be smart to do for 1.1 so it wouldn't be an incompatibility issue later on?)

Life-cycle/Maintenance

• Provide apple support/downloads (support being a relative word here) - Requires fixing a few bugs (Zyn GUI, SF2 Crash, File Association). Nice to have: Wine VST support.
• Provide (or re-introduce) "upgrade" support specifically for config upgrades - Self explanatory

Uncategorized

• Finish implementing Undo/Redo - Self explanatory

GUI and visual/theming improvements

• Switch Zyn from FLTK/Plastic theme to Dark NTK theme - Requires removing FLTK build requirements and adding NTK requirements (NTK is not readily available from Ubuntu repos, requires manual DL/compile).

[DeRobyJ]

MIDI export
MIDI import with tracks (I read that currently lmms imports channels, but I may have not understood)

About the MIDI export, I think that if making a complete export (with automations) is difficult, we should firstly work for score-only MIDI export

Can't give a timeframe because I lack of knowledge about these.

[diizy]

Added to list.

[musikBear]

What about the ladspa discussion we had
http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Zyn-LADSPA-plugins-are-not-working-well-tp9378.html
on quality over numbers, and looking into zasfx stand-alone effects or an understanding of why manual loading of vst effects works perfectly, but lmms cant do it in saved projects -All this could be boiled down to one bullet point:
Give lmms one exelent suite of effects

[diizy]

On 06/29/2014 02:08 PM, musikBear wrote:

What about the ladspa discussion we had on quality over numbers, and
looking into zasfx stand-aline effects or an understanding of why
manual loading of vst effects works perfectly, but lmms cant do it in
saved projects -

I didn't include any bugfixes in this.

All this could be boiled down to one bullet point:
Give lmms /one/ exelent suite of effects

Well that's kind of problematic because many don't want any more
third-party code added to LMMS. We could add some stuff as optional
dependencies if they're commonly available as packages... but then, if
they are, they could just as easily be installed by the user themselves...

[HDDigitizerMusic]

I think I've heard discussions about changing the names of the song editor and beat and bass line editor in LMMS to more standard names, such as "Sequencer" and "Pattern Editor"

Also, ghost notes for each pattern in the pattern editor. Like this:

Not sure how long it would take, but it would be an excellent feature.

To me the most important next step is Finer Scaling In The Sequencer as I posted here: #874 (Not sure if its already on the list though.)

Lastly, graphics showing whats in the pattern you place in the song editor would be quite helpful.

[Sti2nd]

Those graphics showing whats in the pattern actually made it into some branch, didn't it @diizy and @pgiblock ?

[diizy]

On 07/01/2014 12:32 AM, Stian Jørgensrud wrote:

Those graphics showing whats in the pattern actually made it into some
branch, didn't it @diizy https://github.com/diizy and @pgiblock
https://github.com/pgiblock ?

What graphics? I don't follow...

[tresf]

Some of my own recommendations:

Life-cycle/Maintenance

• Provide apple support/downloads (support being a relative word here) - Requires fixing a few bugs (Zyn GUI, SF2 Crash, File Association). Nice to have: Wine VST support.
• Provide (or re-introduce) "upgrade" support specifically for config upgrades - Self explanatory

Uncategorized

• Finish implementing Undo/Redo - Self explanatory

GUI and visual/theming improvements

• Switch Zyn from FLTK/Plastic theme to Dark NTK theme - Requires removing FLTK build requirements and adding NTK requirements (NTK is not readily available from Ubuntu repos, requires manual DL/compile).

[tresf]

Should we put the domain/website stuff on here, or just stick to the software-specific milestones?

[diizy]

On 07/01/2014 07:41 AM, Tres Finocchiaro wrote:

Should we put the domain/website stuff on here, or just stick to the
software-specific milestones?

Just the software I think. Website stuff is probably better left to be
discussed on the mailing list...

[musikBear]

Before this just turn into another 'i would like to see' thread, i think it would be a good thing if we kind of decided focus-points for versions
1.1 obviously focus mixer
1.2 looks like a focus on sample-track and changes in sample and sound usages
1.3 ..?
Now i ofcause should not add anything here, because then i just also joins the 'i would like' :P ..but
Personally i would like a General usabillity focus. Get more ways to handle and display notes in pianoroll and song/BB-editor
-A lot of great idears has been put forward. The cardinal-feature to make peeps aplause, would be ghost-notes, but anything connected to
copy, paste, draw, split, merge, jitter, patterns
could/ should be in this focus 1.3
Here i would shamelesly sugest that anything we know and like from any other DAW .. steal!!!
ehh uops.. mean ofcause get inspired :P
Focus would mean structure, and the whole catalog of ideas could be improved this way -Would also make sure that good idears are not forgotten in the pileup.
imo.

[diizy]

On 07/01/2014 03:17 PM, musikBear wrote:

Before this just turn into another 'i would like to see' thread, i
think it would be a good thing if we kind of decided focus-points for
versions
1.1 obviously focus mixer
1.2 looks like a focus on sample-track and changes in sample and sound
usages
1.3 ..?

Well that would be easier to do if we were a company with paid
developers and schedules... as it is, we have pretty much no idea about
the pace of development, how much we can do for which version...

Also, there isn't really a single "focus" for each version - each minor
version (1.1, 1.2 etc) comes with several new major features, it all
depends more on the, shall we say, dependency graph of the features -
like how sampletrack improvements depend on implementing a tempo track, etc.

But, since you ask, I can give you some general guidelines:

• 1.1 is pretty well known already. It introduces new instruments, new
  FX Mixer, Undo/Redo, logscale models, more accurate timing for several
  instruments...
• 1.2 I would say, the biggest focus as of now is actually the
  sample-exact models. This is something which is seriously a pro-grade
  feature, and I'm actually quite proud of the implementation... when it's
  finished, it can potentially allow sample-exact modulation of almost any
  knob. Tempo tracks and sampletracks may be implemented in 1.2, but it
  may also be that one or both of them may get pushed to 1.3 - it all
  depends on how long it takes to finalize 1.1, and how long it takes to
  finalize sample-exact models and some other things which I don't want to
  talk about too much yet...
• 1.3 is way too early to say yet.

Focus would mean structure, and the whole catalog of ideas could be
improved this way -Would dampen the 'noice'
imo.

The only problem is, with our current scarce developer resources, we
can't really afford to tell people "sorry, that's a nice patch there,
but that isn't really our focus in this version"...

[musikBear]

we can't really afford to tell people "sorry, that's a nice patch there, but that isn't really our focus in this version"...

That is true! +acknowledged :)

[StakeoutPunch]

What about #735 ;)

[diizy]

Added non-integer tempos and group tracks to list.

[tresf]

#977

[diizy]

Should maybe update this at some point

[ViktorNova]

Just throwing my 2 cents in as a long time occasional user of LMMS
I would happily pay $100 for it if LMMS had Jack transport and session manager support (NSM, preferrably)

[tresf]

I believe 2.0 to be an important time to reorg some of our samples (since compat will be affected anyway).

Can (should) our samples team start working on the reorg for the 2.0 branch now, or do we do this after we are closer our goals?

[diizy]

On 12/06/2014 09:20 PM, Tres Finocchiaro wrote:

I believe 2.0 to be an important time to reorg some of our samples
(since compat will be affected anyway).

Can (should) our samples team start working on the reorg for the 2.0
branch now, or do we do this after we are closer our goals?

I'd say wait a bit until the 2.0 branch is in a more usable state...

[Sti2nd]

You know, @diizy , the wiki on github would probably be a better place to maintain a futuremap, I doubt people will naturally search for roadmap in a bug tracker https://github.com/LMMS/lmms/wiki/Roadmap

[Spekular]

@Sti2nd makes very much sense to me. We have issues with feature requests
and bug reports, milestones, branches etc. This is an excellent place for a
roadmap. We could have it elsewhere as well I guess, but it's very valuable
to have a roadmap where the development happens so people know what to work
on next and stuff like that.

[tresf]

Possible additions:

Samples/Presets

• Reorganize/consistent naming for built-in samples (WARNING: this will break backwards compatibility)
  • i.e. samples/tr909/TR909_Kick.ds vs samples/tr808/Kick.ds vs samples/tr77/Tr77_kick.ds
• Add 15+ quality presets for all built-in instruments
• Fix/remove broken or bad-sounding and redundant presets (started per More Presets #1127 Updated 3OSC Presets #1100 New presets for Monstro, Bitinvader, Watsyn and Kicker. #1139 Two new presets for Kicker #1346)

Uncategorized

• New parametric EQ (started per Native Eq plugin #1376)

-Tres

[Sti2nd]

@Spekular Oh, ok. It does seem like you think the developer wiki is on another place than github, which is where the development is going on... but if you actually did search for roadmap/futuremap in the bug tracker and found this, I guess other devs also will think about that. (Assuming wiki pages isn't searchable in the bug tracker)

[Moth-Tolias]

if this is no longer being used as a roadmap, was a replacement ever made? there's not one in the wiki.

[DeRobyJ]

Well actually some of the things were recently requested.
Also, this list mentions optimization changes, and without it I fear we'd lose track of those.

[tresf]

if this is no longer being used as a roadmap, was a replacement ever made? there's not one in the wiki.

It's still loosely being used, but we're not updating it. Most of the items are completely relevant and several are underway. If there is a component someone wants to spearhead, please ask. 👍 If someone wants to help track these initiatives, let us know and we'll grant rights to track issues.

[liushuyu]

It's still loosely being used, but we're not updating it. Most of the items are completely relevant and several are underway. If there is a component someone wants to spearhead, please ask. 👍 If someone wants to help track these initiatives, let us know and we'll grant rights to track issues.

Yes, some of them had already completed while some other are underway. The other are currently not considered due to lack of experienced people to work on or even required a refactor.

[Spekular]

Perhaps we ought to change this to a Task List @diizy @tresf

[Moth-Tolias]

...to continue butting in, should this have a meta tag?

[tresf]

Closing since this offers no benefit to the tracker by being open alongside > 500 bugs.

For those new to the project, it's worth a read. About 20% of enhancements are going to fall into this list.

To do it justice, it should be made into a proper checklist with attainable goals, in a thread maintained by an active developer(s). Each goal may have open PRs and bugs associated which should also be researched and reference. When that time comes, we can cross-reference this as needed.