KVR Audio

It's still a bit tricky though, in that when pre-note PB 0 isn't sent, an (appropriate IMO) pre-note PB is still sent, but not from prepareNewNote (?) Also there's varying delay between the pre-note PBs and note on. There are lots of situational presumptions in the code that are hard to discern (as one might expect)

Nice work! I will try it when I have a chance. Are you happy with it?

shutterdownmax wrote: ↑Tue Apr 16, 2024 9:48 pm Nice work! I will try it when I have a chance. Are you happy with it?

Yup, so far so good.

I think the timing variances are with the MIDI monitor and not the device, checking now.

Hi Rich,

Jumping in here. To better understand your need, would you mind posting a brief video here that demonstrates the problem you're experiencing in your typical musical use case? This would allow me to hear the "yip" that you're hearing and therefore better understand the problem.

It would be helpful if could do the following when making your video:

1) Use one of the preset sounds in the Surge XT "LinnStrument MPE" library, so I can reproduce the same problem here, and know how much the synth's pitch slewing is affecting the "yip". A good sound to use is "Duduk" in the Winds folder.
2) Use MPE settings in both LinnStrument and Surge. This will allow me to learn if the "yip" may be related to a specific per-note channel's voice "yipping" from a previously stored bend amount.
3) Given that you are using different Bend Ranges in LinnStrument and the synth, please tell what values you're using for each.
4) Turn on Release On Release. You've said this is unrelated to the problem, but I'd prefer this in order to rule out the problem.

Thanks for bringing this to my attention,
Roger

Roger_Linn wrote: ↑Wed Apr 17, 2024 10:37 pm
Jumping in here. To better understand your need, would you mind posting a brief video here that demonstrates the problem you're experiencing in your typical musical use case? This would allow me to hear the "yip" that you're hearing and therefore better understand the problem.

Hi Roger,

Thanks very much for your attention. I can make a comparison video, but not until the weekend I think.

I don't know if you've had a chance to read the entire thread yet, but the problem is well understood and demonstrated in this post:

viewtopic.php?p=8873132#p8873132

and I've submitted a modification to the firmware which fixes the problem (while maintaining the current behavior exactly when in quantized mode), described here:

viewtopic.php?p=8887356#p8887356

Making a sound artifact reproducible isn't really the point, since there will be a wide variety of behaviors of sound sources, patches, and hosts, as well as varying abilities of musicians to discern the effect. I'd argue that logic dictates the Continuum behavior (sending a prefix PB message with the fingered/intended pitch, not 0) is similarly correct for the LinnStrument when in unquantized mode. This matters not just for yips/artifacts but for e.g. downstream processing scripts (of which I have many) that need to know the actual pitch when the Note On is sent, not later.

Again, thanks much for the LinnStrument and your fabulous support of it!

Rich

I'm happy to help, Rich. While I appreciate your technical analysis and MIDI output screenshots, I have trouble understanding what you mean by "yip". Usually it means a large pitch sweep resulting from a synth voice's retained bend value from previous use suddenly being reset to the new note's bend value, and the "yip" results from this sudden large change, made more noticeable by the common pitch smoothing in synths.

But in your unusual case of using mismatched bend ranges between LinnStrument and your synth in order to reduce the pitch change for a given finger movement, the sudden pitch change you describe can't be more than a half semitone at most. So I am having trouble understand how such a small pitch change could cause a "yip"

Making a video that demonstrates the problem, under the conditions I suggested and in the context of a typical musical use case in your musical playing style, will help me not only see and hear the problem you're experiencing, but also reproduce it here. This will allow me to better understand the musical problem and perhaps come up with a solution that doesn't create new problems with retained bend values related to MPE voice reuse.

Also, you mentioned a comparison video but no comparison is necessary, just the demonstration of the problem under the helpful conditions I mentioned.

Thanks in advance for your help.

Sorry for any confusion - the mismatched bend ranges are not relevant to this problem and can be disregarded. I was just providing context as to what I was doing when first tripping over this - seeking natural/imperfect onsets. In fact, the ratios I was using make the PB/position difference smaller (in cents) than when 1:1.

The problem manifests with 1:1 ranges, where, as you say, the maximum offset between the played position and the always-sent prefix PB 0 is 50 cents.

50 cents is certainly a perceptible change. The average vibrato width for cellists is ~30 cents. The just noticeable difference for pitch is ~5 cents.

VSL's sample players incorporate a 'humanize' function which introduces onset pitch variations to otherwise perfectly tuned samples, to keep sample-based performances from sounding too perfect and stiff. Notably the default bounds for onset variation are +/- 50 cents, with most settings being far less than that see 1:17 in this video

The LinnStrument should be able to deliver actual performed variations, but it can't if every note starts at offset 0.

The point is understood that retained bend values must be avoided - some prefix pitch bend must be sent before Note On or else you'll get whatever PB was last sent on the channel. But the prefix PB should not (IMO) be 0 when quantize is off, since it can instead reflect the new note's initial offset and thus the player's performance. That is what my patch does.

As promised, here is a video that both demonstrates the problem and contrasts it with the proposed fix:

EDIT: Video removed as the problem is (being) fixed!

Thanks again for your time and sorry for the hearing test

Hi Rich,

I think I wasn't clear enough in my description of the video I was asking for. When I asked for "a brief video that demonstrates the problem you're experiencing in your typical musical use case", I was not asking for a technical video essay using oscillator tones and MIDI graphs, but rather for you to briefly play a typical musical part in your musical style, thereby showing me how loud this "yip" is in a typical musical playing context, and meeting the conditions I asked for. For example, play a short melody as you would in your musical playing style, thereby allowing me to hear how loud this "yip" is. And I asked for you to use one of the Surge XT sounds so that I can reproduce it here. That shouldn't take more that a few minutes using a cell phone for the video.

My focus with LinnStrument is musical performance, so I like to know if a problem affects musical performance. If I can't reproduce a problem, I ask for a demonstration of the problem in typical musical use case. Given your description of the problem, it is difficult for me to understand how the "yip" would be audible, so I am simply asking to hear it-- to be able to reproduce it here--so that I will know that there is something to fix.

I feel this is important because your suggested fix-- not sending the zero pitch bend message before a Note On if Quantize is turned off-- will cause problems with retained MPE voice bend values. So I'd prefer not to implement a fix for a problem that can't be reproduced, has been noticed by only one person, and for which the fix causes other problems.

Also, I noticed from Geert's response that you posted a bug report on Github, which I didn't see because I don't watch Github postings. This is why the readme file in the repository states "Note that customer bug reports or feature requests should not be posted here. Instead, email Roger at support@rogerlinndesign.com."

Geert resolved the pull request by removing the duplicate pre-note pitchbend message in their latest commit to the firmware repository:

https://github.com/rogerlinndesign/linn ... ea14c0b9a5

Currently there is no tagged release containing it, so the repository will need to be cloned, then uploaded to the LinnStrument using Arduino IDE and/or the firmware updater to utilize the latest changes.

Great work! I had given up on microtonal playing because of this. Does that mean the change will be in the next official firmware version?

Yep.

Amazing, thanks Rich for bringing this up.