Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Sat, 2022-01-08 at 19:11 +0100, Christof Ressi wrote:
> Should we also provide a creation argument and float message for the 
> parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> 
> [file patchdir] would output the parent patch directory, etc. This
> would 
> make [pdcontrol]'s [dir( method entirely obsolete.

Nice idea. The ability to query upper level patches is quite a powerful
feature. 

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

probably [file patchpath] then?
a "path" can be both a file and a directory, whereas a "dir" can only be the 
latter

+1



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[IOhannes m zmölnig]

Am 8. Jänner 2022 19:11:43 MEZ schrieb Christof Ressi :
>Then let's go with [file patchdir] for now. I don't care too much about 
>the name :-)
>
>A bang would unsurprisingly output the patch directory.
>
>You can also send a path name as a symbol. If the path is relative, 
>[file patchdir] will resolve it to the patch directory. Absolute paths 
>are passed unchanged.


probably [file patchpath] then?
a "path" can be both a file and a directory, whereas a "dir" can only be the 
latter


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

Then let's go with [file patchdir] for now. I don't care too much about 
the name :-)


A bang would unsurprisingly output the patch directory.

You can also send a path name as a symbol. If the path is relative, 
[file patchdir] will resolve it to the patch directory. Absolute paths 
are passed unchanged.


Should we also provide a creation argument and float message for the 
parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> 
[file patchdir] would output the parent patch directory, etc. This would 
make [pdcontrol]'s [dir( method entirely obsolete.


Christof

On 08.01.2022 18:46, IOhannes m zmölnig wrote:

Am 8. Jänner 2022 18:31:43 MEZ schrieb Christof Ressi :

Both would essentially provide the same things. IMO, [file resolve]
would be more intuitive because after all that's what people likely want
to do when they ask for the current patch directory.



I dunno.
iirc, [file which] was originally named [file resolve] but I started a hearty 
dislike for this name, as I think its rather confusing.


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[IOhannes m zmölnig]

Am 8. Jänner 2022 18:31:43 MEZ schrieb Christof Ressi :
>Both would essentially provide the same things. IMO, [file resolve] 
>would be more intuitive because after all that's what people likely want 
>to do when they ask for the current patch directory.
>


I dunno.
iirc, [file which] was originally named [file resolve] but I started a hearty 
dislike for this name, as I think its rather confusing.


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

I'll be travelling on Monday and can make a PR while sitting around.


  (I'm currently afk, but isn't there already something like this in the 
filename handling parts of [file]?)

Yes, there is. [file isabsolute] should be trivial to implement.


add [file cwd]
   (and probably allow it to also *set* the cwd, not just query it)

Yes, why not. Should be easy to do with chdir() resp. _chdir()


add [file patchdir]
   (I would consider it a feature if that functionality was provided by [file] 
rather than [pdcontrol] (which could keep it for legacy reasons))
+1. On GitHub I have already proposed [file resolve]: 
https://github.com/pure-data/pure-data/issues/1539. The difference is 
that it resolves any path onto the patch directory. Sending a bang would 
output the patch directory itself (= [file patchdir]).


[file patchdir] would be the other way round: it's main purpose is to 
get the patch directory, but as an extra feature it should probably also 
allow to resolve a file path (because such a common task shouldn't 
require several objects).


Both would essentially provide the same things. IMO, [file resolve] 
would be more intuitive because after all that's what people likely want 
to do when they ask for the current patch directory.


Christof


On 08.01.2022 17:58, IOhannes m zmölnig wrote:

Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi :

I think what we actually need is something like [file isabsolute] and
[file isrelative]! That would be a trivial but very useful addition.


yes.

the solution I like best so far is:
- add [file isabsolute]
   (I'm currently afk, but isn't there already something like this in the 
filename handling parts of [file]?)
- add [file cwd]
   (and probably allow it to also *set* the cwd, not just query it)
- add [file patchdir]
   (I would consider it a feature if that functionality was provided by [file] 
rather than [pdcontrol] (which could keep it for legacy reasons))


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Miller Puckette via Pd-list]

The confusion is my fault... "." never really meant current working directory,
it just means "THIS directory here".  I.E., it could mean any #$^#$ thing at
all :)

M

On Sat, Jan 08, 2022 at 10:42:35AM +0100, Dan Wilcox wrote:
> I agree with Roman's point that "current working directory" as an idea is 
> different, depending on the user. For some, it will be relative to the patch, 
> for others it will be relative to the shell (and the resulting programs 
> launched by it). I agree it makes technical sense that [file] would be 
> relative to the Pd process, knowing the C api behind it, but for many it's a 
> bit of friction for sure since it's something that now works different from 
> other objects which handle paths implicitly. Additionally, I think it's 
> perhaps a stretch to assume most beginners are aware of how shells and paths 
> work.
> 
> If it were up to me, I would make [file] work like the other objects and 
> treat relative paths as relative to the canvas. OTOH I know this could 
> complicate the implementation. I think at the very least, this difference 
> needs to be well documented with the requisite canvas-oriented approaches 
> documented. Forgive me if they are already as I've not used [file] yet, but 
> Roman's question indicates to me perhaps not everything is covered yet. ;)
> 
> Another approach is to provide a very explicit option to get the patch canvas 
> location which fits into the api ala [file patchdir] or [file canvasdir]. I 
> know this is probably redundant to [pdcontrol] but perhaps helps with the 
> distinction..?
> 
> > On Jan 8, 2022, at 1:07 AM, pd-list-requ...@lists.iem.at wrote:
> > 
> > Message: 4
> > Date: Sat, 8 Jan 2022 01:07:48 +0100
> > From: Christof Ressi  > <mailto:i...@christofressi.com>>
> > To: Pd-List mailto:pd-list@lists.iem.at>>
> > Subject: Re: [PD] [file]: paths not relative to patch
> > Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com 
> > <mailto:0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com>>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> > 
> >> 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 Pd. But I just wanted to show that the current 
> > directory is not completely useless.
> 
> 
> Dan Wilcox
> @danomatika 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD=gH_npJrym_AUp6g2bC1Cy42FFNjsXv2JGArQ6pEwxoM=
>  >
> danomatika.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com_=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD=5QkVbm0PrquWxtDou0wHEgQlij2_6GjNBrY2b5e5XMI=
>  >
> robotcowboy.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com_=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD=H8fVMW2BC7JQXR0lgwqC8aVGjEXivsHhxcCet25Ib4Q=
>  >
> 
> 
> 

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD=Yk4lLERpW4lj0UBqxDacoYqSc91l7nXb2qIJgzQCYoM=
>  




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[IOhannes m zmölnig]

Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi :
>> I think what we actually need is something like [file isabsolute] and 
>> [file isrelative]! That would be a trivial but very useful addition. 


yes.

the solution I like best so far is:
- add [file isabsolute]
  (I'm currently afk, but isn't there already something like this in the 
filename handling parts of [file]?)
- add [file cwd]
  (and probably allow it to also *set* the cwd, not just query it)
- add [file patchdir]
  (I would consider it a feature if that functionality was provided by [file] 
rather than [pdcontrol] (which could keep it for legacy reasons))


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

I, personally, find the documentation of [file] quite good.


Yes, but it doesn't mention at all that relative paths are resolved to 
the current working directory (or any other way the OS prefers). This is 
goes against an established pattern and would be surprising to most 
users (although it's not wrong).


I think file-help.pd should mention prominently that relative file paths 
are generally *not* resolved to the canvas environment and you have to 
use either [file which] or [dir( -> [pd control]. Hopefully, the latter 
can soon be replaced by something like [file resolve]: 
https://github.com/pure-data/pure-data/issues/1539





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Sat, 2022-01-08 at 10:42 +0100, Dan Wilcox wrote:

> 
> If it were up to me, I would make [file] work like the other objects
> and treat relative paths as relative to the canvas.

I agree with Christof that this probably not a good idea after pd 0.52
has been released.

>  OTOH I know this could complicate the implementation.

Yeah, I see that now. I thought
'chdir(canvas_getdir(canvas_getcurrent))' would probably do, but since
[file] runs directly in Pd it would apply to the whole Pd instance,
which is probably not what anyone wants. My external [command] does
that, but after forking, so it doesn't apply to the parent thread. This
allows to call scripts lying near the patch containing [command]. 

>  I think at the very least, this difference needs to be well
> documented with the requisite canvas-oriented approaches documented.
> Forgive me if they are already as I've not used [file] yet, but
> Roman's question indicates to me perhaps not everything is covered
> yet. ;)

It came up because I noticed [file] breaks established patterns
regarding relative paths. Improving the documentation alone wouldn't
help with making write files near the patch easier. I, personally, find
the documentation of [file] quite good. 

> Another approach is to provide a very explicit option to get the
> patch canvas location which fits into the api ala [file patchdir] or
> [file canvasdir]. I know this is probably redundant to [pdcontrol]
> but perhaps helps with the distinction..?

The hard part is not getting the canvas directory, as that is already
covered, but simply writing a file near the patch involves quite a lot
of patching right now. What _would_ help is Christof's suggestion of
[file resolve] if it has the ability to resolve to relative to the
patch.

[symbol myblobs/newblob.dat(
|
[file resolve -canvas]
|
[open $1 c(
|
[file handle]


See:
https://github.com/pure-data/pure-data/issues/1536#issuecomment-1007849130



Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Sat, 2022-01-08 at 10:27 +0100, Dan Wilcox wrote:
> I assume you already have a relative & absolute path check
> implementation. 

Yes, but thanks anyway.

> If not, I have a simple set of vanilla path abstractions, pre-[file]:
> 
> p_absolute, p_makeabsolute, p_makerelative, etc

> https://github.com/danomatika/rc-patches/tree/master/rc

The latter two currently use [getdir] from ggee, but this could easily
be replaced now by [dir(->[pdcontrol].

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Dan Wilcox]

I agree with Roman's point that "current working directory" as an idea is 
different, depending on the user. For some, it will be relative to the patch, 
for others it will be relative to the shell (and the resulting programs 
launched by it). I agree it makes technical sense that [file] would be relative 
to the Pd process, knowing the C api behind it, but for many it's a bit of 
friction for sure since it's something that now works different from other 
objects which handle paths implicitly. Additionally, I think it's perhaps a 
stretch to assume most beginners are aware of how shells and paths work.

If it were up to me, I would make [file] work like the other objects and treat 
relative paths as relative to the canvas. OTOH I know this could complicate the 
implementation. I think at the very least, this difference needs to be well 
documented with the requisite canvas-oriented approaches documented. Forgive me 
if they are already as I've not used [file] yet, but Roman's question indicates 
to me perhaps not everything is covered yet. ;)

Another approach is to provide a very explicit option to get the patch canvas 
location which fits into the api ala [file patchdir] or [file canvasdir]. I 
know this is probably redundant to [pdcontrol] but perhaps helps with the 
distinction..?

> On Jan 8, 2022, at 1:07 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 4
> Date: Sat, 8 Jan 2022 01:07:48 +0100
> From: Christof Ressi mailto:i...@christofressi.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] [file]: paths not relative to patch
> Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com 
> <mailto:0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
>> 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 Pd. But I just wanted to show that the current 
> directory is not completely useless.


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Dan Wilcox]

I assume you already have a relative & absolute path check implementation. If 
not, I have a simple set of vanilla path abstractions, pre-[file]:

p_absolute, p_makeabsolute, p_makerelative, etc

https://github.com/danomatika/rc-patches/tree/master/rc 


> On Jan 7, 2022, at 11:35 PM, pd-list-requ...@lists.iem.at wrote:
> 
>> If you want to resolve an 
>> existing file using Pd's canvas: use [file which]. If you want create
>> a 
>> new file relative to the patch, use [dir( -> [pdcontrol].
> 
> That's what I do now. That's the easy part. The less easy part is
> reliably detecting whether a given path is relative. But knowing that
> even Pd does it somewhat clumsily, I'll stick to the clumsy solution
> (checking for / and :).


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

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 Pd. But I just wanted to show that the current 
directory is not completely useless.


On 08.01.2022 00:49, Christof Ressi wrote:



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 to do so.


There are certainly scenarios where this is exactly what you want, 
e.g. when Pd is used as command line utily (I have personally written 
such utilities). 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.



Thus, all file writing objects are written so that
they write relative to the patch. That's an already established
pattern. I don't see why you are arguing against it.
I acknowledge that it's an established pattern. Actually, [file] could 
have added an object [file cwd] to get the currenty
working directy if someone needs it and use the Pd patch location as 
the default.


On the other hand, I understand that [file] wants to be a low-level 
filesystem API and not apply any magic. It's really design decision.



I'm asking you back: What do you do if you want to write relative to
Pd's start location with [text], [textfile], [table], [soundfiler],
[array]? You currently cannot do that and apparently this is no
problem, otherwise people would have requested it.


Yes, this is a limitation. And actually an argument for a [file cwd] 
object.



How is the current working directory not a sane directy?

See above. It's just not useful for anything.

See above. It is.

even Pd does it somewhat clumsily, I'll stick to the clumsy
solution
(checking for / and :).

That's what I was going to recommend.

  It's clumsy and wrong. It'll detect my  sub-directory named 'C:' as an
absolute path while I was intending it as a relative path.

Ah yes, on the patch level you don't know if you're on Windows. On 
Windows, ':' is a reserved character and can only appear as part of a 
drive letter.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

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 to do so.


There are certainly scenarios where this is exactly what you want, e.g. 
when Pd is used as command line utily (I have personally written such 
utilities). 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.



Thus, all file writing objects are written so that
they write relative to the patch. That's an already established
pattern. I don't see why you are arguing against it.

I acknowledge that it's an established pattern. Actually, [file] could have 
added an object [file cwd] to get the currenty
working directy if someone needs it and use the Pd patch location as the 
default.

On the other hand, I understand that [file] wants to be a low-level filesystem 
API and not apply any magic. It's really design decision.


I'm asking you back: What do you do if you want to write relative to
Pd's start location with [text], [textfile], [table], [soundfiler],
[array]? You currently cannot do that and apparently this is no
problem, otherwise people would have requested it.


Yes, this is a limitation. And actually an argument for a [file cwd] object.


How is the current working directory not a sane directy?

See above. It's just not useful for anything.

See above. It is.

even Pd does it somewhat clumsily, I'll stick to the clumsy
solution
(checking for / and :).

That's what I was going to recommend.
  
It's clumsy and wrong. It'll detect my  sub-directory named 'C:' as an

absolute path while I was intending it as a relative path.

Ah yes, on the patch level you don't know if you're on Windows. On 
Windows, ':' is a reserved character and can only appear as part of a 
drive letter.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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 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 to do so. When
I double-click a Pd file, the working directory is set to my user home.
When I launch Pd from terminal or by script, anything might be the
resulting working directory. If I do use that in a patch, I must make
assumptions about how the user running my patch is starting Pd. I do
not think that makes any sense, therefor I don't see how Pd's start
location has any sensible meaning in everyday patching. 

I'm asking you back: What do you do if you want to write relative to
Pd's start location with [text], [textfile], [table], [soundfiler],
[array]? You currently cannot do that and apparently this is no
problem, otherwise people would have requested it. 

> > > Generally, [file] doesn't do any magic.
> > I don't consider starting from a sane working directory magic.
> How is the current working directory not a sane directy? 

See above. It's just not useful for anything.

> Again, [file] 
> doesn't do anything special. It treats relative file paths just like
> the 
> OS shell would do.

And? It's usually not part of the Pd workflow to switch to a specific
directory before starting Pd. More often, Pd is launched by double-
clicking a patch. This is very unlike shell, where switching
directories  is part of the experience and where there's an expectation
it has an impact on the outcome ('ls' without args). This does not
apply to Pd at all. Thus, all file writing objects are written so that
they write relative to the patch. That's an already established
pattern. I don't see why you are arguing against it.


> > >   If you want to resolve an
> > > existing file using Pd's canvas: use [file which]. If you want
> > > create
> > > a
> > > new file relative to the patch, use [dir( -> [pdcontrol].
> > That's what I do now. That's the easy part. The less easy part is
> > reliably detecting whether a given path is relative. But knowing
> > that
> > even Pd does it somewhat clumsily, I'll stick to the clumsy
> > solution
> > (checking for / and :).
> That's what I was going to recommend. 
 
It's clumsy and wrong. It'll detect my  sub-directory named 'C:' as an
absolute path while I was intending it as a relative path.





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

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 consider starting from a sane working directory magic.
How is the current working directory not a sane directy? Again, [file] 
doesn't do anything special. It treats relative file paths just like the 
OS shell would do.

  If you want to resolve an
existing file using Pd's canvas: use [file which]. If you want create
a
new file relative to the patch, use [dir( -> [pdcontrol].

That's what I do now. That's the easy part. The less easy part is
reliably detecting whether a given path is relative. But knowing that
even Pd does it somewhat clumsily, I'll stick to the clumsy solution
(checking for / and :).
That's what I was going to recommend. After all, [file isabsolute] would 
likely just use sys_isabsolutepath() under the hood :-)





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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 directory magic.

>  If you want to resolve an 
> existing file using Pd's canvas: use [file which]. If you want create
> a 
> new file relative to the patch, use [dir( -> [pdcontrol].

That's what I do now. That's the easy part. The less easy part is
reliably detecting whether a given path is relative. But knowing that
even Pd does it somewhat clumsily, I'll stick to the clumsy solution
(checking for / and :).
> 
> > 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
> 
> But that's a general limitation of Pd. At the moment, it can only 
> resolve files but not directories. This limitation can, of course,
> be 
> removed and then [file which] will work as expection.

Thinking about it some more, this isn't a severe limitation. As I
understand, it looks into all search paths. However, when I configure
'myblobs' as directory, I don't mean to write to any other 'myblobs'
directory that might be returned by [file which]. I think [file which]
shouldn't be for finding directories to write new files into. It should
only be used for finding existing files. 


> > I only need to append the
> > configured path to the patch's path if the configured path is a
> > relative path. But how can I reliably detect that?
> I think what we actually need is something like [file isabsolute]
> and 
> [file isrelative]! That would be a trivial but very useful addition.

I think those would be valuable additions.

Roman





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

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 mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

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] doesn't do any magic. If you want to resolve an 
existing file using Pd's canvas: use [file which]. If you want create a 
new file relative to the patch, use [dir( -> [pdcontrol].



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


But that's a general limitation of Pd. At the moment, it can only 
resolve files but not directories. This limitation can, of course, be 
removed and then [file which] will work as expection.



I only need to append the
configured path to the patch's path if the configured path is a
relative path. But how can I reliably detect that?
I think what we actually need is something like [file isabsolute] and 
[file isrelative]! That would be a trivial but very useful addition.


Christof





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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 which] doesn't work for resolving relative directories.
Obviously, you also cannot use it for non-existing files, a.k.a files
you want to create. This means, using [file] for writing files near the
patch is a rather convoluted enterprise.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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. If I am not mistaken, [text] uses canvas_makefilename() for
converting a given path or filename to an absolute path. It first
checks if the given path is absolute by checking for '/' (first byte)
or ':' (second byte) and prepends the canvas' own directory to it, if
is relative. It's basically a clumsy way to switch the working
directory to the patch's directory. And it's what I have to do now when
using [file]. 

I need to be enlightened: What is the benefit of using Pd's start
location as working directory in [file]?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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 a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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 whom? Not by a regular user, I suppose, since virtually all
other objects interfacing with IO interpret relative paths as relative
to the patch for _writing_. It's only [file] that stands out and
behaves differently and its the only one that cannot write a file
relative to its patch. If you say this behavior is intended, then I
fail to see the usefulness of this design choice.

Consider this case (a real problem I currently face, not something made
up):

I am writing a patch with a configurable path for writing binary blobs.
The default in the configuration is set 'myblobs' and myblobs is a
directory that exists near the patch. The idea is that new binblobs are
saved there. Since [file] won't find 'myblobs/newblob.dat' near the
patch, I can use [dir(-[pdcontrol] to find the patch's directory and
append the configured path to it: '/path/to/my/patch/myblobs'. Now, I
am able to write my new binblob to the configured path at
'/path/to/my/patch/myblobs/newblob.dat'. Now, the user configures a
custom absolute path for their binblobs: '/opt/myblobs'. My patch
appends this to the patch's path: '/path/to/my/patch/opt/myblobs' and
boom, that is not what the user has expected. I only need to append the
configured path to the patch's path if the configured path is a
relative path. But how can I reliably detect that? Not that easy as I
explained in the other mail. 

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.


>  The [file] interface itself is just a thin wrapper over the 
> POSIX file API and therefore agnostic of Pd's search paths.

Absolutely. I don't see how I am challenging that. I think the decision
of what the current working directory is is wrong. 

> As Antoine has already mentioned, use [file which] if you want to 
> resolve a relative path to the canvas environment.

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 


Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

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 therefore agnostic of Pd's search paths.


As Antoine has already mentioned, use [file which] if you want to 
resolve a relative path to the canvas environment.


Christof

On 07.01.2022 17:34, 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. 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 to Pd's start. At least, _I_ never cared about where Pd was
started from and when working on a patch meant to run on other people's
computer I don't make any assumptions about Pd's start location. To me,
relative to Pd's start location is pretty useless.

Now, it's really unlucky I spotted this only now after 0.52 has been
released. Fixing it would break backwards-compatibility. OTOH, the fact
this hasn't been reported yet makes me assume [file] with relative
paths wasn't used that much yet. If this is going to be fixed, it
should be fixed rather soon.

Best,
Roman

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Antoine Rousseau]

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 patch.
>
> I'd like to work-around this with [dir(-[pdcontrol] which returns the
> directory of the patch which can be used to construct an absolute path
> with a given relative path.
> However, the hard part is to reliably detect whether a given path is
> relative. I thought I could check for absolute paths by checking if the
> first byte is a '/' OR the second byte is a ':'. However, it turns out
> 'C:' is a perfectly valid name for a directory on ext4, for instance.
> Doing that detection reliably turns out to be quite hard and probably
> involves detecting the OS.
>
> Or am I overlooking a simpler vanilla way?
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

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 which can be used to construct an absolute path
with a given relative path.
However, the hard part is to reliably detect whether a given path is
relative. I thought I could check for absolute paths by checking if the
first byte is a '/' OR the second byte is a ':'. However, it turns out
'C:' is a perfectly valid name for a directory on ext4, for instance.
Doing that detection reliably turns out to be quite hard and probably
involves detecting the OS.

Or am I overlooking a simpler vanilla way?
Roman 


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [file]: paths not relative to patch

[Roman Haefeli]

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 to Pd's start. At least, _I_ never cared about where Pd was
started from and when working on a patch meant to run on other people's
computer I don't make any assumptions about Pd's start location. To me,
relative to Pd's start location is pretty useless. 

Now, it's really unlucky I spotted this only now after 0.52 has been
released. Fixing it would break backwards-compatibility. OTOH, the fact
this hasn't been reported yet makes me assume [file] with relative
paths wasn't used that much yet. If this is going to be fixed, it
should be fixed rather soon.

Best, 
Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[Jaime Oliver]

>
> > Maybe [zexy] contains a backdoor for the NSA,
> > who knows?
>
> i do.
>
> well...?

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[IOhannes m zmoelnig]

On 8/31/21 3:50 PM, Christof Ressi wrote:
Has this any security implications? 
Generally, every single external is a potential security risk since it 
contains arbitrary code. 


what i forgot to say:
even with my proof-of-concept exploit (regardless of whether it actually 
works), i don't think there is anything inherently wrong with that.
if we consider Pd as a programming language, then it should be possible 
to write all kinds of code.
e.g. you could write a Pd-patch that cleverly uses beta- and zeta-waves 
to hypnotize people and make them give you all their money - no 
filesystem access involved.
or just play some very loud sounds, right after you completed your ENT 
degree.


having said that, the idea of a "sandboxed" Pd might be interesting.


Maybe [zexy] contains a backdoor for the NSA, 
who knows?


i do.

gfamsdr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[Christof Ressi]

Has this any security implications? 


It's certainly not worse than [pdcontrol] whose "browse" method 
basically allows to run arbitrary executables. A Pd project could 
contain a malicious binary (disguised as a WAV file) which is 
automatically run when you open the main patch - without you ever noticing.


Generally, every single external is a potential security risk since it 
contains arbitrary code. Maybe [zexy] contains a backdoor for the NSA, 
who knows?


Christof

On 31.08.2021 13:05, IOhannes m zmoelnig wrote:

On 8/31/21 12:38 PM, Ingo Stock wrote:

Looks great!

Has this any security implications?


sure.
if the user is allowed to overwrite "C:\Windows\system32\rundll32.exe" 
they could inject malicious code.

or delete that file.

however, if they are allowed to overwrite that file, they can already 
replace it with the contents of a WAV-file to bork the system.


so I don't think there are additional security implications¹.


 Could this be used to attack other
computers?


*other* computers?
no, not really.
it provides an interface to your filesystem.
unless your filesystem lives on other computers, i don't see how you 
could impact them.


gfmasdr
IOhannes

¹ i wonder whether it would be possible (with Pd>=0.42) to create a 
patch that creates a gui-plugin on the fly.
if this is true, then you can already do everything that [file] allows 
you to do - and much more.


gfmadsr
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[IOhannes m zmoelnig]

On 8/31/21 12:38 PM, Ingo Stock wrote:

Looks great!

Has this any security implications?


sure.
if the user is allowed to overwrite "C:\Windows\system32\rundll32.exe" 
they could inject malicious code.

or delete that file.

however, if they are allowed to overwrite that file, they can already 
replace it with the contents of a WAV-file to bork the system.


so I don't think there are additional security implications¹.


 Could this be used to attack other
computers?


*other* computers?
no, not really.
it provides an interface to your filesystem.
unless your filesystem lives on other computers, i don't see how you 
could impact them.


gfmasdr
IOhannes

¹ i wonder whether it would be possible (with Pd>=0.42) to create a 
patch that creates a gui-plugin on the fly.
if this is true, then you can already do everything that [file] allows 
you to do - and much more.


gfmadsr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[Ingo Stock]

Looks great!

Has this any security implications? Could this be used to attack other
computers?

best wishes


Am 23.08.21 um 14:59 schrieb IOhannes m zmoelnig:
> On 8/23/21 12:26 PM, Matt Davey wrote:
>> oh come onspill the beans...what does it do?
>
>
> https://github.com/pure-data/pure-data/pull/1351
>
> gfmdasr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[ub]

wow, because everything is a file (in unix), the sky's the limit!

cheers to that.


ub


On 23.08.21 14:59, IOhannes m zmoelnig wrote:

On 8/23/21 12:26 PM, Matt Davey wrote:

oh come onspill the beans...what does it do?



https://github.com/pure-data/pure-data/pull/1351

gfmdasr
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[IOhannes m zmoelnig]

On 8/23/21 12:26 PM, Matt Davey wrote:

oh come onspill the beans...what does it do?



https://github.com/pure-data/pure-data/pull/1351

gfmdasr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[Matt Davey]

oh come onspill the beans...what does it do?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[Roman Haefeli]

On Mon, 2021-08-23 at 11:10 +0200, Peter P. wrote:
> * Roman Haefeli  [2021-08-23 10:41]:
> > One new object in Pd, one giant leap for Pd programmers!

> Thanks Roman!
> I can't seem to find this in 0.51.4 is it that new?
> Much looking forward!

It will be part of next 0.52 release and is already implemented in
current git master branch. 

Sorry, I got too excited, but realize now that it might not be wise to
post such things on Pd users list.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]

[Peter P.]

* Roman Haefeli  [2021-08-23 10:41]:
> One new object in Pd, one giant leap for Pd programmers!
Thanks Roman!
I can't seem to find this in 0.51.4 is it that new?
Much looking forward!



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [file]

[Roman Haefeli]

One new object in Pd, one giant leap for Pd programmers!

What a great addition. Many thanks!
Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD file format documentation?

[Christof Ressi]

I guess IOhannes means the "f" message which sets the box width.

 
Christof
 

Gesendet: Dienstag, 07. Januar 2020 um 02:02 Uhr
Von: "David" 
An: "IOhannes m zmölnig" 
Cc: Pd-List 
Betreff: Re: [PD] PD file format documentation?

Just out of curiosity, what is it, if it's not a secret? 

On Mon, Jan 6, 2020 at 12:39 PM IOhannes m zmölnig 
mailto:zmoel...@iem.at]> wrote:Am 6. Jänner 2020 18:00:25 MEZ 
schrieb William Huston 
mailto:williamahus...@gmail.com]>:
>Thanks!
>I notice this is from 2004/v0.37
>
>No changes since then?

no. why?


mfg.hft.fsl
IOhannes

ps: actually there is. one. but since it's purely additional, you can probably 
live without it.


___
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]___
 Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD file format documentation?

[David]

Just out of curiosity, what is it, if it's not a secret?

On Mon, Jan 6, 2020 at 12:39 PM IOhannes m zmölnig  wrote:

> Am 6. Jänner 2020 18:00:25 MEZ schrieb William Huston <
> williamahus...@gmail.com>:
> >Thanks!
> >I notice this is from 2004/v0.37
> >
> >No changes since then?
>
> no. why?
>
>
> mfg.hft.fsl
> IOhannes
>
> ps: actually there is. one. but since it's purely additional, you can
> probably live without it.
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD file format documentation?

[IOhannes m zmölnig]

Am 6. Jänner 2020 18:00:25 MEZ schrieb William Huston 
:
>Thanks!
>I notice this is from 2004/v0.37
>
>No changes since then?

no. why?


mfg.hft.fsl
IOhannes

ps: actually there is. one. but since it's purely additional, you can probably 
live without it.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD file format documentation?

[William Huston]

Thanks!
I notice this is from 2004/v0.37

No changes since then?


On Mon, Jan 6, 2020, 8:50 AM David  wrote:

> Or just  https://puredata.info/docs/developer/PdFileFormat
>
> On Mon, Jan 6, 2020 at 8:46 AM David  wrote:
>
>> See
>> https://puredata.info/docs/developer/PdFileFormat?fbclid=IwAR38HPWWXbfn8QrwmgE3A-Vj44NaIJwNKUS4owXoKUjpRqWdy37MWpCCBlg
>>
>> On Sun, Jan 5, 2020 at 11:49 PM William Huston 
>> wrote:
>>
>>> A question arose on Facebook which prompts me to ask:
>>>
>>> Is the PD file format documented anywhere? (besides the source code)?
>>>
>>> Has anyone built any programs which build PD files?
>>>
>>> It might be neat to have a C-Sound or Supercollider style language
>>> (where writting tests and loops can be easier) which compile down to a .PD
>>> source file.
>>>
>>> I'm sure I'm not the only person who has thought of this!
>>>
>>> I realize that editing .PD files directly is generally considered to be
>>> "nicht für der gefingerpoken" ;)
>>>
>>> thanks
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD file format documentation?

[David]

See
https://puredata.info/docs/developer/PdFileFormat?fbclid=IwAR38HPWWXbfn8QrwmgE3A-Vj44NaIJwNKUS4owXoKUjpRqWdy37MWpCCBlg

On Sun, Jan 5, 2020 at 11:49 PM William Huston 
wrote:

> A question arose on Facebook which prompts me to ask:
>
> Is the PD file format documented anywhere? (besides the source code)?
>
> Has anyone built any programs which build PD files?
>
> It might be neat to have a C-Sound or Supercollider style language (where
> writting tests and loops can be easier) which compile down to a .PD source
> file.
>
> I'm sure I'm not the only person who has thought of this!
>
> I realize that editing .PD files directly is generally considered to be
> "nicht für der gefingerpoken" ;)
>
> thanks
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] PD file format documentation?

[William Huston]

A question arose on Facebook which prompts me to ask:

Is the PD file format documented anywhere? (besides the source code)?

Has anyone built any programs which build PD files?

It might be neat to have a C-Sound or Supercollider style language (where
writting tests and loops can be easier) which compile down to a .PD source
file.

I'm sure I'm not the only person who has thought of this!

I realize that editing .PD files directly is generally considered to be
"nicht für der gefingerpoken" ;)

thanks
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] file "save as" window on OSX always opens as "untitled.pd"

[Matt Davey]

Is there any reason why file "save as" in OSX is always defaulting to
"untitled.pd" ??

Is there an easy fix to get it to use the selected patch name?
I think it used to work that way?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] file associations on windows (was Re: [PD-announce] Pd 0.49-0test4 released)

[Lucas Cordiviola]

Would be nice to do it on pd_guiprefs.tcl. The .pd file association does not 
need to specify 32 or 64 Pd on the registry key.

A bit more on pd_guiprefs.tcl. :

On:

https://github.com/pure-data/pure-data/pull/476

we talked about the need to not share prefs for pd32 and pd64.

The C side looks trivial but something must be done on the Tcl side on 
pd_guiprefs.tcl.

IOhannes suggested generating some file with just:


"HKEY_CURRENT_USER\\Software\\Pure-Data-32"

or

"HKEY_CURRENT_USER\\Software\\Pure-Data-64"


so that when when pd_guiprefs.tcl is started the pd32/64 has been already 
detected.

I'll like to know if this is possible when starting Pd with "~/wish85.exe 
~/pd-gui.tcl patch.pd"



Mensaje telepatico asistido por maquinas.

On 9/24/2018 7:58 AM, Dan Wilcox wrote:
It could probably added to pd_guiprefs.tcl. We're already setting a few things 
there on macOS that need to be set for the GUI to behave nicely, ie. turn off 
window state saving for just the Pd app.

On Sep 24, 2018, at 11:34 AM, 
pd-list-requ...@lists.iem.at<mailto:pd-list-requ...@lists.iem.at> wrote:

Date: Mon, 24 Sep 2018 09:27:06 +
From: Lucas Cordiviola mailto:lucard...@hotmail.com>>
To: "pd-list@lists.iem.at<mailto:pd-list@lists.iem.at>" 
mailto:pd-list@lists.iem.at>>
Subject: Re: [PD] file associations on windows (was Re: [PD-announce]
Pd 0.49-0test4 released)
Message-ID:
mailto:cy1pr01mb1963aab39c7bdf96438b56a9a6...@cy1pr01mb1963.prod.exchangelabs.com>>

Content-Type: text/plain; charset="utf-8"

Attached batch file that should live on pd/bin.

i think there should just be a button in the preferences that says
something along the lines: "Open pd-patches with *this* version of Pd".

it would probably be better to handle this directly from Pd-GUI (that
is: write the code in tcl, rather than bat).


Dan Wilcox
@danomatika<http://twitter.com/danomatika>
danomatika.com<http://danomatika.com>
robotcowboy.com<http://robotcowboy.com>




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] file associations on windows (was Re: [PD-announce] Pd 0.49-0test4 released)

[Dan Wilcox]

It could probably added to pd_guiprefs.tcl. We're already setting a few things 
there on macOS that need to be set for the GUI to behave nicely, ie. turn off 
window state saving for just the Pd app.

> On Sep 24, 2018, at 11:34 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Mon, 24 Sep 2018 09:27:06 +
> From: Lucas Cordiviola mailto:lucard...@hotmail.com>>
> To: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" 
> mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] file associations on windows (was Re: [PD-announce]
>   Pd 0.49-0test4 released)
> Message-ID:
>   
>  <mailto:cy1pr01mb1963aab39c7bdf96438b56a9a6...@cy1pr01mb1963.prod.exchangelabs.com>>
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Attached batch file that should live on pd/bin.
> 
> i think there should just be a button in the preferences that says
> something along the lines: "Open pd-patches with *this* version of Pd".
> 
> it would probably be better to handle this directly from Pd-GUI (that
> is: write the code in tcl, rather than bat).


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] file associations on windows (was Re: [PD-announce] Pd 0.49-0test4 released)

[IOhannes m zmoelnig]

On 2018-09-24 01:17, Lucas Cordiviola wrote:
> 
> Known little thing:
> Something must be done to somehow be able to switch .pd file association 
> to 32 or 64. The current behavior is that files (opened from the 
> Explorer) are opened with the last Pd installation and if this 
> installation is removed the other can't open files from the Explorer.

how does this work with other applications?
e.g. if `.doc` is associated with MicrosoftOffice and i install
LibreOffice, claiming the `.doc` extension, what happens if i then
uninstall LibreOffice?


> 
> This might be solved by running a batch script from pd/bin that rewrites 
> to the 'registry'. I'll do some tests.


i think there should just be a button in the preferences that says
something along the lines: "Open pd-patches with *this* version of Pd".

it would probably be better to handle this directly from Pd-GUI (that
is: write the code in tcl, rather than bat).


also, i wonder how much of a problem this will actually be in the real
world (that is: how many people will try to install the 32bit version
and the 64bit version side by side, then decide that they want to ditch
the one they installed last AND will be totally lost in re-installing
the former (or doing file-assocications by hand).

i'm not saying this is not an issue (just trying to assess the priorities)

fgamsdr
IOhannes





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Open Recent... doesn't look like a Pd-file

[me.grimm]

cool... yeah all is working fine now...

thanks!
m

On Sun, Jul 23, 2017 at 9:17 AM, Dan Wilcox <danomat...@gmail.com> wrote:

> Yeah, I thought of this last week while debugging but I forgot about it.
> Fixed with https://github.com/pure-data/pure-data/pull/135 Can y'all give
> it a try?
>
> Also, your current recent files stored in the gui defaults might be
> corrupted with the older bug that didn't quote things correctly.
>
> You can flush them either with the Clear Files menu entry or from the
> command line on macOS:
>
> defaults write org.puredata.pd.pd-gui write NSRecentDocuments ""
>
> You can then see what's in there with:
>
> defaults read org.puredata.pd.pd-gui
>
> I added the info about using defaults to the mac/README.txt a few days ago.
>
> On Jul 23, 2017, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
>
> *From: *"Christof Ressi" <christof.re...@gmx.at>
> *Subject: **Re: [PD] Open Recent... doesn't look like a Pd-file*
> *Date: *July 23, 2017 at 10:29:39 AM GMT+2
> *To: *"me.grimm" <megr...@gmail.com>
> *Cc: *"pd-list@lists.iem.at" <pd-list@lists.iem.at>
>
>
> Hi, I always got this error when the path of the patch has changed and Pd
> can't find the file. The error message is rather misleading, though.
>
> Gesendet: Sonntag, 23. Juli 2017 um 04:02 Uhr
> Von: "me.grimm" <megr...@gmail.com>
> An: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
> Betreff: [PD] Open Recent... doesn't look like a Pd-file
>
> anyone else getting this. when i go to File -> Open Recent -> foo.pd I get
>
> Ignoring 'foo.pd': doesn't look like a Pd-file
>
> ?
>
> im on pd 0.48-0-test3 OSX 10.12.5
>
> m
>
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>


-- 

m.e.grimm, m.f.a, ed.m.
syracuse u., tc3
megrimm.net

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Open Recent... doesn't look like a Pd-file

[Dan Wilcox]

(responding in thread)

I believe this is fixed in a commit which is not in a test build yet. Is the 
recent file list being saved at all or? I not only 1 file is being saved, 
you're seeing the bug I fixed.

https://github.com/pure-data/pure-data/commit/19030496003eb68fe865c7ccd8d99e5fb33a0a5f
 
<https://github.com/pure-data/pure-data/commit/19030496003eb68fe865c7ccd8d99e5fb33a0a5f>

> On Jul 23, 2017, at 5:33 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: "me.grimm" <megr...@gmail.com <mailto:megr...@gmail.com>>
> Subject: [PD] Open Recent... doesn't look like a Pd-file
> Date: July 23, 2017 at 4:02:45 AM GMT+2
> To: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" 
> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>
> 
> 
> anyone else getting this. when i go to File -> Open Recent -> foo.pd I get
> 
> Ignoring 'foo.pd': doesn't look like a Pd-file
> 
> ?
> 
> im on pd 0.48-0-test3 OSX 10.12.5
> 
> m


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Open Recent... doesn't look like a Pd-file

[Christof Ressi]

Hi, I always got this error when the path of the patch has changed and Pd can't 
find the file. The error message is rather misleading, though.

> Gesendet: Sonntag, 23. Juli 2017 um 04:02 Uhr
> Von: "me.grimm" <megr...@gmail.com>
> An: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
> Betreff: [PD] Open Recent... doesn't look like a Pd-file
>
> anyone else getting this. when i go to File -> Open Recent -> foo.pd I get
> 
> Ignoring 'foo.pd': doesn't look like a Pd-file
> 
> ?
> 
> im on pd 0.48-0-test3 OSX 10.12.5
> 
> m
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Open Recent... doesn't look like a Pd-file

[Alexandre Torres Porres]

seems fine here bro,
though it seems to forget some of the recent files

i'm on 10.12.6

cheers

2017-07-22 23:02 GMT-03:00 me.grimm <megr...@gmail.com>:

> anyone else getting this. when i go to File -> Open Recent -> foo.pd I get
>
> Ignoring 'foo.pd': doesn't look like a Pd-file
>
> ?
>
> im on pd 0.48-0-test3 OSX 10.12.5
>
> m
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Open Recent... doesn't look like a Pd-file

[me.grimm]

anyone else getting this. when i go to File -> Open Recent -> foo.pd I get

Ignoring 'foo.pd': doesn't look like a Pd-file

?

im on pd 0.48-0-test3 OSX 10.12.5

m
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Meta Data in a PD file

[José Rafael Subía Valdez]

Oh!! is that what that is!, however you can still see this in the patch,
that is why I was confused. I will take a look at that,

thanks Roman.

BTW, is there a method to get the file name that you open in the patch?
something like canvasname but from the parent itself? (donno if I am
explaining myself properly here)

cheers

On Thu, Oct 6, 2016 at 8:36 PM, Roman Haefeli <reduz...@gmail.com> wrote:

> On Don, 2016-10-06 at 16:39 +0100, José Rafael Subía Valdez wrote:
> > I dont know if it has been discussed, I have searched the archives
> > but didnt find anything simliar.
> >
> > would there be a way to write a META DATA section at the end of a .pd
> > file?
> > I guess this is more of a request. But what if there was a META DATA
> > section available to record things that would be "binded" (don't know
> > if "bound" is the word) to the file. Maybe this could be an open -
> > available- part of the pd file for users. I have been trying to do
> > this in PD by simply writing at the end of the file and then with the
> > [text] object or any similar go to the section where I would have my
> > meta data. The problem is that pd erases this section when saving the
> > file.
> >
> > thoughts?
>
> Yes. Have a look at help patches of many libraries (for instance zexy
> or osc). They do use meta data by putting comments into a subpatch
> named [pd META]. This has two advantages over what you propose:
>
> * You can edit/add them with Pd
> * You can easily parse them with Pd (with [text], for instance)
>
> netpd uses a similar kind of meta tags for declaring version,
> dependencies and other stuff. The only difference is that the subpatch
> is named [pd NETPD 2 0] (2 0 being the version of the meta data format)
> and it uses message boxes instead of comments. Check [netpd-properties]
> if you're interested in seeing how such a meta tag parser could be
> implemented in Pd.
>
> https://github.com/reduzent/netpd
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>


-- 
José Rafael Subía Valdez
www.jrsv.net
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Meta Data in a PD file

[Roman Haefeli]

On Don, 2016-10-06 at 16:39 +0100, José Rafael Subía Valdez wrote:
> I dont know if it has been discussed, I have searched the archives
> but didnt find anything simliar.
> 
> would there be a way to write a META DATA section at the end of a .pd
> file?
> I guess this is more of a request. But what if there was a META DATA
> section available to record things that would be "binded" (don't know
> if "bound" is the word) to the file. Maybe this could be an open -
> available- part of the pd file for users. I have been trying to do
> this in PD by simply writing at the end of the file and then with the
> [text] object or any similar go to the section where I would have my
> meta data. The problem is that pd erases this section when saving the
> file.
> 
> thoughts? 

Yes. Have a look at help patches of many libraries (for instance zexy
or osc). They do use meta data by putting comments into a subpatch
named [pd META]. This has two advantages over what you propose:

* You can edit/add them with Pd 
* You can easily parse them with Pd (with [text], for instance)

netpd uses a similar kind of meta tags for declaring version,
dependencies and other stuff. The only difference is that the subpatch
is named [pd NETPD 2 0] (2 0 being the version of the meta data format)
and it uses message boxes instead of comments. Check [netpd-properties] 
if you're interested in seeing how such a meta tag parser could be
implemented in Pd.

https://github.com/reduzent/netpd

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Meta Data in a PD file

[José Rafael Subía Valdez]

I dont know if it has been discussed, I have searched the archives but
didnt find anything simliar.

would there be a way to write a META DATA section at the end of a .pd file?
I guess this is more of a request. But what if there was a META DATA
section available to record things that would be "binded" (don't know if
"bound" is the word) to the file. Maybe this could be an open - available-
part of the pd file for users. I have been trying to do this in PD by
simply writing at the end of the file and then with the [text] object or
any similar go to the section where I would have my meta data. The problem
is that pd erases this section when saving the file.

thoughts?

-- 
José Rafael Subía Valdez
www.jrsv.net
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Fred Jan Kraan]

> that sounds good. But I think you sent me the same file as before?
> They are exactly alike.

Just checked, and I did send a newer version, I even added a 0.2 version 
number in the header. Here it is version 0.3.


On 2016-03-25 01:53 AM, João Pais wrote:

Hi,

I tinkered around with tcl, until I think I found a version that suits
my needs exactly:

- I reversed the selection - if {[lsearch $lineList $lineCount] < 0} {
- I commented out line  puts "lines to patch: $lineList", so that the
list of patched lines doesn't get saved with the patch output.


It seems that the patch counts each line that begins with # as a real
line. But since the pd txt format splits lines, it turns out that there
are many lines that don't begin with #N. For example with the 2 objects

#N canvas 1066 230 670 662 gui 0;
#X obj 0 0 cnv 12 400 260 empty \$0-colorh-i empty 20 12 0 14 -220796
-1 0;

there are 3 lines in the text file, but the patch will only count 2.
Adding an incr lineCount after the last "puts $patchLine" does the job
of matching the number of lines in the text file with the line count.


Sorry, the script was counting Pd-lines, not lines in the patch. Not 
much use if you look at the lines in a code-editor. If a line increment 
is done always, you could move it outside the if ...


Counting Pd-lines is useful if you want to correlate objects to the '#X 
connect' lines. But this would break down in case of sub-patches. I made 
another script for this...


Thanks very much, I think this is quite good already. I'll tinker a bit
more to see if I find out how to also process subpatches and messages. I
imagine that adding other if lines it could work.


The newer versions should be better as they prevent #A and #N from being 
corrupted.


Best,

Joao



#!/usr/bin/env tclsh
#
# changeCoords.tcl v0.3
# fjkr...@xs4all.nl

if {$argc < 4} {
error "Usage: tclsh changeCoords.tcl patchName xcoord ycoord line1 ?line2? ..."
}

set patchName [lindex $argv 0]
set xcoord[lindex $argv 1]
set ycoord[lindex $argv 2]
set lineArgCount $argc
set lineList {}

#puts "patchName $patchName; xcoord $xcoord; ycoord $ycoord lineArgCount; $lineArgCount"
# line arguments may be numeric or a numeric range "nn-mm" (inclusive)

for {set start 3} {$lineArgCount > $start} {incr start} {
set arg [lindex $argv $start]
#puts "$start: $arg"
if [regexp {(\d+)-(\d+)} $arg lineRange startLine endLine] {
if {$startLine < $endLine} {
#puts "startLine $startLine; endLine $endLine;;  $lineRange"
for {set line $startLine} {$line <= $endLine} {incr line} {
lappend lineList $line
}
}
} else {
#puts "line $arg"
lappend lineList $arg
}
}

#puts "lines not to patch: $lineList"

set lineCount 1
set f [open $patchName]
while {[gets $f patchLine] >= 0} {
if [regexp {\#[AN] } $patchLine] {
#puts -nonewline "$lineCount: "
puts $patchLine
incr lineCount
continue
}
if [regexp {\#[X] } $patchLine] {
if {[lsearch $lineList $lineCount] == -1} { # >= 0 for matching lines, == -1 for non-matching lines
if [regexp {\#X obj (\d+) (\d+) (.+)} $patchLine allOfLine orgX orgY restOfLine] {
#puts -nonewline "$lineCount: "
puts "#X obj $xcoord $ycoord $restOfLine"
} else {
#puts -nonewline "$lineCount: "
puts $patchLine
}
} else {
#puts -nonewline "$lineCount: "
puts $patchLine
}
} else {
# puts -nonewline "$lineCount: "
 puts $patchLine
}
incr lineCount

}
close $f
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[João Pais]

Hi,

I tinkered around with tcl, until I think I found a version that suits my  
needs exactly:


- I reversed the selection - if {[lsearch $lineList $lineCount] < 0} {
- I commented out line  puts "lines to patch: $lineList", so that the list  
of patched lines doesn't get saved with the patch output.



It seems that the patch counts each line that begins with # as a real  
line. But since the pd txt format splits lines, it turns out that there  
are many lines that don't begin with #N. For example with the 2 objects


#N canvas 1066 230 670 662 gui 0;
#X obj 0 0 cnv 12 400 260 empty \$0-colorh-i empty 20 12 0 14 -220796
-1 0;

there are 3 lines in the text file, but the patch will only count 2.  
Adding an incr lineCount after the last "puts $patchLine" does the job of  
matching the number of lines in the text file with the line count.


Thanks very much, I think this is quite good already. I'll tinker a bit  
more to see if I find out how to also process subpatches and messages. I  
imagine that adding other if lines it could work.


Best,

Joao

changeCoords.tcl
Description: Tcl script
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[João Pais]

HI Fred Jan,

that sounds good. But I think you sent me the same file as before? They
are exactly alike.

I don't want to push it, but I noticed 2 details that I could mention. But
ignore them if you have better things to do:
- since I'm recording the console output of the tcl patch, only now I
noticed that it adds a first line with "lines to patch: 9 36 37 38 39..."
etc. Anyway it is ignored by Pd when loading the file, I only noticed it
by chance when I opened the pd file in a text editor
- I didn't look at the structure of the pd files clearly enough, the lines
starting with "#X restore" and "#X msg" could also be processed, for a
more coherent result.

But anyway, ignore all these if you have more interesting things to do. I
can do any testing anytime for anything - since I can't program on
anything else than Pd, at least it's my way of paying back the price of
free software.

Afaik, there isn't any rasterizer or grid alignment option - you might ask  
Jonathan Wilkes, since he's putting lots of new things into Pd2lork. Or  
maybe the community might be interested in supporting your code to improve  
patching quality - at least it could have an interesting result for you.


Best,

Joao


Hi João,

Changed the behaviour and also added some code that prevents #A and #N
lines from being changed. Make sure you proper test it, because I
didn't. Consider this the price of free software :-).

@Dan: It is Tcl, but I should look into the gui plugin interface to make
it work. And another way of selecting objects as there aren't any line
numbers within Pd. It could be converted to some kind of rasterizer or
align-to-grid option, but that may already exist...

Greetings & success,

Fred Jan


Hi Fred,

I did some testing today when I had some more time. It works great, and
if I use it in a command like  > new.pd, I get the new patch out of  
it.


If I may, I would ask for a small improvement: it would be great if the
processing would be done in the opposite way; that is, all lines with #X
obj are processed, *except* the ones given as arguments. I can also work
with the version you sent me, but for the exercises I'm thinking about,
only an exception of lines will be kept in the original way.

I tried to do it myself, but quickly I came to the conclusion that my
lack of experience with scripting languages doesn't really help me.

Thanks a lot,

Joao



Hi João,

It appeared to be a simple program in Tcl, which you should have, as it
comes with Pd.
The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1
?line2? ...
lineN arguments may be a number or a range, like 12-15.

The patch is currently dumped to the console. Only minimal checking is
done.

If you remove the #'s for the puts "..." lines, you can see some  
interim

results (which will ruin the patch format).

Greetings,

Fred Jan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Fred Jan Kraan]

Hi João,

Changed the behaviour and also added some code that prevents #A and #N 
lines from being changed. Make sure you proper test it, because I 
didn't. Consider this the price of free software :-).


@Dan: It is Tcl, but I should look into the gui plugin interface to make 
it work. And another way of selecting objects as there aren't any line 
numbers within Pd. It could be converted to some kind of rasterizer or 
align-to-grid option, but that may already exist...


Greetings & success,

Fred Jan


Hi Fred,

I did some testing today when I had some more time. It works great, and
if I use it in a command like  > new.pd, I get the new patch out of it.

If I may, I would ask for a small improvement: it would be great if the
processing would be done in the opposite way; that is, all lines with #X
obj are processed, *except* the ones given as arguments. I can also work
with the version you sent me, but for the exercises I'm thinking about,
only an exception of lines will be kept in the original way.

I tried to do it myself, but quickly I came to the conclusion that my
lack of experience with scripting languages doesn't really help me.

Thanks a lot,

Joao



Hi João,

It appeared to be a simple program in Tcl, which you should have, as it
comes with Pd.
The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1
?line2? ...
lineN arguments may be a number or a range, like 12-15.

The patch is currently dumped to the console. Only minimal checking is
done.

If you remove the #'s for the puts "..." lines, you can see some interim
results (which will ruin the patch format).

Greetings,

Fred Jan


#!/usr/bin/env tclsh
#
# changeCoords.tcl v0.2
# fjkr...@xs4all.nl

if {$argc < 4} {
error "Usage: tclsh changeCoords.tcl patchName xcoord ycoord line1 ?line2? ..."
}

set patchName [lindex $argv 0]
set xcoord[lindex $argv 1]
set ycoord[lindex $argv 2]
set lineArgCount $argc
set lineList {}

#puts "patchName $patchName; xcoord $xcoord; ycoord $ycoord lineArgCount; $lineArgCount"
# line arguments may be numeric or a numeric range "nn-mm" (inclusive)

for {set start 3} {$lineArgCount > $start} {incr start} {
set arg [lindex $argv $start]
#puts "$start: $arg"
if [regexp {(\d+)-(\d+)} $arg lineRange startLine endLine] {
if {$startLine < $endLine} {
#puts "startLine $startLine; endLine $endLine;;  $lineRange"
for {set line $startLine} {$line <= $endLine} {incr line} {
lappend lineList $line
}
}
} else {
#puts "line $arg"
lappend lineList $arg
}
}

#puts "lines not to patch: $lineList"

set lineCount 1
set f [open $patchName]
while {[gets $f patchLine] >= 0} {
if [regexp {\#[AN] } $patchLine] {
#puts -nonewline "$lineCount: "
puts $patchLine
incr lineCount
continue
}
if [regexp {\#[X] } $patchLine] {
if {[lsearch $lineList $lineCount] == -1} { # >= 0 for matching lines, == -1 for non-matching lines
if [regexp {\#X obj (\d+) (\d+) (.+)} $patchLine allOfLine orgX orgY restOfLine] {
#puts -nonewline "$lineCount: "
puts "#X obj $xcoord $ycoord $restOfLine"
} else {
#puts -nonewline "$lineCount: "
puts $patchLine
}
} else {
#puts -nonewline "$lineCount: "
puts $patchLine
}
incr lineCount
} else {
puts $patchLine
}
}
close $f
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Dan Wilcox]

If it’s a tcl script, maybe it can be run from a tcl gui plugin form within pd?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Mar 24, 2016, at 5:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Hi Fred,
> 
> I did some testing today when I had some more time. It works great, and if  
> I use it in a command like  > new.pd, I get the new patch out of it.
> 
> If I may, I would ask for a small improvement: it would be great if the  
> processing would be done in the opposite way; that is, all lines with #X  
> obj are processed, *except* the ones given as arguments. I can also work  
> with the version you sent me, but for the exercises I'm thinking about,  
> only an exception of lines will be kept in the original way.
> 
> I tried to do it myself, but quickly I came to the conclusion that my lack  
> of experience with scripting languages doesn't really help me.
> 
> Thanks a lot,
> 
> Joao
> 
> 
>> Hi João,
>> 
>> It appeared to be a simple program in Tcl, which you should have, as it
>> comes with Pd.
>> The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1
>> ?line2? ...
>> lineN arguments may be a number or a range, like 12-15.
>> 
>> The patch is currently dumped to the console. Only minimal checking is  
>> done.
>> 
>> If you remove the #'s for the puts "..." lines, you can see some interim
>> results (which will ruin the patch format).
>> 
>> Greetings,
>> 
>> Fred Jan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[João Pais]

Hi Fred,

I did some testing today when I had some more time. It works great, and if  
I use it in a command like  > new.pd, I get the new patch out of it.


If I may, I would ask for a small improvement: it would be great if the  
processing would be done in the opposite way; that is, all lines with #X  
obj are processed, *except* the ones given as arguments. I can also work  
with the version you sent me, but for the exercises I'm thinking about,  
only an exception of lines will be kept in the original way.


I tried to do it myself, but quickly I came to the conclusion that my lack  
of experience with scripting languages doesn't really help me.


Thanks a lot,

Joao



Hi João,

It appeared to be a simple program in Tcl, which you should have, as it
comes with Pd.
The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1
?line2? ...
lineN arguments may be a number or a range, like 12-15.

The patch is currently dumped to the console. Only minimal checking is  
done.


If you remove the #'s for the puts "..." lines, you can see some interim
results (which will ruin the patch format).

Greetings,

Fred Jan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Fred Jan Kraan]

On 2016-03-22 01:44, João Pais wrote:

Hi Fred,

thanks, that looks promissing. But there is a problem, I'm on windows.
 Does the first line in the patch means that I have to find a unix
computer  to run it? Or can it be run from tcl?


No, it should work on Windows too. The line is only relevant if you want 
to run the script directly as an executable program, without feeding it 
to tclsh. If you start tclsh with the script as the first argument, it 
should work on any platform.


No testing on Windows is done however. There might be some issues with 
the line ending convention (LF vs CR,LF).


But knowing where to find a unix computer is always a good idea ;-),

Fred Jan


Best,

Joao


Hi João,

It appeared to be a simple program in Tcl, which you should have, as 
it

comes with Pd.
The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1
?line2? ...
lineN arguments may be a number or a range, like 12-15.

The patch is currently dumped to the console. Only minimal checking is 
 done.


If you remove the #'s for the puts "..." lines, you can see some 
interim

results (which will ruin the patch format).

Greetings,

Fred Jan



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[João Pais]

Hi Fred,

thanks, that looks promissing. But there is a problem, I'm on windows.  
Does the first line in the patch means that I have to find a unix computer  
to run it? Or can it be run from tcl?


Best,

Joao


Hi João,

It appeared to be a simple program in Tcl, which you should have, as it
comes with Pd.
The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1
?line2? ...
lineN arguments may be a number or a range, like 12-15.

The patch is currently dumped to the console. Only minimal checking is  
done.


If you remove the #'s for the puts "..." lines, you can see some interim
results (which will ruin the patch format).

Greetings,

Fred Jan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Fred Jan Kraan]

Hi João,

It appeared to be a simple program in Tcl, which you should have, as it 
comes with Pd.
The usage is: tclsh changeCoords.tcl patchName xcoord ycoord line1 
?line2? ...

lineN arguments may be a number or a range, like 12-15.

The patch is currently dumped to the console. Only minimal checking is done.

If you remove the #'s for the puts "..." lines, you can see some interim 
results (which will ruin the patch format).


Greetings,

Fred Jan
#!/usr/bin/env tclsh
#

if {$argc < 4} {
error "Usage: tclsh changeCoords.tcl patchName xcoord ycoord line1 ?line2? ..."
}

set patchName [lindex $argv 0]
set xcoord[lindex $argv 1]
set ycoord[lindex $argv 2]
set lineArgCount $argc
set lineList {}

#puts "patchName $patchName; xcoord $xcoord; ycoord $ycoord lineArgCount; $lineArgCount"
# line arguments may be numeric or a numeric range "nn-mm" (inclusive)

for {set start 3} {$lineArgCount > $start} {incr start} {
set arg [lindex $argv $start]
#puts "$start: $arg"
if [regexp {(\d+)-(\d+)} $arg lineRange startLine endLine] {
if {$startLine < $endLine} {
#puts "startLine $startLine; endLine $endLine;;  $lineRange"
for {set line $startLine} {$line <= $endLine} {incr line} {
lappend lineList $line
}
}
} else {
#puts "line $arg"
lappend lineList $arg
}
}

puts "lines to patch: $lineList"

set lineCount 1
set f [open $patchName]
while {[gets $f patchLine] >= 0} {
if [regexp {\#[ANX] } $patchLine] {
if {[lsearch $lineList $lineCount] >= 0} {
if [regexp {\#X obj (\d+) (\d+) (.+)} $patchLine allOfLine orgX orgY restOfLine] {
#puts -nonewline "$lineCount: "
puts "#X obj $xcoord $ycoord $restOfLine"
} else {
#puts -nonewline "$lineCount: "
puts $patchLine
}
} else {
#puts -nonewline "$lineCount: "
puts $patchLine
}
incr lineCount
} else {
puts $patchLine
}
}
close $f
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[João Pais]

Hi Fred,

This functionality can be created in any proper language, but it is hard  
to create a generic solution based on your example. For instance, how do  
you know it will be all the lines except the ones you specify, and do  
you really want all the objects at 100,100 ?


Well, the purpose would be to know because the code makes it happen. Just  
like you know that [expr if($f1 >= 0, 1, -1)] gives out a 1 for numbers  
above and 0, and -1 for numbers below.



Only if you have a large number of patches with the same structure and  
object order it is worthwhile to create a program like you propose to  
patch them. Otherwise a proper code-editor will be as time-efficient in  
changing the patches.


If in this case you just want the [expr] and [hradio] at 100,100 for a  
number of patches a sed* script will do...


Creating a script to convert patches costs effort, so you want it as  
generic as possible. If it can be used only once, a code editor is a  
better way.


With one single patch I have here, there are 8805 lines of code. Is it  
easier to change this by hand than to find a general solution? And if I  
change a couple of objects and want to try this again, should I redo it  
every time?




Fred Jan

*) sed is a unix tool just like grep, only more flexible... Maybe you  
should try to install cygWin, then you get most unix tools on Windows.  
However, prepare for a steep learning curve...


Success,

Fred Jan

P.S. first non-optimized attempt:
cat jmmmp.pd | sed -e 's/#X obj [1-9][0-9]* [1-9]expr/' -e 's/#X obj  
[1-9][0-9]* [1-9][0-9]* expr/#X obj 100 100 hradio/'


I thank you for this, but I think you didn't understand the purpose: I'm  
looking for a general tool. If I needed to edit 5 lines, it would have  
been much faster to do it by hand than to write a mail bothering people  
about it.


Best,

Joao

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Fred Jan Kraan]

Hi João,

This functionality can be created in any proper language, but it is hard 
to create a generic solution based on your example. For instance, how do 
you know it will be all the lines except the ones you specify, and do 
you really want all the objects at 100,100 ?


Only if you have a large number of patches with the same structure and 
object order it is worthwhile to create a program like you propose to 
patch them. Otherwise a proper code-editor will be as time-efficient in 
changing the patches.


If in this case you just want the [expr] and [hradio] at 100,100 for a 
number of patches a sed* script will do...


Creating a script to convert patches costs effort, so you want it as 
generic as possible. If it can be used only once, a code editor is a 
better way.


Fred Jan

*) sed is a unix tool just like grep, only more flexible... Maybe you 
should try to install cygWin, then you get most unix tools on Windows. 
However, prepare for a steep learning curve...


Success,

Fred Jan

P.S. first non-optimized attempt:
cat jmmmp.pd | sed -e 's/#X obj [1-9][0-9]* [1-9]expr/' -e 's/#X obj 
[1-9][0-9]* [1-9][0-9]* expr/#X obj 100 100 hradio/'



Dear list,

I wanted to edit some Pd files so that I can change the coordinates of
*some* lines. For example, if in a pd file there is the content:

#N struct 1164-element float x float y float nr float index float nr-show
float tick-show;
#N canvas 168 80 670 664 gui 0;
#X obj 186 548 textfile;
#X obj 167 328 openpanel;
#X obj 395 878 delay;
#X obj 474 838 expr 60*$f1/$f2*1000;
#X msg 166 668 stop;
#X obj 293 207 hradio 17 1 0 6 \$0-instructions \$0-colord-i empty
0 -6 0 8 -134268 -1 -1 0;

I wanted:
a) in the lines beginning with "#X obj", to change the 2 fields
afterwards to a general value I'll give in the command (e.g. all lines
are changed "#X obj 100 100 ...")

b) to exclude from this operation the line numbers I supply, preferably
in an expression such as "5 10 20-30" etc.

To give an example, with the command "100 100 4-6", the text above would
be changed to

#N struct 1164-element float x float y float nr float index float nr-show
float tick-show;
#N canvas 168 80 670 664 gui 0;
#X obj 186 548 textfile;
#X obj 167 328 openpanel;
#X obj 395 878 delay;
#X obj 100 100 expr 60*$f1/$f2*1000;
#X msg 166 668 stop;
#X obj 100 100 hradio 17 1 0 6 \$0-instructions \$0-colord-i empty
0 -6 0 8 -134268 -1 -1 0;

where all lines starting with #X obj were change, except for lines 4-6.
Further numbers or ranges after 4-6 would indicate other lines to
exclude from the replacement.

I know this isn't a task which can be done in Pd, but much better in a
language such as lua or python. As I don't know any of these languages,
I would appreciate some guidance on how to start, and maybe I could
myself continue the work. Preferably I would like to try it in lua, so
that I could process it in pdlua. But any suggestions are welcome.
Except using grep, as I only have access to an ms-dos console, no bash
or similar ones.

Thanks,

jmmmp

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Edit Pd file to change coordinates. pdlua or other language?

[Daniel Iglesia]

I'd guess it probably _is_ doable in Pd, with some tangled use of the
[text] (using "search" and "set").
When I do this type of manipulation, it's for mobile, so I'm limited to
Objective-C and Java, but if you use Java you could adapt Chris' parser:

https://github.com/chr15m/PdDroidParty/blob/master/src/cx/mccormick/pddroidparty/PdParser.java

to get a java data structure representation. Or, potentially simpler, port
the parsing logic in that file to python or whatever language you want to
use.


On Sat, Mar 19, 2016 at 12:36 PM, João Pais <jmmmp...@gmail.com> wrote:

> Dear list,
>
> I wanted to edit some Pd files so that I can change the coordinates of
> *some* lines. For example, if in a pd file there is the content:
>
> #N struct 1164-element float x float y float nr float index float nr-show
> float tick-show;
> #N canvas 168 80 670 664 gui 0;
> #X obj 186 548 textfile;
> #X obj 167 328 openpanel;
> #X obj 395 878 delay;
> #X obj 474 838 expr 60*$f1/$f2*1000;
> #X msg 166 668 stop;
> #X obj 293 207 hradio 17 1 0 6 \$0-instructions \$0-colord-i empty
> 0 -6 0 8 -134268 -1 -1 0;
>
> I wanted:
> a) in the lines beginning with "#X obj", to change the 2 fields afterwards
> to a general value I'll give in the command (e.g. all lines are changed "#X
> obj 100 100 ...")
>
> b) to exclude from this operation the line numbers I supply, preferably in
> an expression such as "5 10 20-30" etc.
>
> To give an example, with the command "100 100 4-6", the text above would
> be changed to
>
> #N struct 1164-element float x float y float nr float index float nr-show
> float tick-show;
> #N canvas 168 80 670 664 gui 0;
> #X obj 186 548 textfile;
> #X obj 167 328 openpanel;
> #X obj 395 878 delay;
> #X obj 100 100 expr 60*$f1/$f2*1000;
> #X msg 166 668 stop;
> #X obj 100 100 hradio 17 1 0 6 \$0-instructions \$0-colord-i empty
> 0 -6 0 8 -134268 -1 -1 0;
>
> where all lines starting with #X obj were change, except for lines 4-6.
> Further numbers or ranges after 4-6 would indicate other lines to exclude
> from the replacement.
>
> I know this isn't a task which can be done in Pd, but much better in a
> language such as lua or python. As I don't know any of these languages, I
> would appreciate some guidance on how to start, and maybe I could myself
> continue the work. Preferably I would like to try it in lua, so that I
> could process it in pdlua. But any suggestions are welcome. Except using
> grep, as I only have access to an ms-dos console, no bash or similar ones.
>
> Thanks,
>
> jmmmp
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Edit Pd file to change coordinates. pdlua or other language?

[João Pais]

Dear list,

I wanted to edit some Pd files so that I can change the coordinates of  
*some* lines. For example, if in a pd file there is the content:


#N struct 1164-element float x float y float nr float index float nr-show
float tick-show;
#N canvas 168 80 670 664 gui 0;
#X obj 186 548 textfile;
#X obj 167 328 openpanel;
#X obj 395 878 delay;
#X obj 474 838 expr 60*$f1/$f2*1000;
#X msg 166 668 stop;
#X obj 293 207 hradio 17 1 0 6 \$0-instructions \$0-colord-i empty
0 -6 0 8 -134268 -1 -1 0;

I wanted:
a) in the lines beginning with "#X obj", to change the 2 fields afterwards  
to a general value I'll give in the command (e.g. all lines are changed  
"#X obj 100 100 ...")


b) to exclude from this operation the line numbers I supply, preferably in  
an expression such as "5 10 20-30" etc.


To give an example, with the command "100 100 4-6", the text above would  
be changed to


#N struct 1164-element float x float y float nr float index float nr-show
float tick-show;
#N canvas 168 80 670 664 gui 0;
#X obj 186 548 textfile;
#X obj 167 328 openpanel;
#X obj 395 878 delay;
#X obj 100 100 expr 60*$f1/$f2*1000;
#X msg 166 668 stop;
#X obj 100 100 hradio 17 1 0 6 \$0-instructions \$0-colord-i empty
0 -6 0 8 -134268 -1 -1 0;

where all lines starting with #X obj were change, except for lines 4-6.  
Further numbers or ranges after 4-6 would indicate other lines to exclude  
from the replacement.


I know this isn't a task which can be done in Pd, but much better in a  
language such as lua or python. As I don't know any of these languages, I  
would appreciate some guidance on how to start, and maybe I could myself  
continue the work. Preferably I would like to try it in lua, so that I  
could process it in pdlua. But any suggestions are welcome. Except using  
grep, as I only have access to an ms-dos console, no bash or similar ones.


Thanks,

jmmmp

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list