@RetroMaximus Sorry.... what I noticed is that "get_state" is never sent on from the [f] where it is stored.
It is simply overwritten by an incoming float from "state" when that arrives at the left inlet of [f]..... and it is that float that is sent onwards.

+..... if [t f f] receives a bang and not a float then it will send 0... zero. Hopefully not the case..!
David.

@RetroMaximus Are you not banging in "state" for example instead of "get_state" and the trigger should be [t b f] and not [t f f]......?
If so then the same error for all the other outlets of [route].... ?
David.

@RetroMaximus Also...... adding to @ingox tips....... you can store floats in [f] and lists in [list] and symbols in [symbol] on their right inlets and then bang them through via their left inlets when ready.
Maybe use [f] or [list] or [symbol] where appropriate at the end of all your chains, and then use a [t b b b b b ........] at the top of your chain to bang them all onwards in the correct order once all the data is set?
David.

@4ZZ4 slate.zip
David.

@4ZZ4 I don't understand.
Do you mean send it into another program?
On a mac I think "soundflower"? or something similar..... https://rogueamoeba.com/freebies/soundflower/
On a Pc...... https://www.vb-audio.com/Cable/
David.

@60htz It works for me with Pd 0.50 in windows7.
I assume you modified the plugin for those folders.
What is your operating system?
@ingox I think Pd now only sets a [declare] in an abstraction for that abstraction..... I need to check that though. Maybe your solution could work though....... as Pd might see it as a top level "mother" patch. Testing required by @60Hz though.
David.

@60htz Yes, very strange.
What version of Pd and which OS?

Stupid question maybe........ are your files actually in Pd/extra/extra/path1 and path2.....?
David.

@RetroMaximus Yes, order of operations seems likely.
You should work from the object that starts the operation and follow each leg (including through send/receives) to the very end.
Remember that a trigger [t x y] will not send "x" until every operation of "y" has finished......
If you connect "y" to another trigger [t b c] then "c" first and then "b" must be complete before x will start.

Sends >>> multiple receives are problematic because you probably don't remember in which order you created them.
You might need to create new triggers and send/receive pairs to force the order of operations to various parts of your patch.

You have used [delay] a few times. That will reschedule the operation that comes afterwards and is not really a good solution for forcing the order of operations. [delay] might seem to solve an immediately obvious problem, but then makes it really impossible (in all circumstances) to be sure of the state of the other data when the scheduled operation actually "happens".
David.

@cfry To open a Pd patch add...... -open <file.pd> ...... (no left and right arrowsI think) as a command line switch for the command that starts Pd in the .desktop file. You might need the full path.... or not.
Other switches can set audio parameters etc...... https://puredata.info/docs/faq/commandline
For the synth and Jack I think you will need to look at their doc.
E.G. https://manpages.debian.org/jessie/yoshimi/yoshimi.1
I would expect Jack to have startup command line switches as well.
David.

@4ZZ4 It is as I thought. The two audio rate calcs combined will not work.
I have added a switch to switch off the unused inlet (softly ..... no clicks).
Also..... sorry..... I compacted your patch as I am working on a small screen.
Try this....... exponent-wave-2.pd
It looks and sounds correct to me.
David.