ok, so i have this:

the objective of this is to save all the 16 arrays i have (i have a 16 looper system i use at gigs etc) into textfiles and wavefiles.
but, since the filenames are static, i run the risk of overwriting previously existing files by chance.

now, i've been running around trying to find a date system, i was told [zexy/date] would work, but while going through the All_Objects.pd in ELSE library, i came across else/datetime, which looks like this, in it's most useful (for this usecase) situation:

now, my question is, how would i take this bit of information (2023_04_02) and incorporate it into a foldername, like:
/Users/esaruoho/Music/samples/pd/(here)/plomwavexport%d.wav

and make sure that prior to the writing of those wav + textfiles to /pd/(here)/ - the (here) folder is created?

@oid
hi, just got it working in a more complex way (such as delay 10 to send to [bng] which sends to [symbol /path/date] - but after looking at what you sent, i got it working like the above screenshot.
(btw, i need it to be yyyy-mm-dd - your direct method just outputs yyyy-m-d)

now i'm trying to figure out how in the world to take this resultant folder structure and feed it to [makefilename]

i'm sure it's just a few minutes of fiddling away though.

i tried [makefilename $1/plomwavexport%d.wav] but that didn't work. tried feeding it the end result as a symbol i.e. [symbol /Users/esaruoho/Music/samples/pd/plom/2023_04_04] but that also didn't work. i'm not sure how to get it to "go".

@esaruoho Your Pd file is fine..... or @oid's is anyway.
He mentioned OSX permissions above.
Is a bang sent from the right outlet of [file]....?
Your problem does suggest that security stops Pd creating the folder.
I don't know much about Macs, but Google found this.........

"To review app permissions—for example, if you later decide to give a denied app access to your Mac—choose Apple menu > System Settings, click Privacy & Security in the sidebar, then click Accessibility on the right. (You may need to scroll down.) Turn permission on or off for any app in the list."

I hope that is the solution..... good luck, but Accessibility might not be the permission that is needed.
Can you (as administrator) create folders outside the Desktop?
Maybe try telling Pd to write to the desktop....... /Users/esaruoho/desktop/Music/samples/pd/plom and see if that works.

Also try the flags..... the arguments for [file mkdir -v] to see what nastiness prints to the console or the right outlet, and [file mkdir -m] to set user permissions in octal....
You will have to Google for "OSX permissions in octal" to work out what you need, and it probably only sets the permissions for the folder you want to create..... so will not solve your problem.
David.

@esaruoho Dollar arguments work differently in objects than messages, in objects they are expanded on creation so any object in [your-abstraction Arg1] with $1 in it will have $1 expanded too Arg1. Manual has a good rundown on dollar arguments. So if you want to build a message you need to do it in a message {$1/filename( -> [makefilename] or read the section on doing multiple substitutions in the makefilename help. I don't think you even need makefilename but you could maybe use some error handling, always wise to do checks before you start writing stuff to the filesystem.

But I have little business talking about the audio side of pd, have never even used soundfiler, and pd is not sane so you may very well need makefilename before soundfiler for some reason unknown to me.

@whale-av said:

@esaruoho Your Pd file is fine..... or @oid's is anyway.
He mentioned OSX permissions above.
Is a bang sent from the right outlet of [file]....?
Your problem does suggest that security stops Pd creating the folder.

so in the newest screenshot, PD definitely successfully creates the date-folder.
but what i'm missing now is how to combine that with the 1-16 array textfile+wavefile renderer, i.e. how to put in $1/plom%d.wav and $1/plom%d.txt so that it works. so, now that the correct folder has been created, it's a matter of using that same symbol of the correct path, in makefilename, and that's what i'm vague on this time

Like @oid recommended: trying to avoid [makefilename], - as it might be the most confusing object in Vanilla:

Read the helpfile of messages > changing messages
on how to compose messages.

Maybe this?

You can use [pack s f] instead of [list append],

but [set( only sets the upcoming message. To send that upcoming message, - or let's say to forward it, you have to [bang( it.
With comma you can put several messages in one, so

[set something, bang(
|
[temp(
|
[soundfiler]

sets the upcoming message to something and bangs it afterwards.

@esaruoho You seem to already have the bang for the messages sent to [soundfiler] as @lacuna suggests..... but you are not sticking the parts of your symbol together as shown in his and @oid's examples.
So have the files been written to the /plom directory instead of the /plom/2023_04_04 directoryintended?

You are breaking up your messages.
A space between two parts of a message will create 2 separate messages.
If you need one symbol you do not need [makefilename].
You need to stick the message dollar variables together..... including at the output of [pack s s s].
So for one message composed of 3 variables do not put [$1 $2 $3( but put instead [$1$2$3(
Sort of the same principle as that you used with the [else/format list]] arguments to create a single date message.

[soundfiler] and [readsf~] are both a bit "picky" about the messages they receive and do need explicit symbols.
Try [symbol $1$2( where $1 and $2 are directory and filemame from the previous message.... banged into [write $1( where $1 is now the combined path and filename.... and send that to [soundfiler].
David.

P.S. If you start your message with "symbol" or "list" or another tag then the message sent onwards prepended by "set" is not broken up into separate "symbol" and "message".
The tag takes effect on the following message and is silent in the next message window.
If you [print] that following message then you will see that.
For a "list" tag...... which is automatically applied by the [list] objects..... often it is necessary afterwards to remove the tag with [list trim] to get back to a symbol..... as you can see in some of the examples above.
Standard tags (also called "selector") are list, symbol, float (implied) and pointer.
A PITA is that a text string is considered "text" unless tagged as a symbol.
If you are unsure of the tag then you can use "a" for "anything" in a trigger and the message will pass...... as in [t b a].

You can also add your own tags to a message..... which is what you are doing when you send [this woof( into [route this that].
It is a little complicated, but essentially the first atom in a message is considered to be the tag and the following atoms parts of a list, except........

It is nasty. I made this tag.zip to help me through the quagmire..... especially to remember to use [bug_protected] when necessary as a list sent into [route] will change its arguments when unrecognised.

It is horrible...... e.g. you need to know that list is stripped if the list starts with a symbol......
but added back if it starts with a float....... but that doesn't show up in a [print].
You need [rawprint] to see that..... maybe the most useful external ever made...?......

ok so i took a long look at that makefilename thing and thought about what $1 $2 and $3 really mean in the mix. in the end i ended up just introducing a fourth symbol into the pack s and that would be the full url with the date in it, and then this was enough in the message to get the everything going:

wavename set write -wave $4/$1 $2;
textname set write $4/$3 $2

thanks everyone for your assistance!

I find, when coding, that I can sometimes "throw code at the wall" and eventually something will stick... but with patching, it takes more effort to be clear about which data are traveling where. Hence "i took a long look at that makefilename thing and thought about what $1 $2 and $3 really mean" is the thing that got results I guess the catch is that the patching UI invites a "throw stuff at the wall" approach.

Your solution -- build the path and then reuse it -- is nice and elegant.

hjh