Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map GS NPRN Params to CC numbers #1420

Open
spessasus opened this issue Nov 5, 2024 Discussed in #1406 · 0 comments
Open

Map GS NPRN Params to CC numbers #1420

spessasus opened this issue Nov 5, 2024 Discussed in #1406 · 0 comments

Comments

@spessasus
Copy link
Contributor

Discussed in #1406

Originally posted by spessasus October 13, 2024

The problem

Currently, there's no way to make fluidsynth react to GS NPRNs.

For example, take a listen to this MIDI file being played on a GS device. At around 18 seconds in, the trumpets can be heard with clear vibrato. Playing it on fluidsynth even with stgiga's HiDef (the SC-88Pro soundfont) does not result in any vibrato.

And that's fine, fluidsynth is not said to be GS compatible.

But, even as a soundfont creator, I can't make it GS compatible with modulators. You see, modulators only support CCs as sources, not NPRNs. This is why I propose the following:

The solution

In this SC8850 owner's manual you can see the CC numbers on page 227 and the correspoding NPRNs on page 228.

It would be great if fluidsynth mapped those NPRNs to their respective controllers. That is:

  • NPRN 01H 08H to CC 76 (vibrato rate)
  • NPRN 01H 09H to CC 77 (vibrato depth)
  • NPRN 01H 0AH to CC 78 (vibrato delay)

note: numbers with "H" at the end indicate hex

And by mapping i mean directly copying the data entry value to the CC:

  • received an NRPN LSB: 01H
  • received an NRPN MSB: 08H (this is vibrato rate)
  • received a data entry MSB: 10H: this is effectively interpreted as CC change: CC 76 is set to 10H

**Note: this would only apply if the synth is in the gs bank select mode (I.E. after receiving a GS sysex)

Rationale

  • does not mess up other systems (the change only applies after a GS sysEx)
  • does not add any default modulators or anything like that
  • allows the soundfont creators to implement support for the said GS NRPNs
  • does not break any existing soundfonts

What do you think?

derselbst agreed to give it a try, hence I'm opening an issue here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant