@evaekblad If it is anything like an RPI you need to tell pins whether they should be inputs or outputs.
"AllInputs" sounds like it will never switch a pin to output..... but I have no idea.
This is in French unfortunately....... https://fr.flossmanuals.net/puredata/arduino-et-pd/
There is a link to a patch that will do what you want.
You will need StandardFirmata.
Maybe there is an English version somewhere, or you can use google translate.
It is quite simple.
David.

@ingox If you are looking for source code for any old extended externals they are all in https://sourceforge.net/projects/pure-data/files/pd-extended/0.43.4/Pd-extended_0.43.4-source.tar.bz2/download

Worth grabbing a copy while it remains available.
All the "makefile"s are included.
Useful for compiling externals for 64-bit (when they work).

I have seen the sort message almost hidden in a subpatch in 12-tut.pd in a tutorial on scalars here...... https://puredata.info/community/projects/convention04/lectures/tk-barknecht/tut.tgz

and it is mentioned (again... sort of.... with no explanation of the message call) as a function in Chapter 2.9.1 here...... http://puredata.info/docs/manuals/pd/x2.htm
and so it is also in Pd's \doc\1.manual\x2.htm

Zexy sort below. But it looks like the canvas sort is in g.graph.c.
There is an "if scalar sort" statement in there.
However g.graph.c has been disappeared from 0.49...... so......?
David.
.... sort.c.... (zexy)

In/* 
 *  sort :  sort a list of floats
 *
 * (c) 1999-2011 IOhannes m zmölnig, forum::für::umläute, institute of electronic music and acoustics (iem)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License along
 * with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

#include "zexy.h"

/* ------------------------- sort ------------------------------- */

/*
  SHELL SORT: simple and easy
*/

static t_class *sort_class;

typedef struct _sort
{
  t_object x_obj;

  int bufsize;
  t_float *buffer;
  t_int   *indices;

  int ascending;

  t_outlet*indexOut, *sortedOut;
} t_sort;


static void sort_dir(t_sort *x, t_float f)
{
  x->ascending = (f < 0.f)?0:1;
}

static void sort_buffer(t_sort *x, int argc, t_atom *argv)
{
  int n = argc;
  t_float *buf;
  t_atom *atombuf = argv;

  if (argc != x->bufsize) {
    if (x->buffer) freebytes(x->buffer,  x->bufsize * sizeof(t_float));
    if (x->indices)freebytes(x->indices, x->bufsize * sizeof(t_int));

    x->bufsize = argc;
    x->buffer = getbytes(x->bufsize * sizeof(t_float));
    x->indices = getbytes(x->bufsize * sizeof(t_int));
  }

  buf = x->buffer;
  while (n--){
    *buf++ = atom_getfloat(atombuf++);
    x->indices[n] = n;
  }
}

static void sort_list(t_sort *x, t_symbol *s, int argc, t_atom *argv)
{
  int step = argc, n;
  t_atom *atombuf = (t_atom *)getbytes(sizeof(t_atom) * argc);
  t_float *buf;
  t_int   *idx;

  int i, loops = 1;

  sort_buffer(x, argc, argv);
  buf = x->buffer;
  idx = x->indices;

  while (step > 1) {
    step = (step % 2)?(step+1)/2:step/2;

    i = loops;
    loops += 2;

    while(i--) { /* there might be some optimization in here */
      for (n=0; n<(argc-step); n++) {
        if (buf[n] > buf[n+step]) {
          t_int   i_tmp = idx[n];
          t_float f_tmp = buf[n];
          buf[n]        = buf[n+step];
          buf[n+step]   = f_tmp;
          idx[n]        = idx[n+step];
          idx[n+step]   = i_tmp;
        }
      }
    }
  }

  if (x->ascending) 
    for (n = 0; n < argc; n++) SETFLOAT(&atombuf[n], idx[n]);
  else
    for (n = 0, i=argc-1; n < argc; n++, i--) SETFLOAT(&atombuf[n], idx[i]);

  outlet_list(x->indexOut , gensym("list"), n, atombuf);

  if (x->ascending) 
    for (n = 0; n < argc; n++) SETFLOAT(&atombuf[n], buf[n]);
  else
    for (n = 0, i=argc-1; n < argc; n++, i--) SETFLOAT(&atombuf[n], buf[i]);
  outlet_list(x->sortedOut, gensym("list"), n, atombuf);


  freebytes(atombuf, argc*sizeof(t_atom));
}

static void *sort_new(t_floatarg f)
{
  t_sort *x = (t_sort *)pd_new(sort_class);
  x->ascending = (f < 0.f)?0:1;

  x->sortedOut=outlet_new(&x->x_obj, gensym("list"));
  x->indexOut=outlet_new(&x->x_obj, gensym("list"));

  x->bufsize = 0;
  x->buffer = NULL;

  inlet_new(&x->x_obj, &x->x_obj.ob_pd, gensym("float"), gensym("direction"));

  return (x);
}

static void sort_help(t_sort*x)
{
  post("\n%c sort\t\t:: sort a list of numbers", HEARTSYMBOL);
}
void sort_setup(void)
{
  sort_class = class_new(gensym("sort"), (t_newmethod)sort_new, 
                         0, sizeof(t_sort), 0, A_DEFFLOAT,  0);
  
  class_addlist    (sort_class, sort_list);
  class_addmethod   (sort_class, (t_method)sort_dir, gensym("direction"), A_DEFFLOAT, 0);
  class_addmethod(sort_class, (t_method)sort_help, gensym("help"), A_NULL);

  zexy_register("sort");
}
`

@microgramme_crk You could try reversing the connections to the outlets of [t f f]
That might fix the "small leap"....... unsure how the synth is reacting to the order of midi.
The two messages really need to arrive at the same time..... and of course that is not achievable.

My patch did not output every single "fine" value.
So, if you change the grain of [line]...... put [line 0 1] instead then you should get every decimal value of "fine" even at fairly fast change speeds.
You might saturate the midi though. Depending on how fast the changes are...... 1000, 2000, 6000.... change to [line 0 2] or [line 0 20] ....... as large a second argument as possible that will still output every fine value as it sweeps.
Put a print on the "fine" outlet to see whether every number in a series is sent.

You can also put [change] before [ctlout 89] which will reduce the coarse updates.... but that might not be acceptable for the synth.
David.

@microgramme_crk Maybe..........
Change the 2000 in [$1 2000] to make the smoothed reaction faster or slower.
I imagine "fine" goes from -50 cents to + 50 cents for its 0-99 range.... so........
was2.pd
David.

@leech If you reduce the dynamic range of the spectrogram, or increase the resolution, or both, you can get it to show a line at 80Hz.
40dB and about 16384 bins should give you a red line with standard colours.
Although a sine wave has a constant frequency the rate of change of amplitude varies over the cycle.
Windowing functions are used with FFTs. These transform the signal block-by-block into a spectral representation whose resolution (accuracy) in both the frequency and time domains are proportional to their size.
Unless the window "width" ...... time....... matches the width of a cycle or cycles of the sine wave you will get spectral leakage.
http://download.ni.com/evaluation/pxi/Understanding FFTs and Windowing.pdf
David.

@cfry It had worked in the past (32-bit extended +RPI2B + wiringPI) and can probably work now (vanilla + comport / python).
It is complicated by the variables introduced.
Bits.... 32/64
Pd versions and available externals.
RPI versions and OS choices.

For example wiringPI was broken for 64-bit RPI3 last year, but is maybe working again now?
I am controlling my gpio pins directly on RPI3 with direct messages now (not in Pd but it is probably possible)....... like.....
os.execute("gpio write 25 0");

where "os" is in the standard lua library.
I am still a Linux noob....!
I have a startup file that sets the pins as I want them.......

#! /bin/bash 
gpio mode 17 output
gpio mode 27 output
gpio mode 18 output
gpio mode 22 output
gpio write 22 1
gpio mode 23 output
gpio write 23 1
gpio mode 25 output
gpio write 25 1
gpio mode 24 output
gpio write 24 1
exit 0

And I understand that Pd can do this through [shell] but I don't know which library that is in......?
For reading the pins...... Adafruit retro games...... https://forum.pdpatchrepo.info/topic/11564/how-to-use-disis_gpio-for-rpi-button-input-alternatives/3
David.

@cfry Also....... 50cents for 6 buttons....... because...... how long can you bounce my dear switch?
https://hackaday.com/2015/12/09/embed-with-elliot-debounce-your-noisy-buttons-part-i/
David.

@Joseph-Mikkelson No, changing the samplerate will not help, except that matching it to the soundcard reduces the load on the cpu......but there are more important issues...... see below.....

I should have expanded on latency.
Using a live input [adc~] and doing some Pd processing effects and then sending that to speakers [dac~] latency is not so much of a problem. Often it involves delays anyway (echo, reverb, etc.) and our ears are used to that.
Latency for playback of an audio track, or generated audio, is no problem...... it is heard when it arrives at the speakers and that is all.
Problems arise when the input goes straight to the output....... as with a monitor mixer built in Pd for example..... with live acoustic instruments...... where the musician hears their own instrument acoustically and the same sound delayed in the monitor. Essentially a chorus effect is produced, caused by the latency, and that will make it harder for a violinist for example to pitch correctly.
Chorus in a reverb effect really upsets violinists..... anything much over 5ms.
Of course a massive latency...... 100ms+..... will cause timing problems even for a guitarist, and even if they are the rare musician that didn't have such issues in the first place.
I have met classical and jazz musicians that have learnt to dissociate what they play from what they hear...... for example playing through a delay, but in sync with everyone else...... so playing say 1 second before everyone else....... but......

SAMPLE RATE
You should match your samplerate to your soundcard, or you will have re-sampling artefacts....... usually a low level high pitched whine when your patch is not producing any sound.
It is slightly more complicated than that.
If you play an audio file that was recorded at 44.1KHz while the Pd samplerate is set to 48KHz it will play back at the wrong speed....... Pd will not resample it and so the pitch will be wrong.
It's a PITA.
So the Pd samplerate must be set to match all the audio files that you use in Pd.
To avoid the artefacts you then need to set your soundcard to match Pd.
Other programs will adjust..... so that is not a problem.
External cards can make that change through their control panel, and internal cards should have the option somewhere.
In windows it is here in the speaker control panel..... https://forum.pdpatchrepo.info/topic/12094/newbie-clipping-on-pure-data-portable-with-mmio/4
and I am pretty sure that windows always sets the on-board soundcard to 48KHz "out of the box".
David.

@Joseph-Mikkelson In that case try relaxing the audio by increasing the "Delay (msec):" in the Pd .... Media.... Audio Settings.
Those are the exact symptoms of too small an audio buffer.
For a computer in-built sound card "30" and above should be fine..... I have mine set to "80" for everyday use.... to be safe.
That causes increased latency, by increasing the buffer size so that more can be done by the computer between it collecting the lumps of audio from Pd. At the moment your computer is interrupting the audio to do other things.
Latency (for the sound card) only matters if you are using the audio in a "live" situation where delay would be upsetting for a musician. You would need a professional outboard soundcard in that case.
If that doesn't work then let us know more about your computer, operating system, and sound card.

If you are doing important audio and video work on your computer then read "GlitchFree" here.....
https://forum.pdpatchrepo.info/topic/10125/audio-and-video-why-do-i-have-problems
Bluetooth and Wi-Fi drivers can be particularly problematic.
David.