In abstractions I've been using the following to provide default values for creation arguments that aren't specified:

[loadbang]
|
[list $1]
|
[select 0]
|        |
[7(      |
|        |
+--------+
|
[...\

Where "7" would be a default value. (That seems to work well unless I want to explicitly set the creation argument to 0).

But what if I'm using $1 to set the length of a delay:

[delwrite~ $0-del $1]

How can I set a default value for the $1 in the [delwrite~...] if my abstraction is created without a $1 creation argument?

@AlanMJackson Sorry to be so negative today. You know what I am going to write.......
The $ argument in an object is interpreted as the object is created...... and gets its value from the arguments of the patch that contains it.
So, no argument, no value, and it will be set to zero which is particularly useless for [delwrite~]

Anyway, it is [delread~] or [vd~] that need a value changed usually and they take messages.
Nowadays with loads of ram you can just set [delwrite~] as long as you could possibly need.
David.
Ps.... @Liam is about to tell you that you could create and connect it dynamically....... with an "if $1=0" "else"

@whale-av Thanks for your speedy help today!
Ah ok, so [loadbang] and anything it triggers isn't running at creation time, it's actually running after that at "load" time.

I'm writing vanilla PD patches for the Bela so I was wanting to keep everything like memory as small as possible but your answer prompted me to go and check on the Bela's specs. It's got 512MB of RAM, so I've probably been worrying unnecessarily.

Depending on what you're doing, you could also use [max] to establish a floor for the argument value.

[loadbang]
|
[f $1]
|
[max 7]
|
...

@AlanMJackson Like this........ dynamic_delw.pd
You then need another message to connect its inlet, and you need to know how many objects you have in the patch first...... so that [connect x y z a( message will be the last thing to add to the patch.
David.
Ps......... aargh...... missed one connection...... sorry..... download it again as it is now fixed.
Ps Ps...... if you change [dynamic_delw] and save it you must first delete the [delwrite~] that it has created, otherwise you will end up with more than one...... all on top of each other.
Click the [7000( message to see it create the object.
Put [dynamic_delw 20000] and [dynamic_delw] into another patch to see that it creates with an argument or with the default 7000.

@whale-av Oh wow, dynamic object creation. I had no idea that was possible. My mind is blown. Thank you. I've only been learning PD for a week. I think I'll wait for another week before I start using that for real!

Here's a quick test patch I made just to see how the obj and connect messages work.

dynamic-object-creation2.pd

@whale-av Is the only way of using connect with the number of the object? I could see it would be tricky to count correctly for larger sets of objects.

I guess I can connect it all up by hand then look in the saved pd file with a text editor.

@AlanMJackson Yes, this is the only way. Looking at the patch in a text editor may help.

I made an abstraction out of this: dyndelwrite~.zip.

Here you can see how to deal with some difficulties of dynamic patching. As connentions to inlets might get lost otherwise, everything is created within a subpatch together with a receive. The inlet with the send stay outside of the subpatch. This also allows to send [clear( to the subpatch in the beginning to keep everything clean. In the end, a [dirty 0( message is send to make the patch appear as if it where saved, to avoid warnings when closing the patch.

There is a warning in place here: When you work with [dirty 0(, you have to make sure to save your patch before closing, as there will be no warning.

Here is a collection of dynamic patching commands: https://forum.pdpatchrepo.info/topic/10813/collection-of-pd-internal-messages-dynamic-patching