If I pass a relative path to such an utility, I want it to resolve to
the current working directy and *not* to the Pd patch itself.
In practice, I almost wrap such utilities in a shell script anyway and
there I would turn relative path arguments into absolute paths before
passing them on to
use the current working directory?
Ah, now I understand your question. But I don't think it is a valid
question. I see no point in using what currently is the working
directory of Pd. Depending on how Pd is started, it uses a different
working directory without the user necessarily intending
On Fri, 2022-01-07 at 23:41 +0100, Christof Ressi wrote:
> > > > And what would you *do* want to use the current working
> > > > directory?
> > The patch's own directory, like all other file writing objects do.
> Sorry, made a typo there. I meant: what would you do if you *do* want
> to
> use the
And what would you *do* want to use the current working directory?
The patch's own directory, like all other file writing objects do.
Sorry, made a typo there. I meant: what would you do if you *do* want to
use the current working directory?
Generally, [file] doesn't do any magic.
I don't
On Fri, 2022-01-07 at 23:20 +0100, Christof Ressi wrote:
> >
>
> And what would you *do* want to use the current working directory?
The patch's own directory, like all other file writing objects do.
> Generally, [file] doesn't do any magic.
I don't consider starting from a sane working
I think what we actually need is something like [file isabsolute] and
[file isrelative]! That would be a trivial but very useful addition.
Just made a feature request:
https://github.com/pure-data/pure-data/issues/1535
___
Pd-list@lists.iem.at
What I think should happen when instantiating any [file] objects is to
set the working directory to the patch's directory and not to Pd's
start directory. The latter is irrelevant in the cases I can think of.
And what would you *do* want to use the current working directory?
Generally, [file]
On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote:
>
> Yeah, this works fine for finding already existing files, but as the
> help-file says, you cannot resolve directories with. So, it cannot be
> used for
Sorry, I somehow hit 'send' in the middle of a sentence. I meant to
say: [file
On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote:
>
> What I think should happen when instantiating any [file] objects is
> to
> set the working directory to the patch's directory and not to Pd's
> start directory.
I was wondering how objects before [file] did select a path for
writing.
On Fri, 2022-01-07 at 18:11 +0100, Antoine Rousseau wrote:
> Have you tried [file which] ?
Thanks for the hint. This helps for finding already existing files by
their relative path, but it doesn't help for creating new files
specified by relative path.
Roman
signature.asc
Description: This is
On Fri, 2022-01-07 at 19:57 +0100, Christof Ressi wrote:
> > When using a relative path with the new [file], it is resolved
> > relative
> > to Pd's start location and not relative to the patch.
> Actually, it's resolved to the current working directy. This is
> expected behavior.
Expected by
On 30.11.21 11:13, Simon Iten wrote:
I am finding infos from people doing it with omxplayer, but I need it
synced and looped. Or are there any other Linux video players that can
sync two streams on two different monitors?
You can sync and loop with omxplayer with multiple Rpis. I did this 5
check this :
https://github.com/gllmAR/pd-omxplayer
it is a good base for network use but as i see it could be used on two
local instances of omx-daemon.
i didn't try it.
please keep me informed if it works for you.
have a nice day .
Le mar. 30 nov. 2021 à 13:01, Bastiaan van den Berg a
When using a relative path with the new [file], it is resolved relative
to Pd's start location and not relative to the patch.
Actually, it's resolved to the current working directy. This is expected
behavior. The [file] interface itself is just a thin wrapper over the
POSIX file API and
Have you tried [file which] ?
Le ven. 7 janv. 2022 à 17:58, Roman Haefeli a écrit :
> On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote:
> > Dear list
> >
> > When using a relative path with the new [file], it is resolved
> > relative
> > to Pd's start location and not relative to the
On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote:
> Dear list
>
> When using a relative path with the new [file], it is resolved
> relative
> to Pd's start location and not relative to the patch.
I'd like to work-around this with [dir(-[pdcontrol] which returns the
directory of the patch
Dear list
When using a relative path with the new [file], it is resolved relative
to Pd's start location and not relative to the patch. This is unusual,
as [text], [array], [table], [soundfile], etc. resolve relative paths
relative to the patch. Also, I don't quite see the use case for
relative
17 matches
Mail list logo
