A few quick comments. Quoting Vesa <dii....@nbl.fi>:
> *#2. Revise some core parts of LMMS > 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... The "one thread per note" thing felt quite surprising when I first heard of it. I then went from "WTF?" through "sounds a little odd" to "OK, there must've been sound reasons for it". This change makes sense to my coding instincts, but thinking a bit more I'm pretty divided. So, this would be one thread for each track, one for the GUI and... N for the mixer? > Also considering that only instrument plugins that can even > theoretically benefit from per-note parallelization are our native > multistreamed instruments (triple osc etc.), That benefit will be real if you have enough stacking, arps and heavy filters in a track using e.g. SID. Basically, you're talking about stomping heavily on most native instruments to give the rest a little bit more CPU time, if any. I'd imagine a Zyn-only project not being hurt much by the overhead of non-existing threads handling non-existing notes. Is there any kind of guesstimate on how much overhead there is in the current massively threading model? > - 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 I'd look closely at what kind of code compilers can vectorize. Might be better to put the audio in something like float[notes*2][bufsize] and possibly get 4 or more channels through the env/lfo section in parallel. Same probably goes for parts of the mixer. > *#3. Revise automations > 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. "One knob, one track" is good, but... what about those relative automations you mentioned earlier, shouldn't you be able to apply them on top of absolute automation? Or what if there's a need to combine automation and LFO? I think there could be a market for mixing automation sources in some way. > *#4. Disallow overlapping blocks/segments/patterns in tracks > 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. Negative on adding/removing sub-tracks manually. If I move a block to overlap, why not just add another row automatically to hold the block? And the row would of course disappear when not needed as well. > Instead I think we should represent note length in ticks, decrement the > counter every tick and trigger note release when it hits zero. Notes > that are not pre-determined length can ignore this completely and have > the release triggered by the midi input. The MIDI model of note-on/note-off really has no alternatives when you think about live playing and streaming input events, and it should work for everything else, too. Maybe everything could move to that? I.e. a note plays until it's turned off. Or is there a need to know the note length in advance for any features? I could imagine some kind of advanced arpeggiator doing something with that knowledge. -- ra...@iki.fi softrabbit on #lmms ------------------------------------------------------------------------------ _______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
