It's again time for me to write about things I've been thinking about relating to LMMS development.
These ideas have been brewing in my head for a while, and some of them may be controversial to some. Nevertheless, sometimes it's necessary to make some sacrifices in order to achieve something great. The gist of the idea is, basically: *LMMS 2.0*. And not just in the sense of a version number increment, but actually more like a very extensive rehaul of how the software works both inside and outside. Why is this controversial, you might ask? Well... let's start from the item I expect the most flak for: *#1. **Get rid of legacy cruft *Meaning: get rid of all backwards-compat hacks. We have "compat code" extending all the way back to 0.3 version series, maybe even earlier. I think it's high time to get rid of those. People who still have old projects made with such ancient versions can then just use 1.0 or 1.1 to edit those projects - perhaps someone can even maintain an old compat version and keep it from bitrot, but that should no longer be a concern for the LMMS devs. With the scarcity of our resources, it simply doesn't make sense to have such a focus on such extensive backwards-compatibility. But that's just the beginning. What I'm suggesting is more radical than that. I'm saying, basically, that LMMS 2.0 would break backwards compatibility completely - no compat code for any 1.0, 0.4, 0.3 or any earlier versions. Why such drastic measures? Well, one reason is, that all the compat hacks reduce maintainability, they add code complexity for very little real world benefit, potentially cause bugs which have to be found and fixed, draining resources. And also, they're holding us back. If we want to make a big change or improvement, having to consider backwards compat is an extra burden... IMHO, it's better to break compat if it allows us to bring something new and better to the table. *#2. Revise some core parts of LMMS *So, this is getting into quite technical stuff, and I imagine a lot of people here won't have much to comment on this, but I have to write this stuff down somewhere, so might as well be here... There's already been talk of rehauling the LMMS rendering engine. Unfortunately, Paul is no longer active, and without his help, I don't think migrating to the Unison core (no matter how awesome it is - I've taken a look at the code, it has some really neat concepts) is going to happen. Also, our efforts of trying to get someone knowledgeable in RT-audio coding to help work on the engine have so far been in vain. So anyway, I've been trying to think of ways to mold the current engine into something workable. So here's some things I've been thinking about that could help realize that goal: Get rid of the idea of rendering each note in its own thread. Instead, move to a more conventional approach: one thread per track. The reasoning here is simple: most people have at most 4 cores at their disposal, and most projects have at least 4 instruments playing at the same time at most times, so excess parallelization is not likely to provide that much benefit. In fact it could well be counterproductive, considering all the thread-safety stuff, building job queues, processing lots of small threadable jobs... Also considering that only instrument plugins that can even theoretically benefit from per-note parallelization are our native multistreamed instruments (triple osc etc.), and that since we now have Carla, and native LV2-support on the way, and already pretty good wine/VST support - and NONE of those benefit at all from per-note parallelization, in fact it probably HURTS the performance of those instruments... so why not change it to something that works for both native instruments and external ones? I've come up with a way to do this that would also allow us to keep the unique features of our native instruments (per-note pitch automation, per-note panning, the env/LFO tab). This is even more technical stuff, so I won't go into too much details here, feel free to ask me if interested, but I'll outline the logic flow: - Song generates NoteHandles from the Notes in patterns (NoteHandles will replace NotePlayHandles, the name change is to indicate that they no longer inherit PlayHandle nor ThreadableJob and won't be rendered as such) - The generated NoteHandles are gathered to an array/list within the InstrumentTrack - Every instrument gets an InstrumentPlayHandle - the IPH renders all notes serially, one at a time, using a stack buffer, and applies the soundshaping (env/lfo) on each rendered note, before mixing it into the mixing buffer - when all the notes' output is written to the mixing buffer, it is passed to AudioPort, which applies the FX chain to it and the destination FX channel can then read the input from that same mixing buffer Similar logic can be implemented for sampletracks. In fact, this will unify the way sampletracks and instrumenttracks work internally, and I believe it will make it easier to make sampletracks work the way they should - playback from any position, recording, etc. Whereas instruments have NoteHandles and one InstrumentPlayHandle, the corresponding constructs for sampletracks would be SampleHandles and one SampleTrackPlayHandle (names subject to change). AudioPorts for sampletracks can work exactly the same way as for instrumenttracks. AudioPorts can also incorporate a ringbuffer that allows us to do manual latency compensation: Basically, you can manually set a positive or negative delay for each track. *#3. Revise automations *Automations will work per-track. One knob can only be connected to one automation track. I've talked about this before and explained the benefits of doing so. The logic in automations will also change. Automation tracks will no longer push their data to the model, instead it'll work the same way as controllers, where the model reads from the automation track as needed. The purpose of the "one knob, one track" rule is to make it so that there can't be two overlapping automations to the same target, because this causes undefined behaviour - the user can't easily predict which automation gets applied to the knob, so it's bad UI. And to that effect, there's also the next item: *#4. Disallow overlapping blocks/segments/patterns in tracks *This is very bad UI design. Mainly because there can be hidden elements in tracks, which the user can't easily discover, and it is even worse for automations because of the aforementioned overlapping automations problem. Instead, each non-automation track could have multiple rows or "sub-tracks" which the user can add/remove. This way you could still have overlapping patterns on instrument- and sampletracks, but automations would disable that possibility. Of course, we could just disallow overlapping on automation tracks only, but the rows/subtracks would still be better UI (no hidden elements). *#5. Implement lots of the already planned/discussed things*: Dedicated tempo track, sampletrack playback from any position, per-pattern time signature, rehaul of beat patterns and b/b tracks, get rid of all the locks (well, as much of them as possible)... these are all still part of the vision for LMMS 2.0. But by reworking the aforementioned core aspects of LMMS, many of these things become much more feasible to implement, because we don't have to constantly fight an engine that was never designed to do many of the advanced stuff we're trying to force it to do. Of course, getting to that point is going to be a lot of work, and we'll need all the help we can get in order to make that possible at all. Getting back to item *#1*, many of these changes are such that if we're to have any hope of implementing them, we're realistically going to have to say bye-bye to backwards compat because the changes required are just so big and profound, and adding in backwards compat to that equation would just make it overflow. But I do believe it would be for the better, in the long run. Now, for some actual schedule/roadmap plans... I think we can keep working on 1.2 as we are now, but after 1.2 is released, the focus of development would shift towards creating "the New LMMS" or, LMMS 2.0. 1.2 could be maintained as the last version to provide compat for older versions, for some amount of time, with some amount of effort, so people could have some time to transition from the old to the new. So in conclusion, the idea is to make LMMS 2.0 earn that version number. To strive for something great. To make LMMS into a respectable, professional-quality DAW. That is all.
------------------------------------------------------------------------------
_______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
