Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
P
purr-data
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 399
    • Issues 399
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 40
    • Merge Requests 40
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Jonathan Wilkes
  • purr-data
  • Issues
  • #692

Closed
Open
Created Oct 07, 2020 by Albert Gräf@aggraefDeveloper

Overhaul / cleanup of fluid~'s soundfont search, MIDI message interface

Our version of fluid~ is a plain C port of Frank Barknecht's original version, which serves the basic purpose of interfacing to fluidsynth, but still has some annoying usability issues which should be easy to fix:

  • fluid~ doesn't search for the soundfont file in the directory of the patch and the Pd search path, which makes it really cumbersome to use, because soundfonts need to be specified using absolute paths.

  • fluid~'s interface for passing MIDI messages doesn't cover all MIDI messages, and has the arguments in the wrong order (in particular, the MIDI channel comes first, causing issues with Pd's MIDI input objects which have them on the rightmost outlet). We should replace this with something more comprehensive such as my own SMMF a.k.a. "Simple MIDI Message Format".

SMMF offers the following advantages over the ad-hoc message interface that fluid~ currently uses:

  • It covers all MIDI voice messages, as well as system exclusive and the most important system realtime messages. (Note that sysex support is particularly interesting in the context of fluidsynth because it allows to pass octave-based temperaments using sysex messages following the MIDI Tuning Standard (MTS), which fluidsynth readily supports.)

  • It enforces a close 1-1 correspondence between the Pd MIDI objects and the message format (it uses the same basenames as message selectors, and has the arguments in the right order to easily interface with the Pd MIDI objects).

  • It is is readily supported by some helper abstractions (midi-input.pd and midi-output.pd, available at https://bitbucket.org/agraef/pd-smmf).

  • Last but not least, it is compatible with pd-faust and pd-faustgen2 which makes it very easy to integrate Faust- and soundfont-based synthesis in Pd.

I think that both issues should be rather easy to fix (MR is in the works), and that this will improve the usability of this important external a lot. I will also make an attempt to preserve the old message interface as much as possible, so that most existing patches using fluid~ should continue to work without too much fiddling.

Edited Oct 07, 2020 by Albert Gräf
Assignee
Assign to
2.15.1
Milestone
2.15.1
Assign milestone
Time tracking
None
Due date
None