For anyone who can help..... the patch is here...... https://forum.pdpatchrepo.info/topic/13555/picodrumz-extremely-simple-drum-module
Personally I think it needs a better ADSR than the simple [line~] but maybe that's a matter of taste.
Changing [the message to line to [1, 0 2000( and the [pow 4] below to about 50 works better for me.
With a syncopated rhythm triggered manually the pitch seems to vary, but I think that's psychoacoustic...
But it could be the [phasor~] fm though as you say...?
Very hard for me to be sure.
David.

@mezko The list-abs library has an abstraction for this... list-inter.zip
It might produce the same lists as @oid's patch. I have not tested.
I imagine that it will do what you are looking for if the correct lists are applied to the second and third intets.
David.

@KoaN Thank you for posting what you have discovered. It will surely help someone in the future.

In windows you can start 2 instances of Pd.... one for audio and one for midi.... which can help as although the audio settings do affect the midi lag you can set one of the instances to run with a tiny buffer that would cause audio dropouts..... but use that instance purely for midi.
This can be done in other os's too.

The 2 instances can then communicate control rate messages using [netsend] and [netreceive].
A steep learning curve but you seem to be advancing rapidly.

The instances can be opened with a pre determined setup using command line flags.... http://msp.ucsd.edu/Pd_documentation/resources/chapter3.htm#s3.4.1

Here is an example of a batch file that should achieve this.....

start "C:\Users\David\Desktop\Pd Vanilla\pd-0.55-2.msw\pd-0.55-2\bin\pd.exe -noaudio -midiindevice 2 -midioutdevice 2" start midi_patch.pd
start "C:\Users\David\Desktop\Pd Vanilla\pd-0.55-2.msw\pd-0.55-2\bin\pd.exe -r 44100 -asio -nomidi -audioindev 9 -audiooutdev 9 -inchannels 18 -outchannels 22 -audiobuf 2 -blocksize 64 -callback -nosleep" start audio_patch.pd
exit

The paths will be wrong for your computer, so will need to be changed, and the command line flags will be wrong for your sound card, and probably for the midi devices too. For the sound card and midi devices you should first open your patch and open the Media AudioSettings and Media MidiSettings and write down the device numbers and settings for those found on your system as Ps starts up.
Then create an audio patch (-nomidi) and a midi patch (-noaudio) and change the command flags to match your setup for each.

BUT I cannot (so far) get the flags to work in a batch file opening 2 instances (works fine for one instance so it is my batch programming problem).
So copy the code above into a simple text editor like notepad, save it as e.g. "pd_twice.bat" and then edit it to match your Pd binary location and the Pd files you want to load to each instance. Once the 2 instances are open set the audio and the midi for the instances to something like this and do not turn on DSP for the midi instance.......
Keep the batch file with the Pd files you are loading in the same folder.

Of course your settings for the audio and the midi instances will be different..... different devices, different delay for audio.... but the midi instance can have the delay set to 1 (or maybe even 0) as it will not be running any audio.
As @jameslo says above...... in Pd the "Delay" setting is the buffer for communication with the sound card.
David.

@KoaN Well done getting it to work... and welcome to the forum.
Pd will introduce a small delay. The "control" messages... the non-audio messages like midi... are processed in between the audio blocks. The standard block in Pd is 64 samples.
That gives a latency of about 1.45 milliseconds. If you move one and a half feet away from another musician you hear what they play one and a half milliseconds later..... so that latency is not really noticeable.
It could be that you have a large audio buffer set for your sound card. On a computer one thing has to finish before another can be processed and audio has priority. Try to keep buffers as small as possible. If you make them too small you will start to get clicks as the computer fails to process audio in time... so it's a compromise.
With a pro soundcard with good drivers you should be able to reduce the buffer to 128 samples or maybe even less. Using the computer on-board sound card you will need a much bigger buffer to avoid clicks and so some noticeable latency.

You are unlikely to get help here with those exact plugins..... as someone would have to have purchased them. But other forums dedicated to plugins might well give you some pointers.
David.

@porres Wow! Thank you to all the contributors..
David.

@Balwyn Personally I wouldn't bother with $0 as the clones and nested clones can have more arguments like this......
this.zip

Edit... I have not passed on an argument for the first clone.... so 20 messages received....obviously incorrect.... but no time to fix it now. But easily doable...

David.

@impression All clones are automatically assigned $1..... normally from 0 but here starting at 1.....
Clone is [clone -s 1 6voices_part 800 800]

Put a [receive] inside the receiving abstraction and [route] your message to the correct abstraction using [route $1]

The message will be e.g. [6 cutoff 0.378(
Where "cutoff 0.378" will be received at the outlet of [route $1] by the abstraction number 6.
Sent to [s curve] (in this case)......
David.

@impression Good news..!
Yes, the MrPeach objects take care of string, float etc formats without us needing to get involved in such details.. They are very useful.
David.

@impression If it is definitely sending then tcp and udp should work if you have specified the same port and the same format (tcp or udp) for both the send and receive..
If you put a [print] on the left outlet of [netreceive] you should see some data arrive.
Assuming you are not trying to receive on another (second) RPI, in which case you will need to tell the GPIO RPI the IP address of the second RPI as well as the port.
David.

@atux You can try that....... pd2py_v2.pd
Does it work?
If not then post your Python code and someone will tell you why not.
David.

@andrearkham Might need some externals (it is old), and might not be what you need......
https://forum.pdpatchrepo.info/topic/3274/speech-formant-synthesizer-with-bonus-turkish-vowels-pack-p
David.

@willblackhurst If you look at the help file for [tabread4~] you will see that correct interpolation requires guard points added to the array so that interpolation is performed correctly as [phasor~] wraps around the end of the array.
Your patch doesn't glitch between the array copies, but it does as [phasor~] wraps at the end of the 3rd copy, or where you chop into the array adjusting the clip length percentage.
@lacuna made a handy patch to add guard points automatically.... https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect
I suppose that if you want to adjust the playback length then you would need to copy a percentage of the array to a new array, and then add the guard points.
David.

@jameslo Yes, it seems to work with the $0 inside or at the end of the name....
David.

@jameslo Can you make it work something like this?
I would expect that $0 can be used in the name as they are both objects.... but I am so confident that I didn't check.....
David.

It seems to update [value me]....... maybe.pd

@Coalman Nearly...... see [sort-help] from the zexy library, which contains what could be a specified list randomiser if a $ argument is added to [pd randompackage].....
No post sort routing though.
David.

@Coalman Probably the list-abs library....... maybe [list-wrandom]..?
Although the list-abs library comprises vanilla abstractions.
David.

@avenir I agree with @alexandros , as it seems what you are trying to achieve is convolution but only for volume, in which case you could send [tabread4~] into [env~] and give [env~] a big enough window size to smooth the envelope which you will multiply by the output of [noise~].
David.

@jameslo Schrodinger would have a word with you...
I think knowing the applied output of [phasor~] is enough, as it is the only "known" and is determinable. Capturing at audio rate timing also gives almost unfathomable precision given the bit depth at 64-bit. Go for 192kHz sample rate if you want. Although such timing is not really human relatable it could make a difference when multiplied in the signal domain.
I know, I am setting myself up for some pushback....

More ramblings.....
It should be a new thread I suppose, but it would be good to establish exactly the data points reported by [snapshot~] and [print~] etc.
I think it has been discussed before so I will try to dig it out.
@lacuna [snapshot~] is continuously taking snapshots of the last value of a block. That is demonstrated by the fact that when banged with dsp off it reports a value. Not sure that it can be called a bug, but it needs to be widely known.
When [print~] is banged with dsp off nothing is printed, and it will print the block following the bang with dsp on. Its first reported value is the next sample after the [snapshot~] value if they are banged at the same time.

Yes, @porres for sample accurate timing we do have all the "v" objects but if the patch is controlled at block boundaries then repetition of actions is still accurate, simply the original command and the repeated command both occur at exactly the block boundary.
Assuming that [phasor~] always starts at 0 when the patch is created the commands are repeatable.

Using "v" objects is slightly more complicated as it is documented for example that [vline~] starts its ramp one sample early.
Vanilla [vsnapshot~] is still documented.... "- mal-designed snapshot~ extension, best not to use this".

So a time graph of samples over 2 blocks, with "v" and "non-v" objects overlaid showing their data points and trigger points would be a very useful reference document I think.
I know I am making work for you, but somewhere I got the idea that you enjoy it... !
David.

@jameslo A very different approach (which seems to work) by suspending dsp processing in the sub-patch and re-starting when you wish to repeat the [phasor~] sequence (it should be accurate but could need better testing by external graphing..!!)....... phasor-store.pd
In 32-bit Pd it seems to be accurate for value only to 1/1000 but in 64-bit 1/10000 or greater.

This method does not restore the master [phasor~] so a switch to using the slave would be necessary as the sequence is restored.... and it is single use.

I cannot fathom for now how the same accuracy could be saved and recalled for a future start of a patch, apart from saving an [array] of a [phasor~] output.
David.

@avenir Thank you for testing.
Should get there in the end..... cart-5-vanilla.zip
David.