@hansr Pretty sure a wrong order of operation...... as [expr sin....etc] looks for the value of w$0 but it is not set by [unpack] until after [expr ($f3...etc] operates.
So a one time only divide by zero as the patch is first run..
Swapping the first and second outlets of [unpack f f f] should fix it...
David.

@Orangery ChatGPT will not help...it will not have devoted much resource to Pd..
As you mentioned compiling @dreamer probably thought you were trying to compile CC from pure data using Heavy.
Pd does not normally need to be compiled.
You could send a screen shot of the errors you are getting, which would help us understand maybe..?
But the pd patch that is producing those errors would be more useful for seeing how to help you.... it doesn't matter that it is not working.... it will show us how far you have got and save us repeating the work that you have already done.
You can upload it to the forum using the "up arrow" symbol above your post as you are typing.
David..

@Penguino Do you get a result using this.zip test patch...? (unzip first)
David.

@Penguino Android supports midi since 6.0 and Midi2 since 13.0.
But I think devices need to offer support for a USB OnTheGo connection.
The Hexler TouchOsc page ... https://hexler.net/touchosc/manual/setup-android-usb-midi suggests that there are no naming conventions or fixed port numbers.
This page might help understanding of any hurdles... https://source.android.com/docs/core/audio/midi

I can find no reference to a successful PdDroidParty implementation but I think it could be a question of finding a midi device that claims to work with Android.... class compliant.
Some might work but need a splitter OTG cable to provide extra power for the device.

The TouchOSC app is cheap and IMHO a useful investment...... so might be worth trying.
It can easily communicate with Pd on a computer over a network using OSC messages.
David.

@jamcultur My best guess....
[savestate] in the main patch (as that works correctly) and global (not $0) messages to/from the [toggle] in the 2nd level abstraction.
Might need a small delay to restore the [toggle] correctly on recreation as the creation order might perturb the restore.
David.

@rewindForward Object I don't know but simple to build.....

You might need to smooth the switch using messages to [line~] or [vline~] instead of [*~ ]
David.

@kroklop92217 It might help to look at @Porres 64-bit rewrite of the 2005 16-bit cycone object [matrix~].
https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/audio/matrix.c
Control input lists are probably the same...... (Input id, output id, gain 0-1(
Creation arguments set the number of inputs and outputs and 1-mix.or.0-switch(
i.e. [matrix~ 5 7 1]
David.

@_ish The vanilla version is [random] which spits integers.
You could use a few of them and [* 0.1] ... [* 0.01] for each..... adding the outputs.... if you want more decimal places.

Bangs at loop wraparound... https://forum.pdpatchrepo.info/topic/3168/bang-on-zero
So it depends on how you are driving the array and how much time accuracy you need but [edge~] might be good enough.
As in that link if using [phasor~] catching it's output as it passes 0 is unreliable because the value of [phasor~] will likely not be 0 as it is captured at a block boundary.
There are audio rate objects that can set future events within the 64 sample blocks of the Pd audio thread, so achieving more time accuracy.
Their names usually start with a "v"
So [vline~] is a more time accurate version of [line~] for example.

But for most uses whether a bang is at one block boundary or the next is unimportant.
Audibly it is as if the origin of the sound has moved just one metre further away from you.

If you are looking for an external object (not part of your vanilla download) then go to Help.... Find externals..... in the Pd top menu and search for it.
[randomf] is in the markex library.
David.

@ddw_music Oh no...!!... I aimed for both....
David.

@ddw_music