On 1/27/22 10:10, martin brinkmann wrote:

thanks, i'll do that. i used [shell] basically for getting a random-seed (and filenames) via date, and it affects only a few patches, and should be easy to change to [command].

if you need to read the date, you probably should use zexy's [date] (resp [time]). it works on all platforms, and is *much* faster than a call to an external program.

if you want to generate a seed for your random number, you can use the new built in [file] to read some bytes from /dev/random (from your usage use [shell] together with date, i figure you already use a unix-like system). the randomness should be much better than just using some date-based thingy.

mfgadr IOhannes

On 1/27/22 20:06, martin brinkmann wrote:

i need the date-as-a-filename

i have no idea what that means. but concatenating a bunch of numbers into a symbol is not exactly rocket science,even in Pd.

ffdsxy IOhannes

On 1/28/22 08:23, martin brinkmann wrote:

On 27/01/2022 23:05, IOhannes m zmölnig wrote:

...

On 1/27/22 20:06, martin brinkmann wrote:

...

i need the date-as-a-filename

...

but concatenating a bunch of numbers into a symbol is not exactly rocket science,even in Pd.

yes, and that was what i did.

but without a date (and withouth a unique random number as a fallback (shell not working)) my old soundfiles are replaced when a new one is recorded, which is not exactly what i want.

so that's when you use zexy's [date].

i was under the impression, that you simply dismissed zexy's [date] because you "need the date-as-a-filename". on re-reading i see that i was wrong. sorry.

instead you wrote:

so speed does not matter much. platform independence would be nice though, and a 'vanilla'-solution even nicer...

it's of course always nicer to be vanilla only. i suggested zexy mainly because you were *already* using an external (leaving aside that zexy is my library and somebody else's :-))

the thing with ggee is, that it practically has been unmaintained for 15 years or so. zexy otoh is still actively maintained (i consider it stable so there is not much new development going into it; but bugs are fixed regularly - if they are reported)

but if you do want a vanilla solution for setting initial values, i'd go the other way round: create a script that invokes Pd, providing whatever unique values you need. something like:

#!/bin/sh
timestamp=$(date +%Y%m%d-%H%M)
pd -send "timestamp ${timestamp}" -open mypatch.pd

and in the patch you need something like this for filename generation

|
[t b]      [r timestampe]
|          |
|          [symbol]
|          |
[symbol XXX]
|
[symbol sound-$1.wav(
|

mgfds IOhannes

On Sun, 2022-01-30 at 18:59 +0100, martin brinkmann wrote:

i have switched to [command] and it works fine (except for numeric values being converted to floats and coming out of the left outlet (!?), but adding a (non numeric) character to the output helped.)

[command] parses stdout and stderr of the command as a FUDI message. Numeric values are returned as floats, symbolic values as symbols and leading, trailing, or multiple spaces (or tabs) are discarded. I _think_ quite a few objects interfacing the outside world behave like this, so I assume it is kind of a standard.

If you want to preserve the exact output, use the binary format invoked with the -b flag [command -b]. This returns the results as list of bytes. You could use [list tosymbol] to convert the whole thing to a single symbol. If you want more sophisticated parsing, you can do it, though it probably takes a little effort.

Roman

On Tue, 2022-02-01 at 21:17 +0100, martin brinkmann wrote:

On 30/01/2022 21:43, Roman Haefeli wrote:

...

If you want to preserve the exact output, use the binary format invoked with the -b flag [command -b]. This returns the results as list of bytes. You could use [list tosymbol] to convert the whole thing to a single symbol.

i have tried this (and used list/tosymbol before with filenames as numeric characters), and it works. but the problem is, that

exec date +%S%M%H%m%d

(my randomseed which looks like 3401210201 for example)

apparently prepends a parsed numeric value to LS_EXIT (first) outlet of [command]).

I'm confused. The left outlet of [command] outputs the exit code of the command, not the stdout of it. The middle inlet is supposed to output the stdout of the command.

the output is something like print: 5.70921e+09 print: 0 and nothing at the middle (and right) outlet.

As I tried to explain previously, this is expected behavior in Pd land. If you want to preserve the exact output, use the -b flag and convert the result to a symbol with [list tosymbol]:

[exec date +%S%M%H%m%d( | [command] | <- middle outlet [list tosymbol] | [print]

Gives me: symbol 4416220201

Note: If your [command] outputs stdout on the left, then you're using a unreleased beta version of [command] that probably even hasn't the -b flag implemented. However, only the released version v0.1 is available through Deken.

Roman

On 2/2/22 09:04, martin brinkmann wrote:

On 01/02/2022 22:25, Roman Haefeli wrote:

...

As I tried to explain previously, this is expected behavior in Pd land.

yes, but the float is coming out of the leftmost output, and this only happens when the commands output is a number (and only a number).

"exec echo 123456789" for example, while "exec echo number123456789" works

well, this is just how FUDI works.

• everything that looks like a number, is interpreted as a number.
• numbers are internally represented as single-precision floating point

and Pd will not show you the *exact* number, but "print" it using %g to make it more visually pleasant.

(I'm not going into details; this has been discussed in the past. more than once; check the archives if you are interested).

so:

• if your script outputs "123456789", this looks very much like a number

and is thus converted to one.

• since the number is a single precision floating point number, it will

not be *exactly* "123456789" (since this number cannot be represented by a 32bit floating point number). instead it will be stored as 123456792.0f

• if you display your number with [print] or a numberbox, it will show

as "1.23457e+08". the same string-conversion happens if you use $arg expansion (e.g. "[open mysound.$1.wav(").

you can use your own conversion if you send the number to [makefilename]. e.g. [makefilename mysound.%d.wav] will give you the integer part of the full number (but it's still a 32bit floating point number, so you won't get "123456789")

adding a string, and afterwards splitting it off is a workaround.

this is of course very ugly. Pd is not exactly good at string manipulation.

better use zexy's [date] and [time], create a list of the values you are interested in and then do a piecewise assembly:

[12 34 56 79 90] | [open mysound.$1$2$3$4$5.wav(

...

flag implemented. However, only the released version v0.1 is available through Deken.

i use

commandv0.1.dek     Uploaded by rdz @ 2021-10-01 22:20:51

installed via deken a few days ago

i just like to confirm that the version available via deken will indeed output single number printout on the 1st outlet.

https://github.com/pd-externals/command/issues/9

dgnfsa+ IOhannes

On 02/02/2022 13:04, Roman Haefeli wrote:

On Wed, 2022-02-02 at 12:06 +0100, IOhannes m zmoelnig wrote:

...

https://github.com/pd-externals/command/issues/9

Thanks, Martin, for finding that bug

and thanks for fixing it, and i'm looking forward to the new version.

and thanks, IOhannes, for creating

an issue.

sorry, i should have done this myself, but i was not entirely sure whether this was a bug or i was doing something wrong...

bis denn! martin

On Wed, 2022-02-02 at 12:06 +0100, IOhannes m zmoelnig wrote:

On 2/2/22 09:04, martin brinkmann wrote:

...

i just like to confirm that the version available via deken will indeed output single number printout on the 1st outlet.

https://github.com/pd-externals/command/issues/9

IOhannes already fixed the problem (whose solution also fixed another issue). I created a 0.2 release. It should be available on Deken soon.

Roman