on that occasion, (but these are basics that I could also find out by reading the source code) -- what actually happens when e.g. I have a gain that is 80 and I send a value to it with amount 128? will it then go to 128, or somehow, larger? and when zending a 0, will it stay at 80 or go to 0?

Gain value of 80 is converted to float with x/128.0 so the gain is 0,625, and then if you send signal x to it with send amount 128, the resulting gain will be x+0.625 i.e. can very well go over 1. This has the implication that some units can create NaNs if a parameter is modulated and goes beyond the normal range.

The force-pushed version from last night seems to include a stab at the cache, great! But it does not seem to work yet? At least I don't see the send targets highlighting anymore.

If this was a draft version and just saving evening's work, you might consider keeping these WIPs in another branch, because I get notifications when there is a new version in the branch associated with pull-requests and I am a bit unsure if that's an invitation to rereview or merge, or just that you were finished for the night.

That being said: I think it's a good idea to put all the cache / derived data (whatever we call it) in one place (e.g., derived.go)! I can eventually throw updatePatternUseCount there too, because it is conceptually similar cache.

The only challenge with this approach is that we need to make sure that the caches are always regenerated correctly, but I don't see major bugs appearing even if these caches somehow manage to be out-of-date, as long as we use the caches just to display some helpful information in the GUI.

on that occasion, (but these are basics that I could also find out by reading the source code) -- what actually happens when e.g. I have a gain that is 80 and I send a value to it with amount 128? will it then go to 128, or somehow, larger? and when zending a 0, will it stay at 80 or go to 0?

Gain value of 80 is converted to float with x/128.0 so the gain is 0,625, and then if you send signal x to it with send amount 128, the resulting gain will be x+0.625 i.e. can very well go over 1. This has the implication that some units can create NaNs if a parameter is modulated and goes beyond the normal range.

Oh, that is interesting to know. Is that something were we would benefit if the UI is actually warning about such cases? (new issue?)

Gain value of 80 is converted to float with x/128.0 so the gain is 0,625, and then if you send signal x to it with send amount 128, the resulting gain will be x+0.625 i.e. can very well go over 1. This has the implication that some units can create NaNs if a parameter is modulated and goes beyond the normal range.

Oh, that is interesting to know. Is that something were we would benefit if the UI is actually warning about such cases? (new issue?)

It's very hard to give accurate error messages because there is no guarantee that the signal sent is actually within -1..1 (for example: a simple LFO oscillator has the gain parameter to adjust it so it could be -0.5..0.5). Also, many units are just fine having their params go beyond 0..1, it's just some that aint.

Bottomline: we already warn when there's NaN; that's when we know things have gone really bad; everything before that is "fine" and might be actually what the musician intended to do

Something is still off in the latest version:

Also, I managed to make the tracker crash:

...
C:/Users/sariola/go/pkg/mod/gioui.org@v0.7.1/op/clip/clip.go:105 +0x31
panic({0x7ff746319b40?, 0x7ff746287100?})
	C:/Program Files/Go/src/runtime/panic.go:785 +0x136
github.com/vsariola/sointu/tracker.(*Model).collectSendSources.func1(0xc003810ce0)
	c:/Users/sariola/git-repos/sointu/tracker/derived.go:214 +0x34e
slices.AppendSeq[...]({0x0, 0x0, 0x0}, 0xc002b24cb0)
	C:/Program Files/Go/src/slices/iter.go:50 +0x172
slices.Collect[...](0xc002b24cb0)
	C:/Program Files/Go/src/slices/iter.go:58 +0x47
...

The offending line:

unitParam := sointu.FindParamForModulationPort(unit.Type, port)
if unitParam.Name != paramName {
	continue
}

There is no check for unitParam being a nil pointer. In general, returning a struct and ok bool is better, because the user then realizes that (s)he needs to consider what happens when ok is false.

So,

func FindParamForModulationPort(unitName string, index int) (up UnitParameter, ok bool)

would have avoided this crash (there's again a heap escape in the return &param now, so would be better even)

In FindParamForModulationPort, the param.CanModulate is handled incorrectly, because it returns the stereo parameter (which has CanModulate false) if the index is 0.

Should be:

func FindParamForModulationPort(unitName string, index int) (UnitParameter, bool) {
	unitType, ok := UnitTypes[unitName]
	if !ok {
		return UnitParameter{}, false
	}
	for _, param := range unitType {
		if !param.CanModulate {
			continue
		}
		if index == 0 {
			return param, true
		}
		index--
	}
	return UnitParameter{}, false
}

You can see that when selecting envelope attack as the send target, it does not highlight:

LGTM, thanks! Merged, thank you for your contribution ❤️