@mkdewolf I recommend you take a step by step approach from the bottom up rather than from the top down because the first way you only have to learn one small thing at a time whereas the second way you have to learn many things at once. If you approach it this way then if something goes wrong at one of those small steps, you can just examine the few things you added or changed to find where the problem is.

Start by simply controlling [phasor~] with a frequency slider. Put a number display box between your slider and the phasor so you can see what's going on. You will immediately notice that frequency is different than pitch, and that a frequency of 10 sounds more like a beat than a tone. Next you could look for a way to convert a pitch number (i.e. MIDI) to a frequency. @nicnut suggested something you could use. Next take a look at that tutorial I suggested in your other topic, A02.amplitude.pd. The key insight here is that you can make the note turn on by taking the volume from 0 to some positive value, and the positive value it ends up on represents velocity. Conversely, you can make the note turn off by turning the volume back down to 0. The timing between when the note turns on and when it turns off is your duration, so you would next need a way to automate that. A delay from when the note turns on is one possibility, but you've already discovered [makenote], so that's another way. @nicnut's suggestion, setting the frequency to 0 after some delay, is another possibility for note off but I'd bet that it has side effects you wouldn't like. (Or maybe you would--that's up to you!)

Even if you do all these steps, the result will still be pretty crude, but you can continue refining one bit at a time and get closer and closer to something good at each step. You can get ideas about how to refine your patch by looking at some of the other tutorials, e.g. C10.monophonic.synth.pd and J08.classicsynth.pd. Once you have something that you like well enough, then you can add note-velocity-duration sequences (maybe using [text] as @whale-av suggested in your other topic), and finally, you can work on generating sequences that are serialized.

PS: if you're really only interested in serialization (and don't really care about making a synth from scratch) then there are other options available to you. Reply if so and then I or someone else can suggest alternatives.

@Zooquest You will hear clicks because there will be jumps between samples.... if the playback was at a sample level of 0 and you change the delay time to a point where the level is 1 then the click will be loud.
You will hear "steps" as the playback point is probably being changed repeatedly by the ctrl messages.

You could experiment with a [lop~] filter in the delayed sound output, with a high value e.g... [lop~ 5000] but you will lose some high frequencies in the echo.
That might sound natural though, like an old tape echo, but you will probably still hear the clicks a little.

Or you could "duck" the echoes by not changing the delay time immediately, reducing the echo volume to zero in say 3msecs using using [vline~] and not bringing the echo volume back up to 1 (in, say, 3msecs again) until you have NOT received a ctrl message to change the delay time...... for again 3msecs.
The last part of that would need a [delay 3] using the property that any new bang arriving at its inlet will cancel the previously scheduled bang.

You would need to duck the FB signal as well though, and all that that might sound worse than the [lop~].

I cannot remember well...... but this "sampler_1.pd" might contain elements useful to demonstrate "ducking" https://forum.pdpatchrepo.info/topic/13641/best-way-to-avoid-clicks-tabread4/12

Or do a crossfade between separate delays once the incoming control messages have stopped..... https://forum.pdpatchrepo.info/topic/12357/smooth-delay-line-change-without-artifacts ..... as you can then avoid the "duck"ing effect.
David.

@oid I was assuming that you thought of analogue ladder filter design a la Moog when you suggested the feedback path to get the resonance. And since analog feedback is basically delayless (which in digital land is of course impossibe), I suggested to make the delay as short as possible.

But there's one thing, that I forgot to consider: The whole magic of the Moog filter only works with four one-pole filters in series! I can't remeber how exactly, but it has to do with the phase response of each one-pole filter and the sum of the phase shifts corresponding to the resonant frequency.

So if you care about controlling the frequency of the resonance, it seem to be necessary to implement the 8-pole filter as two resonant 4-pole filters in series. Of course, this is still a very crude approximation ...

lop8_2x4.pd

hi everyone!

I'm trying to run the patch "Ambisonic_2d_example.pd" from the iem_ambi external. While trying to get it to run, I made some changes to the declare statement. You can find the code below..

I installed the externals needed for this patch through deken and I also set the "-lib iemlib" startup flag in PD.

Unfortunately I get the following errors. As you can see PD fails to create some objects (e.g. fadtodb, rbpq, mull~, dsp). These objects seem to all come from the iemlib which is loaded successfully. I have also checked the /externals/iemlib directory.. the four mentioned object-patches are there.

I am running PD on a VM running Debian 11.7 on a M1 MacBook Pro.

I have been trying to solve this for a couple of hours now.. Does anyone know why it's not working?

iemlib (1.22-1) library loaded!   (c) Thomas Musil Jul  7 2023 : 18:09:42
   musil@iem.at iem KUG Graz Austria
iem_ambi (1.21.1) library loaded!   (c) Thomas Musil Jul 18 2023 : 11:42:00
   musil@iem.at iem KUG Graz Austria

iemmatrix 0.3.3
    objects for manipulating 2d-matrices
    (c) 2001-2015 iem
        IOhannes m zmölnig
        Thomas Musil
        Franz Zotter
    compiled Jul 18 2023 : 22:25:45

iemlib (1.22-1) library loaded!   (c) Thomas Musil Jul  7 2023 : 18:09:42
   musil@iem.at iem KUG Graz Austria

    ♡♡♡
    ♡ the zexy external  2.4.2
    ♡ (c) 1999-2023 IOhannes m zmölnig
    ♡       forum::für::umläute
    ♡       iem  @  kug
    ♡  compiled  Jul  7 2023
    ♡ send me a 'help' message
    ♡♡♡

matchbox: OSC-pattern matching code (c) Matt Wright, CNMAT
iemgui (1.21-1) library loaded!   (c) Thomas Musil Sep 13 2022 : 19:34:09
   musil@iem.at iem KUG Graz Austria
 dsp
... couldn't create
 rbpq2~ 1000 2 100
... couldn't create
 mull~ 1 100
... couldn't create
 fadtodb
... couldn't create
matrix_inverse nonsingular

modified_Ambisonic_2d_example.pd:

#N canvas 1512 175 1512 1715 10;
#X declare -stdlib /home/amir/Documents/Pd/externals/iem_ambi -stdlib
/home/amir/Documents/Pd/externals/iemmatrix -stdlib /home/amir/Documents/Pd/externals/iemlib
-stdlib /home/amir/Documents/Pd/externals/zexy -stdlib /home/amir/Documents/Pd/externals/iemgui
;
#X obj 20 44 dsp;
#X obj 20 24 tgl 15 0 empty empty empty 0 -6 0 8 -260818 -1 -1 0 1
;
#X floatatom 20 83 5 0 0 0 - - -;
#X floatatom 33 65 5 0 0 0 - - -;
#X obj 230 88 ambi_encode 2;
#X obj 469 102 mtx_*~ 5 1 100;
#X obj 509 11 noise~;
#X obj 509 32 rbpq2~ 1000 2 100;
#X obj 225 591 mtx_print;
#X obj 230 140 mtx 5 1;
#X msg 230 51 col 1 \$1;
#X obj 230 109 t b a;
#X obj 699 118 prvu~;
#X obj 700 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 719 118 prvu~;
#X obj 720 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 739 118 prvu~;
#X obj 740 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 759 118 prvu~;
#X obj 760 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 779 118 prvu~;
#X obj 780 142 vu 15 120 empty empty -1 -8 0 8 -66577 -1 1 0;
#X obj 115 222 loadbang;
#X obj 442 257 mtx_*~ 2 2 100;
#X obj 537 257 mtx_*~ 2 2 100;
#X obj 233 240 ambi_rot 2;
#X obj 699 273 prvu~;
#X obj 700 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 719 273 prvu~;
#X obj 720 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 739 273 prvu~;
#X obj 740 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 759 273 prvu~;
#X obj 760 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 0 0;
#X obj 779 273 prvu~;
#X obj 780 297 vu 15 120 empty empty -1 -8 0 8 -66577 -1 1 0;
#X obj 411 257 *~ 1;
#X obj 131 436 round_zero 1e-06;
#X msg 147 343 real_ls \$1 \$2;
#X msg 131 364 begin_pseudo_inverse;
#X msg 115 385 end_pseudo_inverse;
#X obj 115 245 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 131 414 ambi_decode3 2 2 8 0;
#X msg 147 322 1 0 \, 2 45 \, 3 90 \, 4 135 \, 5 180 \, 6 225 \, 7
270 \, 8 315;
#X obj 425 381 mtx_*~ 8 5 0 ________________;
#X obj 115 264 t b b b b;
#X obj 508 75 mull~ 1 100;
#X obj 678 27 fadtodb;
#X obj 551 55 dbtorms;
#X obj 618 58 - 100;
#X obj 618 82 vsl 15 121 0 120 0 1 empty empty empty 0 -8 0 8 -260818
-1 -1 24000 1;
#X floatatom 637 80 5 0 0 0 - - -;
#N canvas 0 0 462 312 __________________________ 0;
#X obj 25 66 rvu~;
#X obj 25 86 + 100;
#X obj 25 106 dbtorms;
#X obj 25 127 outlet;
#X obj 75 66 rvu~;
#X obj 75 86 + 100;
#X obj 75 106 dbtorms;
#X obj 75 127 outlet;
#X obj 125 66 rvu~;
#X obj 125 86 + 100;
#X obj 125 106 dbtorms;
#X obj 125 127 outlet;
#X obj 175 66 rvu~;
#X obj 175 86 + 100;
#X obj 175 106 dbtorms;
#X obj 175 127 outlet;
#X obj 225 66 rvu~;
#X obj 225 86 + 100;
#X obj 225 106 dbtorms;
#X obj 225 127 outlet;
#X obj 275 66 rvu~;
#X obj 275 86 + 100;
#X obj 275 106 dbtorms;
#X obj 275 127 outlet;
#X obj 325 66 rvu~;
#X obj 325 86 + 100;
#X obj 325 106 dbtorms;
#X obj 325 127 outlet;
#X obj 375 66 rvu~;
#X obj 375 86 + 100;
#X obj 375 106 dbtorms;
#X obj 375 127 outlet;
#X obj 25 45 inlet~;
#X obj 75 45 inlet~;
#X obj 125 45 inlet~;
#X obj 175 45 inlet~;
#X obj 225 45 inlet~;
#X obj 275 45 inlet~;
#X obj 325 45 inlet~;
#X obj 375 46 inlet~;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 14 0 15 0;
#X connect 16 0 17 0;
#X connect 17 0 18 0;
#X connect 18 0 19 0;
#X connect 20 0 21 0;
#X connect 21 0 22 0;
#X connect 22 0 23 0;
#X connect 24 0 25 0;
#X connect 25 0 26 0;
#X connect 26 0 27 0;
#X connect 28 0 29 0;
#X connect 29 0 30 0;
#X connect 30 0 31 0;
#X connect 32 0 0 0;
#X connect 33 0 4 0;
#X connect 34 0 8 0;
#X connect 35 0 12 0;
#X connect 36 0 16 0;
#X connect 37 0 20 0;
#X connect 38 0 24 0;
#X connect 39 0 28 0;
#X restore 425 406 pd __________________________;
#X obj 459 490 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 486 460 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 486 528 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 516 450 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 516 538 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 546 460 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 546 528 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X obj 573 490 vsl 15 51 0 0.2 0 0 empty empty empty 0 -8 0 8 -1 -24198
-1 0 1;
#X msg 310 58 ambi_weight 1 1 1;
#X msg 164 299 ambi_weight 1 1 0.3904;
#X msg 89 466 ambi_weight 1 1 1;
#X text 388 509 +90 degree;
#X text 601 506 -90 degree;
#X text 486 602 +-180 degree;
#X obj 234 220 cnv 12 30 12 empty empty empty 20 12 0 14 -260818 -66577
0;
#X obj 231 32 cnv 12 30 12 empty empty empty 20 12 0 14 -260818 -66577
0;
#X floatatom 230 31 5 -180 180 0 - - -;
#X text 232 14 phi;
#X floatatom 233 219 5 -180 180 0 - - -;
#X text 231 201 rho_z;
#X obj 264 213 cnv 8 8 8 empty empty empty 20 12 0 14 -262144 -66577
0;
#X obj 260 24 cnv 8 8 8 empty empty empty 20 12 0 14 -262144 -66577
0;
#X text 341 114 ENCODING;
#X text 309 378 DECODING;
#X text 323 257 ROTATING;
#X text 587 90 gain;
#X text 24 119 iemmatrix \, iem_ambi \, iemgui;
#X text 17 108 we need iemlib1 \, iemlib2 \,;
#X text 78 596 IEM KUG;
#X text 62 584 musil;
#X text 92 584 @;
#X text 98 584 iem.at;
#X text 61 606 Graz \, Austria;
#X text 13 573 (c) Thomas Musil 2000 - 2006;
#X obj 182 647 declare -stdlib /home/amir/Documents/Pd/externals/iem_ambi
-stdlib /home/amir/Documents/Pd/externals/iemmatrix -stdlib /home/amir/Documents/Pd/externals/iemlib
-stdlib /home/amir/Documents/Pd/externals/zexy -stdlib /home/amir/Documents/Pd/externals/iemgui
;
#X connect 0 0 2 0;
#X connect 0 1 3 0;
#X connect 1 0 0 0;
#X connect 4 0 11 0;
#X connect 5 0 12 0;
#X connect 5 0 36 0;
#X connect 5 1 14 0;
#X connect 5 1 23 1;
#X connect 5 2 16 0;
#X connect 5 2 23 2;
#X connect 5 3 18 0;
#X connect 5 3 24 1;
#X connect 5 4 20 0;
#X connect 5 4 24 2;
#X connect 6 0 7 0;
#X connect 7 0 46 0;
#X connect 9 0 5 0;
#X connect 10 0 4 0;
#X connect 11 0 9 0;
#X connect 11 1 9 0;
#X connect 12 0 13 0;
#X connect 14 0 15 0;
#X connect 16 0 17 0;
#X connect 18 0 19 0;
#X connect 20 0 21 0;
#X connect 22 0 41 0;
#X connect 23 0 28 0;
#X connect 23 0 44 2;
#X connect 23 1 30 0;
#X connect 23 1 44 3;
#X connect 24 0 32 0;
#X connect 24 0 44 4;
#X connect 24 1 34 0;
#X connect 24 1 44 5;
#X connect 25 0 23 0;
#X connect 25 1 24 0;
#X connect 26 0 27 0;
#X connect 28 0 29 0;
#X connect 30 0 31 0;
#X connect 32 0 33 0;
#X connect 34 0 35 0;
#X connect 36 0 26 0;
#X connect 36 0 44 1;
#X connect 37 0 44 0;
#X connect 38 0 42 0;
#X connect 39 0 42 0;
#X connect 40 0 42 0;
#X connect 41 0 45 0;
#X connect 42 0 37 0;
#X connect 43 0 38 0;
#X connect 44 0 52 0;
#X connect 44 1 52 1;
#X connect 44 2 52 2;
#X connect 44 3 52 3;
#X connect 44 4 52 4;
#X connect 44 5 52 5;
#X connect 44 6 52 6;
#X connect 44 7 52 7;
#X connect 45 0 40 0;
#X connect 45 1 39 0;
#X connect 45 2 43 0;
#X connect 45 3 62 0;
#X connect 46 0 5 1;
#X connect 47 0 48 0;
#X connect 47 0 49 0;
#X connect 48 0 46 1;
#X connect 49 0 51 0;
#X connect 50 0 47 0;
#X connect 52 0 56 0;
#X connect 52 1 54 0;
#X connect 52 2 53 0;
#X connect 52 3 55 0;
#X connect 52 4 57 0;
#X connect 52 5 59 0;
#X connect 52 6 60 0;
#X connect 52 7 58 0;
#X connect 61 0 4 0;
#X connect 62 0 42 0;
#X connect 63 0 42 0;
#X connect 69 0 10 0;
#X connect 71 0 25 0;

Hey all,

I am integrating a Pd patch with an existing sequencer/looper (Seq192) with an OSC interface, where my patch should convert my MIDI controller's button presses to OSC commands and send back MIDI signal out to lighten the controller's LEDs.
I can retrieve periodically the status and details of all clips/sequences and aggregate it into a list of parameters for each sequence. The LED colors and the actions that the next button press will trigger depend on these parameters, so I need to store them for reuse, which I like doing with [text] objects. I am then handling buttons' light status in a [clone 90] (where each instance of the clone handles one button).

This should be running on a fairly low-end laptop, so I'm wondering which of these approaches is the most CPU-efficient - if there is any significant difference at all - and I couldn't come up with a way to properly measure the performance difference:

1. one [text define $1-seq-status] object in each clone, with one single line in each. I compare the new sequence status input with [text get $1-seq-status 0] so that I update only line 0 with [text set $1-seq-status] when I know that the content has changed.
2. one single [text define all-seq-status] object with 91 lines. I compare the new sequence status with

[ <button number> (
|
[text search all-seq-status 0]
|
[sel -1]
       |
       [text get all-seq-status]

and if it has changed, I update a button's line with

[ <new status content> (
|
|      [ <line number> (
|      |
[text set all-seq-status]

The order in which buttons/sequence statuses are listed in the file might change, so I can't really avoid searching at least once per button to update.

3. Should I instead uses simple lists in each clone instance? As far as I could test, getting a value from a list was a bit slower than getting a value from a text, but searching in a text was much slower than both. But I don't know the impact of processing 91 lists or text at the same time...

TL;DR: Is it more efficient to [text search], [text get] and [text set] 91 times in one [text] object, or to [text get] and [text set] 1 time in each of 91 [text] objects? or in 91 [list] objects?

Since you've gone through this long post and I gave a lot of context, I am of course very open to suggestions to do this in a completely different way :D
Thanks!

@high_output-5000 I think [matrix~] is the way to go as @alexandros suggests..... as it avoids building a matrix of [*~] controlled by the toggle matrix.
I have dynamically patched audio connections directly in the past... but of course clicks as connections are made and broken.
I had missed [numberbox_matrix] and would definitely have used that to create the messages to [matrix~] if I had found it at the time.
It is a very simple solution with no need for sends and receives. You can pass the messages directly from [numberbox_matrix] to [matrix~] and set the fade time in [matrix~] to avoid clicks.
But it means putting a number 1 or 0 in the numberbox rather than just clicking a toggle....... so building a toggle matrix might be better...... however.....

If you only needed one toggle selected at any time then [grid] is back on Deken thanks to Lucarda..... and if you set x max and y max to the same as the number of squares in the [grid] it will output the data you need to control [matrix~].
So for my twopence...... [grid] and [matrix~] gives instant relief for a single toggle selection.

Last thoughts.......
A Data structure could well be easier to build than a toggle matrix and easier on the cpu @jona.
If you are sending any to any (any input to any filter) you could use radio buttons instead of toggles.
Or Ofelia could do the job........ https://forum.pdpatchrepo.info/topic/11792/ofelia-test-grid .... but is a bit heavy.
David.

@oid said:

@ddw_music Long sysex messages work just fine if you treat them as what they are and what pd is quite good at dealing with, streams.

I do understand what you're saying, and I began with the same assumption -- that [midiout] should be just a low-level conduit -- byte goes in, byte gets sent out.

Unfortunately it doesn't work that way in practice.

My test scenario looks like this. Launch SuperCollider and Pure Data. It helps in my case that I'm testing in Linux, where I can create and remove MIDI connections arbitrarily in qjackctl's ALSA tab.

SC code:

MIDIClient.init;

MIDIIn.connect(0, MIDIClient.sources.detectIndex { |src| src.device.containsi("pure") });

m = MIDIOut(0).connect(MIDIClient.destinations.detectIndex { |dst| dst.device.containsi("pure") });

m.connect(MIDIClient.destinations.detectIndex { |dst| dst.device.containsi("superc") });

MIDIdef.sysex(\a, { |... args| args.postln });

Then I need to go to qjackctl and connect Pd's MIDI output to Pd's MIDI input.

At this point, I can send MIDI from either Pd or SuperCollider, and both SC and Pd will respond.

Pd patch, implementing "stream of bytes" (btw I tested both [sysexin] and [midiin], no difference in the results):

sysex-stream.pd

(Note also: Because I am collecting the MIDI-in bytes into a list, I also checked whether there is a maximum list length. There may be, but we won't hit any such limit in these tests -- I could go up to 5000 numbers in a list, no problem. So, in case of any message truncation, it must be happening in the MIDI objects, not in list handling.)

The test case will be to send a packet of n 14-bit integers (MSB first). The total packet size will be n*2 + 2, so if we want to produce exactly b bytes, n = (b / 2) - 1.

SuperCollider sending:

(
f = { |n|
    var out = Int8Array[240];
    n.do { |i|
        out = out.add(i >> 7 & 127).add(i & 127);
    };
    out.add(247);
};
)

// small packet
m.sysex(f.value(10));  // SC OK, Pd OK (22 bytes)

// 512 bytes
m.sysex(f.value(255));  // both OK

// 514 bytes
m.sysex(f.value(256));  // SC OK, Pd did not print

And my results for Pd sending:

• 22 bytes (n = 10): Both OK
• 512 bytes (n = 255): Both OK
• 514 bytes (n = 256): SC did not respond. Pd printed only 512 bytes (truncated).

Conclusions:

• When SC sent 514 bytes, SC received 514 bytes, so we know SC is sending a complete packet.
  • Pd did not respond, suggesting that both [sysexin] and [midiin] simply stopped listening after 512 bytes, did not process the ending delimiter, and thus did not output the packet at all.
• When Pd was asked to send 514 bytes, Pd received only 512 bytes. This suggests that [midiout] is buffering the incoming bytes, waiting for a complete packet before sending, but it must have a limit of 512 bytes, causing the message to be truncated. (And SC didn't respond at all, which suggests that the closing delimiter was never sent.)

So again... in principle, you're correct -- it's technically possible for some [midiout] object to relay the data out, byte by byte. But neither [midiin] nor [midiout] are implemented that way.

hjh

@oid that's nice and simple. I think you can also ignore the "$1 set 1" message, as the toggle will have been clicked manually, and won't be affected by "$1 set 0". In this case, you have to initiate [f ] with some value that doesn't exist in [route] below it, like -1, to avoid deactivating the first toggle, if this is the one that is being clicked at the very beginning ([f ] will hold 0 without any arguments, so the first time it will be queried, it will send a 0 to the first toggle). Of course that's what you're avoiding with the "$1 set 1" message in your version.
I'm sure you understand all the above, I'm just writing it for anyone else who need clarification.

sorry for the late reply, somehow the it was not possible to post for some time.

@whale-av, ah, now i understand! So the data size needs to be set to the number of pressure values that i'm sending in to the filter. Makes sense and it seems to work much better now. Still there is indeed a calculation problem in [example] that i now understand. By ignoring the lowest input of the three neightbouring crossings most scenarios cant be handled correctly.
For example:
crossing A / note 61 = pressure 75
crossing B / note 62 = pressure 95
crossing C / note 63 = pressure 76
The highest pressure obviously lies almost exactly at B and in the middle between A and C. The calculated note should be approx. 62.05...
[example] though will calculate that B and C have the smallest difference, leave out A, and output the note 62.2.
So it is indeed needed to calculate all three values together if i want to have the correct peak of pressure. I thought and googled a bit and figured, that it would probably be the best if the three known values are used for a quadratic equation that can help determine a parabola and thus the apex of the pressure applied. I think it will the patch more simple too. Will try to do it with [expr] the next days and give an update as soon as possible.

To be honest, I hadn't tested the patch before I shared it. Which I definately should have, because I just found some serious distortion problems! Not the kind of distortion that you may want, of course ...

The problem is this: In a digital (sampled) signal you can never really find zero-crossings. All you can get is the first sample after the zero crossing. So I had to calculate an imaginary point between the samples n (> 0) and n-1 (< 0) using linear interpolation. The point of zero crossing then is: n - x[n] / (x[n] - x[n-1])

Fortunately, the vline~ object is sub-sample accurate and can handle this!

So here is an improved version of the patch: waveset-experiments-ms.pd

One more problem might be pd's limited precision. But I've never worked with "double precision" and it would probably be an overkill for this kind of problem anyway.