purr-data issueshttps://git.purrdata.net/jwilkes/purr-data/-/issues2020-11-02T19:50:42Zhttps://git.purrdata.net/jwilkes/purr-data/-/issues/692Overhaul / cleanup of fluid~'s soundfont search, MIDI message interface2020-11-02T19:50:42ZAlbert GräfOverhaul / cleanup of fluid~'s soundfont search, MIDI message interfaceOur version of fluid~ is a plain C port of Frank Barknecht's [original version](https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid), which serves the basic purpose of interfacing to fluidsynth, but still has ...Our version of fluid~ is a plain C port of Frank Barknecht's [original version](https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid), 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](https://bitbucket.org/agraef/pd-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](https://bitbucket.org/agraef/pd-smmf/src/master/midi-input.pd) and [midi-output.pd](https://bitbucket.org/agraef/pd-smmf/src/master/midi-output.pd), available at https://bitbucket.org/agraef/pd-smmf).
- Last but not least, it is compatible with [pd-faust](https://agraef.github.io/pure-docs/pd-faust.html) and [pd-faustgen2](https://github.com/agraef/pd-faustgen) 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.2.15.1Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/690fluid~ broken (again) on Windows since 2.11.02022-08-03T14:48:28ZAlbert Gräffluid~ broken (again) on Windows since 2.11.0We've been through this before (cf. #540). This time it's a new dependency on libopus in libsndfile which we don't currently include in the Windows installer, and the fix is simply to include libopus (analogous to !300).We've been through this before (cf. #540). This time it's a new dependency on libopus in libsndfile which we don't currently include in the Windows installer, and the fix is simply to include libopus (analogous to !300).2.15.1Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/687iemgui dialogs are not capturing new hex colors correctly in their color pick...2020-09-25T20:33:57ZIvica Bukviciemgui dialogs are not capturing new hex colors correctly in their color pickers for bfl colorsThis is likely a regression since we adopted the new colors and is hopefully not a major one.This is likely a regression since we adopted the new colors and is hopefully not a major one.https://git.purrdata.net/jwilkes/purr-data/-/issues/645The bar graph array scalars inside a subpatch (topwindow) look like a flat li...2020-06-17T19:06:37ZIvica BukvicThe bar graph array scalars inside a subpatch (topwindow) look like a flat line out of which bars grow out of both up and down, rather than appearing from the bottom of the windowI will look into this eventually. I wonder though, if having Jonathan do this since the bargraph is his baby may be easier. Please also note the issue #643 that is also related to this bug but should be fixed globally for all plots in a ...I will look into this eventually. I wonder though, if having Jonathan do this since the bargraph is his baby may be easier. Please also note the issue #643 that is also related to this bug but should be fixed globally for all plots in a separate merge request.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/643When a GOP subpatch with an array or scalars is open, the array/scalars do no...2020-08-25T03:31:33ZIvica BukvicWhen a GOP subpatch with an array or scalars is open, the array/scalars do not scale across the entire window sizeIvica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/issues/640Improving scrollbar appearance2021-03-17T23:15:38ZIvica BukvicImproving scrollbar appearanceThe following css suggests an appearance that is more in line with the 1.x. I would further add the semitransparency to minimize occlusion of the content behind the scrollbars:
http://jsfiddle.net/6KprJ/1/The following css suggests an appearance that is more in line with the 1.x. I would further add the semitransparency to minimize occlusion of the content behind the scrollbars:
http://jsfiddle.net/6KprJ/1/