On Tue, 21 Jan 2025 11:52:30 +0100
Kristian Amlie <krist...@amlie.name> wrote:
>On 17.01.2025 23:32, ichthyo wrote:
>> On 13.01.25 09:33, Kristian Amlie wrote:
>>> But I have one "side question": Does you suggestion relate at all to
>>> crossfades
>>> between kit items? We had a discussion there a while back about how
>>> the cross
>>> fades are happening by fading velocity up and down for the two
>>> crossfaded parts,
>>> but it should really be fading the volume. I've been meaning to look
>>> at fixing
>>> this, but it's not entirely trivial and I got a bit side tracked from
>>> that project.
>>
>> Yes indeed, this is spot on.
>>
>> To recall the whole story why I'd like to engage into this project:
>> I am looking for ways to help with "fine-tuning and voicing" of a patch or
>> instrument, in a similar way how you'd do that for a physical instrument.
>>
>> An organ stop is a good example. If you'd just build an array of pipes,
>> these would not work well together in a musical way. If you'd hit a chord,
>> the individual tones would not sound balanced. And if you'd be playing
>> some arpeggio or runs, it would not "run well".
>>
>> These are the very problems we often encounter with synth sounds.
>> You create an interesting spectrum, but then you'll notice that it does
>> not work well in a score. Sometimes you'd get a much to drastic change
>> of tone within a single octave.
>>
>>
>> Anyway, we all know these kind of problems, and we've found ways to work
>> around
>> them. Which, however, often tend to be limiting in other ways, and at
>> the very
>> least are often quite labour intensive.
>>
>> A cross fade based on volume, not velocity, would be indeed just another
>> tool
>> in the toolbox, that could be used to handle such a "tuning and voicing".
>> Another solution would be to introduce a new, single top-level control,
>> which
>> allows to make an automatic adjustment of the note volume based on the
>> MIDI note.
>>
>> At this point for me the most relevant question is "how far can and
>> should we
>> go with implementing such a new feature"?
>> * if we are overly timid, we create yet-another-not-so-useful special
>> feature
>> * if we approach it in a excessively broad way, we might degrade
>> performance,
>> or create a maintenance problem in the code base, and the feature might
>> be too abstract to grasp, at least for people without technical
>> background.
>>
>> That is the reason why I'm proposing to handle this as a "project",
>> progressing
>> in several steps. bottom-ip. And then, the secondary issue with a per-key
>> aftertouch was just the final idea that also hinted into a similar
>> direction.
>>
>> Thus I want to start out from a very abstract notion, which is that of a
>> "cross linking" between control channels. And my proposal was to first
>> find out about the reality in the code base, to look into possible issues
>> and to conduct a thorough performance investigation. If that goes well,
>> we'd create a base platform for several new features. And we could then
>> hopefully take the time to discuss how to actually provide those features,
>> and to what degree.
>>
>> And yes, a cross fade based on volume would just be a special case, that
>> could be implemented on top of that base feature. Because this base feature
>> would foremost require to transport a small record of per-note-settings to
>> some parts of the engine, which right now are invoked as simple functions.
>
>This is a good idea, but I think it's not the right tool for this
>particular job. It's possible to implement crossfading by say, having
>inverse volume responses to the note scale, but this would be a very
>cumbersome way to do it. And quite prone to mistakes also. You always
>have to keep the two endpoints "in sync" if you change the crossover
>point. Which you would probably do a lot while fine tuning the
>instrument. This gets even worse if you have multiple crossover points.
>
>On the other hand, my proposal is extremely simple from the user
>perspective: Just add one more entry to the Kit Edit Mode: "Crossfade
>(volume)", and rename the existing "Crossfade" to "Crossfade (velocity)"
>to make the distinction clear. The fact that it's slightly more than
>trivial (and only slightly!) to implement this is a technical detail, I
>don't think this should factor in too much.
>
>I think those two features could happily coexist, and one would use them
>for different tasks.
This is along the lines I was thinking off, and I slightly modified the current
crossfade to make this a bit easier. It needs an extra parameter added to the
note object, but I tested that with a couple of unused additional parameters
(removed them after the test) and didn't notice any difference in performance.
--
Will J Godfrey {apparently now an 'elderly'}
.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
