Seems to me English is not up to the challenge here.

So here is what I mean:

triple-arp.pd -- plugdata, and uses else and/or cyclone for audio, apologies to vanilla-land.

The notes are to play in the same order continuously, but distributed among the three players. If I print out the symbols being accessed and add note indices, it's:

next: symbol instr3 -- play note 0
next: symbol instr2 -- note 1
next: symbol instr1 -- note 2
next: symbol instr1 -- note 3
next: symbol instr2 -- note 4
next: symbol instr1 -- note 5
next: symbol instr3 -- note 6
next: symbol instr2 -- note 7
next: symbol instr1 -- note 8
next: symbol instr1 -- note 9
next: symbol instr2 -- note 10
next: symbol instr3 -- note 11 etc.

@porres 's "one sequence and 3 independent playing from this sequence. I can envision a simple [clone] with 3 instances..." sounds like it will clone the sequence -- that's not the same thing.

@oid 's version will skip notes, because it's advancing through the stream on a fast timing that is independent of the three players' timing (and the order isn't deterministic -- whereas SC's Pshuf repeats the same shuffled ordering). That's also a misinterpretation. The advancement through the stream should be passive, in response to requests from the players.

("Why would you want to do that?" Why not... it's a reasonable algorithm.)

Now, why do I care about this? Because I've done a lot with state-machine parsers and found it to be really nice to have, for instance (and speculating in Pd terms) an abstraction that parses an identifier, and another abstraction that parses a number, and another that parses some kind of bracketed group containing identifiers and numbers, etc. How do these different parts of the patch know where you are in the source string? This is easy if there is a shared object that streams out the characters one by one, and the character goes to the part of the patch that requested it. Distributing a single stream among multiple players is just a different version of the same problem -- I was hoping that putting it in musical terms would make it clearer, but that seems not quite to have worked.

It's mainly out of curiosity to see how patching handles this.

• I'm suggesting [send] with a variable target: the request tells the stream where to send its "next" result.
• Or @solipp has suggested to spray the value everywhere in the patch that it might be needed, and then the caller bangs only the one it's interested in.

I feel a bit like the "spray everywhere" solution would require more object copy/paste -- mine just has "; next symbol instr1" where the other needs a [t], a [s], a [r], and an [f]. Also my [pd stream], if it used a list instead of an array, could be type-agnostic. (I only used an array here to avoid more lectures about the perils of list manipulations, which are not quite relevant I think.) But YMMV.

hjh

I've released an album and an EP of music made using my Pd based performance software, formuls.

You can stream them from my bandcamp page, or take one of the free download codes from below. Enjoy!

Disorder as a function of time (from Graz to Holycross)
https://formuls.bandcamp.com/album/disorder-as-a-function-of-time-from-graz-to-holycross

Obsession as a function of time (inertia)
https://formuls.bandcamp.com/album/obsession-as-a-function-of-time-inertia

Free download codes!
Disorder as a function of time (from Graz to Holycross)
suxy-ghz3
pley-uv84
rs6n-jkbm
kxg7-cq8j
uekx-w8bk
v8np-h2l9
9kd8-5dvt
z3qy-bctb
za83-xh3x
39zl-j5cq
wy2j-6rst
pkm6-y4hb
8ngt-bmpw
2dk2-xz3s
kxc3-b6tl
uejw-x6uj
x8b4-jymk
qzxh-gr98
93ej-346n
zd8r-cm8j
3qzd-wtbk
5g2e-hbl9
8klg-5cvt
tnpz-bwtb
ta9n-xx3x
jxpk-uqg4
7c62-jzrm
xs3d-kth6
qqxe-67qy
9bcg-yjkr

Obsession as a function of time (inertia)
kkm5-gd3m
uz8g-uhd6
vtzn-ejwy
9ktm-uycr
z3z6-vf4d
nayt-gpjc
w9kt-un8w
cy3y-jmu4
suvy-kgam
slgz-67ug
pskn-kvmu
665j-w989
knr8-c87z
kam2-w2q6
z685-hd6y
zynb-vctf
ztam-gc3m
3z99-uxd6
5ytu-evwy
8kka-78cr
tny8-vn4d
2aky-gajc
76c3-u69y
v3hl-j6kf
6ae4-kyzm
nf6h-guk6
m5ns-bqzk
98ap-wz89
ynfg-ct7z
y5a3-wbq6

@porres But this is way cooler and provides a great deal to learn from

Oh, I missed this. Well, sorry then for suggesting an external that does it then? I see now it's not cool and doesn't provide a way for people to learn, maybe I shouldn't have suggested, is that it? Sorry for the sarcasm, but I don't know how to respond to this and I'm just either very surprised or I don't get where this is coming from. Should I should never ever suggest any external, as some random people might say they don't want externals? I'm really trying to understand where this is coming from, please help me understand what you mean...

Vanilla might be more work and less efficient than an external but the efficiency is not that big of a deal these days and that work is rewarded with better understanding of pd and gives the ability to do far more than externals generally allow.

You can't play soundfonts in Vanilla wihtout an external, maybe you missed that part? Note that @Balwyn suggests people to use "RGC-Audio" plugin loaded via the [vstplugin~] eternal.

Anyway, not being sarcastic now, but if I ever suggest other externals in this forum and people, for whatever reason, don't like using externals and want to just be fully Vanilla, I guess it makes sense to keep it to oneself as this is not about this person... you know? If people don't like externals, don't use them and don't criticize people that offer externals. Maybe others in this forum kinda like using externals right? And anyway, if anyone wants use soundfont in Pd, this person definitely need externals!

@Aliam.Sigsaly the maintainer of pdlua is Albert Gräf. The way open source software works is that one person can use the code from other projects (provided the licenses are compatible). This is called a 'fork' and it doesn't imply that the original project is being 'taken over' or 'annexed' by the fork.

Afaik there are feature request github and discord forums/channels for plug data if you want to discuss the direction of the project (though I suppose this could also be an appropriate venue).

Imo your expectations for an announcement on arbitrary channels for a certain library version not being supported anymore are slightly unreasonable.. I would say that if you want to be informed of plug data or development about a certain version of ophelia there are places to follow in order to do so.

I also don't think it's productive to talk about how superior m4L is unless you're making specific feature suggestions for the project you want to use in a productive and collaborative way.

edit: also, a great thing about open source is that if you don't like the direction of a project you are free to make your own fork and add or remove whatever aspects you wish. The maintainers have a right to include or omit features and library for whatever reason though you are of course free to make criticisms or suggestions (though I have to say your tone did come across as somewhat entitled, rather than collaborative.. for instance you could enquire why something might not be maintained anymore before catastrophizing). But if you want a certain feature without doing the work to implement it that can come across as expecting free labor or agreement on aesthetics.

edit2: personally I disagree with alexandre's "everything in 1 lib" philosophy for else (personally I like using many different established libraries that already have equivalent objects) but he does work hard on it and those aspects have driven its adoption in plug data and many other projects. Also he probably (would have been) open to improvements for it in general if you considered them to be lacking and had made pull requests to improve it or at least given suggestions or feature requests instead of/before complaining..

@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.

@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;

@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.

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.

@jenkutler
The helpfile of [cyclone/togegde~] doesn't work here, but I replicated it's behavior in signalrate like this:

togedge~2b.pd

If you want strictly ints, you can add a signalrate [int] like this:

@bocanegra said:

The logical output is signal rate (which can be very useful). If you want bangs look into [threshold~]. You should be able to set that up as a zero crossing detector.

I don't know about [threshold~] never used it, but my example above is not suitable as zerocrossing detector, as the chance of a sample being actually 0 at zero-crossing is very small!
Detecting zero-'crossing' would be a transition from postive to negative or vice versa, or to zero. There is also [zerox~].

The DSP block size will affect the accuracy of the timing though so if you need a bang exactly when your signal crosses zero, you will need to do [block~ 1]

Much later edit: the following is actually wrong, - it is even more complicated (((Message-handling happens in 64-sample periods, only. You can't change that. Even if [threshold~] would go down to 1 sample (still one sample late), the following message-chain won't.))))
EDIT: edited