On Wed, 1 Jan 2025 22:29:55 +0100
ichthyo <p...@ichthyostega.de> wrote:
>Hello Yoshimi-devs,
>
>First things first: a happy new year to everybody!
><sarcasm>
> Some people around the world are engaged with determination to make this new
> year a big mess.... so let's hope matters go south in mostly unexpected ways!
></sarcasm>
Exactly!
>After we've somehow managed to close out the last round of internal changes
>(seemingly without major problems up to now...), I was wondering if it's the
>time to pick up on one topic which I have on my mind since quite some time.
>
>On 31.12.24 19:44, Will Godfrey wrote:
>> I'd like to be able to make another minor point release in February,
>> so it would be good to have a significant development to hang it on.
>> Ideas, most welcome!
>
>
>My most important wish is to let us proceed in a considerate way.
>The time and capacity I'm able to put in *is limited*, for sure, because I have
>to focus on my main project (Lumiera). So, while I'm proposing something bold,
>I'd like to ask to break it down into several small increments, and -- above
>all
>-- to avoid those "*big bang*" changes. I mean, if that's possible at all,
>since
>we've all made the experience that often matters can escalate to a much wider
>scope in the Yoshimi code base, than was initially expected. :-/
>
>
>In a nutshell: I'd like to pick up that topic of *balancing the presence* of an
>instrument or the closely related global parameter links like *crossfades*.
>
>See the threads "Note-Weight-Adjustment" and "Crossfade" from last summer.
Jumping in here. I've already read through the rest, and broadly agree.
>My proposal is to proceed in several steps:
>
>(1) have a up-front discussion about *what* we want to achieve;
> take the necessary time to define the scope of where we're headed.
>
>(2) do a technical prototype to bring in the foundational changes into the
> engine. Make performance measurements to see if our guesses were right.
> Recall from the mentioned discussion that we assume that it should be
> possible to bring the base extension into the engine without a measurable
> impact on performance (at least in disabled state)
>
>(3) then merge that change into mainline, test it and bring it into widespread
> use in some minor release, so that we have to option to back out or search
> for a better approach before anyone starts to use the new feature in
> creative ways.
>
>(4) only then build the GUI part and gradually make the feature visible for
> the users. Consider how it relates to existing features like Crossfade
> and Velocity sensing. Mark it as "experimental" first and try to get
> feedback from the users.
>
>
>
>Following this outline, we'd be currently engaged into (1), and we'd be able
>to change course and reshape the direction up into point (3), in case it
>turns out to be to much for us to handle....
>
There is something that has been bothering me literally for years, and if
resolved first, could help with the rest. If nothing else it would give as more
experience with the note structure.
We are very 'wasteful' of notes. At each note on we allocate memory, define all
the elements, then populate it with the starting parameters.
When the note finishes we throw this all away, and start again with the next
note.
I would suggest we use note pools *per part*.
In outline, as soon as a part is enabled, in a background thread we create (say)
6 notes with all the structure in place but not sounding.
When a note on event arrives, we only need to set the starting values in the
first available free one, and enable it. When it ends we disable it, but don't
destroy it. The mechanism for that is pretty much already there.
Speculatively we create spare disabled notes for the part (again in a
background thread) to try to stay ahead of the note count. Also, we can release
some disabled notes if the part goes silent (but still enabled).
We only fall back to creating and filling together if there are unexpected
multiple notes at pretty much the same time.
If a part is disabled we clear the lot.
Finally, there are some parameters that are always the same at the start of a
note, so these could also be prepared in a background thread for non sounding
notes.
This probably won't make much difference to the simplest notes, but to things
like kits and/or AddSynth engines, it would soon mount up.
If we do this, it would be the ideal time to leave 'hooks' for adding
parameters to the notes themselves.
>To make the first step: here is how I see this possible bold new feature:
>
>* The point of operation is in the "note on" code. In each Part, right now
> there is basically a similar piece of code, which takes the raw parameters,
> does some fusion on them and computes the parameter values effective for
> this
> note, i.e. the effective frequency, gain, filter cut-off or vowel position.
>
>* the core idea is to allow for a /very small number/ of additional control
> parameters to be transported into this code. Right now it is only driven
> by the note (midi) value, the velocity and the volume. So the idea is
> to extend that and allow -- say maybe two or three additional controller
> values as input. Which ones these are would be a matter of instrument?
> patch? or global instance? (do be discussed!) setup. The prominent example
> would be a channel pressure, or a per-key aftertouch. This immediately shows
> that we'd have to re-evaluate this piece of code while playing a note under
> some circumstances; and we should carefully plan how to do that.
>
>* and then, at the heart of the feature would be *optional cross-links*
> between those parameters. For performance reasons, these would obviously
> be implemented as Look-up-Table (LUT), with a suitable interpolation.
> These would implement a *function* of the input parameter and produce
> a *factor* applied to some output parameter. Lots of fine points to
> consider here, but overall doable and within our abilities and close
> to what the existing code already does right now.
> - Volume could be adjusted as function of MIDI note (my primary use case!)
> - Volume could be adjusted as function of channel pressure
> - Frequency could be adjusted as function of velocity
> - Cut-off could be adjusted as function of aftertouch
> ...
>
>* Needless to say: this is a very advanced feature and will just confuse
> most users. Yet people familiar with the fine points of sound design will
> understand it intuitively, because, in a way, its obvious you want to do
> that.
>
>* So there would be a full-control GUI in each Part. It's hidden behind a
>button
> and will bring up a matrix of knobs or graph widgets. For example, the input
> could be in the columns (note, volume, velocity, ctrl-1, ctrl-2). And in
> the rows, there would be the target parameters (frequency, gain,
> filter-freq,
> filter-q, what else...?). Each "point" in that correlation matrix would
> either
> be disabled, or a simple knob similar to velocity-sensing, or a graph widget
> with a bezier-curve, similar to the gamma or colour channels in Gimp.
> (Yes, I know, its messy to build such a beast, but it is well doable)
>
>* we have already some controls which effectively so something similar. They
> can be seamlessly translated into the new machinery. Notably, the velocity-
> sensing is already a function of volume based on velocity or filter gain
> based on velocity. I'd leave the familiar controls in place and just map
> them down into the new feature.
> Likewise, all existing cross-fades can seamlessly be translated into such
> a cross-correlation of parameters. Because they are just a function of
> velocity (or volume!) based on MIDI note value. But then an advanced
> user could go in and adjust and tweak the transition curve. Yikes!!
>
>What I'm proposing is bold, for sure. But IMHO it is not too bold: it is a
>generalisation of what we're doing already in some aspects; it would make
>handling those cases more symmetric. And what's more important, I expect
>that such a feature will unleash a lot of further possibilities present
>in Yoshimi's system of layered parts, because it's a generic component
>we'll build once and can then integrate into each part.
>
>Its also a lot of work, but -- as I've said in the introduction -- the
>proposal would be to proceed in small steps. Moreover, such a feature is
>certainly a bold bet that the zombie apocalypse would not happen right now
>and we'll all might have some further time left to build interesting stuff.
>
>-- Hermann
>
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
