---------- Missatge reenviat ---------- De: *Òscar Martínez Carmona* Data: dijous 31 de gener de 2013 Assumpte: absolute vs relative filepath on oggread~ A: IOhannes m zmölnig zmoelnig@iem.at
In reality now I'm facing some trouble composing the whole file path by concatenating the message I got from [getdir] and the file name via osc, I've tried [glue] and [pack s s] and I get errors on data types and stuff like that (I'm away from computer now so I cannot prompt out) any suggestions??
El dijous 31 de gener de 2013, IOhannes m zmölnig ha escrit:
On 01/31/2013 21:33, IOhannes m zmölnig wrote:
On 01/31/2013 20:50, Andy Farnell wrote:
Not sure what will happen on Windows regarding slash separators (?) Might not be as portable as you hope.
usually this is not a problem. for one thing, Pd (internally) provides ways to convert \ to /.
ah, you probably meant it the other way round: that the filenames via OSC are given backslash delimited ("movies\gross.ogg")
as long as only w32 receivers are involved, this *should* work, but just in case: filenames should preferably be sent with forward slashes ("movies/gross.ogg").
gfasmdr IOhannes
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
On 01/31/2013 10:24 PM, Ãscar MartÃnez Carmona wrote:
---------- Missatge reenviat ---------- De: *Ãscar MartÃnez Carmona* Data: dijous 31 de gener de 2013 Assumpte: absolute vs relative filepath on oggread~ A: IOhannes m zmölnigzmoelnig@iem.at
In reality now I'm facing some trouble composing the whole file path by concatenating the message I got from [getdir] and the file name via osc, I've tried [glue] and [pack s s] and I get errors on data types and stuff like that (I'm away from computer now so I cannot prompt out) any suggestions??
you need to construct a symbol (absolute filename) from a two element list (filename, absolutedirname). [pack] and [glue] (the latter being deprecated in favour of [list append]) and the entire [list] family of objects will help you to create "list"s of "atoms" (aka elements, which can be either symbols or numbers). but they will not help you to create a single symbol out of that list. the simplest way to do that is by using dollarg-expansion in a messagebox.
e.g.
filename | absolute_directory_name | | [pack s s] | | ("list filename absolute_directory_name") | [open $2/$1( | | ("open absolute_directory_name/filename")
gfmdasr IOhannes
I tried that but still got some errors that I don't understand:
doing exactly the same i got this:
[image: Inline image 1]
and if I switch the order I get this: [image: Inline image 2]
The second one gots closer to the goal, but why do I get "symbol" instead of the filename(which arrives correctly as you can see)?
Thanx!
On Fri, Feb 1, 2013 at 9:42 AM, IOhannes zmölnig zmoelnig@iem.at wrote:
On 01/31/2013 10:24 PM, Òscar Martínez Carmona wrote:
---------- Missatge reenviat ---------- De: *Òscar Martínez Carmona*
Data: dijous 31 de gener de 2013 Assumpte: absolute vs relative filepath on oggread~ A: IOhannes m zmölnigzmoelnig@iem.at
In reality now I'm facing some trouble composing the whole file path by concatenating the message I got from [getdir] and the file name via osc, I've tried [glue] and [pack s s] and I get errors on data types and stuff like that (I'm away from computer now so I cannot prompt out) any suggestions??
you need to construct a symbol (absolute filename) from a two element list (filename, absolutedirname). [pack] and [glue] (the latter being deprecated in favour of [list append]) and the entire [list] family of objects will help you to create "list"s of "atoms" (aka elements, which can be either symbols or numbers). but they will not help you to create a single symbol out of that list. the simplest way to do that is by using dollarg-expansion in a messagebox.
e.g.
filename | absolute_directory_name | | [pack s s] | | ("list filename absolute_directory_name") | [open $2/$1( | | ("open absolute_directory_name/**filename")
gfmdasr
IOhannes
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
On 02/01/2013 07:14 PM, Ãscar MartÃnez Carmona wrote:
I tried that but still got some errors that I don't understand:
doing exactly the same i got this:
[image: Inline image 1]
and if I switch the order I get this: [image: Inline image 2]
The second one gots closer to the goal, but why do I get "symbol" instead of the filename(which arrives correctly as you can see)?
i don't understand what you are talking about (but then, i use a mail-reader that doesn't display images; could that be a problem? if so, please describe the problem in words)
hmsdf IOhannes
yeah, lazy me (friday's afternoon...)
if I use: (filename) (absolute_path_directory) I I I I I I [pack s s] I I [open $2/$1(
I got: error: inlet expected symbol but got "(absolute_path_directory)"
and if I switch the order: (absolute_path_directory) (filename) I I I I I I [pack s s] I I [open $1/$2(
the constructed string printed is: "(absolute_path_directory)symbol" <- I get symbol instead of the filename which I'm receiving correctly, so it doesn't open any file.
What am I doing wrong?
Thanx again!
On Sat, Feb 2, 2013 at 12:01 AM, IOhannes zmölnig zmoelnig@iem.at wrote:
On 02/01/2013 07:14 PM, Òscar Martínez Carmona wrote:
I tried that but still got some errors that I don't understand:
doing exactly the same i got this:
[image: Inline image 1]
and if I switch the order I get this: [image: Inline image 2]
The second one gots closer to the goal, but why do I get "symbol" instead of the filename(which arrives correctly as you can see)?
i don't understand what you are talking about (but then, i use a mail-reader that doesn't display images; could that be a problem? if so, please describe the problem in words)
hmsdf
IOhannes
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
On Sat, Feb 02, 2013 at 11:02:35AM +0100, Ãscar MartÃnez Carmona wrote:
yeah, lazy me (friday's afternoon...)
if I use: (filename) (absolute_path_directory) I I I I I I [pack s s] I I [open $2/$1(
filename and path are not symbols here.
Try:
[symbol filename( [symbol /path/to/stuff( | | [pack symbol symbol] | [read $2$1(
----- Original Message -----
From: Andy Farnell padawan12@obiwannabe.co.uk To: Òscar Martínez Carmona xamps23@gmail.com Cc: "pd-list@iem.at" pd-list@iem.at; IOhannes zmölnig zmoelnig@iem.at Sent: Saturday, February 2, 2013 6:49 AM Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~
On Sat, Feb 02, 2013 at 11:02:35AM +0100, Òscar Martínez Carmona wrote:
yeah, lazy me (friday's afternoon...)
if I use: (filename) (absolute_path_directory) I I I I I I [pack s s] I I [open $2/$1(
filename and path are not symbols here.
Try:
[symbol filename( [symbol /path/to/stuff( | | [pack symbol symbol] | [read $2$1(
Or better yet, replace [pack] with [list], then there's no need to add the "symbol" selector to the message boxes.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Not sure if this is off-topic, but pd-l2ork has an external called patch_name (or patchname, can't remember off top my head) which gives you both the current open patch path and filename as two separate symbols. I am sure there might be other similar externals out there, I just failed to locate them...
Best wishes,
Ico
[getdir] in ggee gets the path for the current patch, and levels above it too, like the parent and top-most.
.hc
On 02/02/2013 07:01 PM, Ivica Ico Bukvic wrote:
Not sure if this is off-topic, but pd-l2ork has an external called patch_name (or patchname, can't remember off top my head) which gives you both the current open patch path and filename as two separate symbols. I am sure there might be other similar externals out there, I just failed to locate them...
Best wishes,
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day!
On Sun, Feb 3, 2013 at 2:29 AM, Hans-Christoph Steiner hans@at.or.atwrote:
[getdir] in ggee gets the path for the current patch, and levels above it too, like the parent and top-most.
.hc
On 02/02/2013 07:01 PM, Ivica Ico Bukvic wrote:
Not sure if this is off-topic, but pd-l2ork has an external called patch_name (or patchname, can't remember off top my head) which gives you both the current open patch path and filename as two separate symbols. I
am
sure there might be other similar externals out there, I just failed to locate them...
Best wishes,
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote:
hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day!
If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location).
IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused.
For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with.
(or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way)
Roman
On 02/05/2013 04:30 AM, Roman Haefeli wrote:
On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote:
hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day!
If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location).
IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused.
For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with.
(or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way)
Roman
I agree, relative should be relative to the patch. Please file a bug report on that.
.hc
Never done that before, excuse my idiocy and tell me how! Thanx!
On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On 02/05/2013 04:30 AM, Roman Haefeli wrote:
On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote:
hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day!
If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location).
IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused.
For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with.
(or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way)
Roman
I agree, relative should be relative to the patch. Please file a bug report on that.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
In the Help menu, click on "Report a bug". :-)
.hc
On 02/05/2013 11:08 AM, Òscar Martínez Carmona wrote:
Never done that before, excuse my idiocy and tell me how! Thanx!
On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On 02/05/2013 04:30 AM, Roman Haefeli wrote:
On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote:
hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day!
If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location).
IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused.
For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with.
(or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way)
Roman
I agree, relative should be relative to the patch. Please file a bug report on that.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yay, I've just reported a bug!
On Tue, Feb 5, 2013 at 5:13 PM, Hans-Christoph Steiner hans@at.or.atwrote:
In the Help menu, click on "Report a bug". :-)
.hc
On 02/05/2013 11:08 AM, Òscar Martínez Carmona wrote:
Never done that before, excuse my idiocy and tell me how! Thanx!
On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner <hans@at.or.at wrote:
On 02/05/2013 04:30 AM, Roman Haefeli wrote:
On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote:
hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day!
If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location).
IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started
from.
I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused.
For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with.
(or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way)
Roman
I agree, relative should be relative to the patch. Please file a bug report on that.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name.
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner Sent: Saturday, February 02, 2013 8:30 PM To: pd-list@iem.at Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~
[getdir] in ggee gets the path for the current patch, and levels above it
too,
like the parent and top-most.
.hc
On 02/02/2013 07:01 PM, Ivica Ico Bukvic wrote:
Not sure if this is off-topic, but pd-l2ork has an external called patch_name (or patchname, can't remember off top my head) which gives
you
both the current open patch path and filename as two separate symbols. I
am
sure there might be other similar externals out there, I just failed to locate them...
Best wishes,
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Hans-Christoph Steiner' hans@at.or.at; pd-list@iem.at Cc: Sent: Friday, February 8, 2013 4:18 PM Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~
But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name.
So does canvasinfo: http://article.gmane.org/gmane.comp.multimedia.puredata.devel/11601/match=cl...
with a bang method that prints all the canvas attributes to the console for quick reference. Way easier for the user since each attribute is a method within a single object, with a standard interface (and if more attributes are needed it's trivial to add them without breaking anything). Also easier to develop, as adding another attribute is as simple as adding a method (as opposed to copy/pasting yet another external class, which is the equivalent of copy/pasting subpatches instead of learning to use abstractions in Pd).
-Jonathan
On 02/08/2013 05:32 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Hans-Christoph Steiner' hans@at.or.at; pd-list@iem.at Cc: Sent: Friday, February 8, 2013 4:18 PM Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~
But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name.
So does canvasinfo: http://article.gmane.org/gmane.comp.multimedia.puredata.devel/11601/match=cl...
with a bang method that prints all the canvas attributes to the console for quick reference. Way easier for the user since each attribute is a method within a single object, with a standard interface (and if more attributes are needed it's trivial to add them without breaking anything). Also easier to develop, as adding another attribute is as simple as adding a method (as opposed to copy/pasting yet another external class, which is the equivalent of copy/pasting subpatches instead of learning to use abstractions in Pd).
-Jonathan
This has been added to pd-l2ork git...
Hello
I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use
[number I [string( I [text3d]
but I have no result in the other languages than english or french.
I try to use japanese and no result too ?
I m in OSX 10.7.5
and 43.4 for pd-extended
Do you know where is the problem ?
philippe
Le 10/02/2013 04:18, philippe boisnard a écrit :
Hello
I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use
[number I [string( I [text3d]
but I have no result in the other languages than english or french.
I try to use japanese and no result too ?
I m in OSX 10.7.5
and 43.4 for pd-extended
Do you know where is the problem ?
philippe
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Philippe,
According to : http://fr.wikipedia.org/wiki/Unicode You need to send the good [string( value to [text3d]. As you can see for japanese, it seems to be (in hexa) between 3040 and 30FF. Convert this in decimal and it should be OK. Maybe between 12352 and 12543 ? ;) And if i am right you need a Gem version > 0.93. ++
Jack
Hello
Thank you for your help. I know what you explain to me, but I have a real bug because I have tried with pd 0.42.5 and gem 0.93.3 = no result I have tested too with pd 0.43.4 and gem 0.93.3 and it 's the same. I don't know where is the problem …..
Is that someone who has a mac with OSX 10.7.5 and the same pd-configuration could try?
thank you
philippe
Le 10 févr. 2013 à 23:54, Jack a écrit :
Le 10/02/2013 04:18, philippe boisnard a écrit :
Hello
I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use
[number I [string( I [text3d]
but I have no result in the other languages than english or french.
I try to use japanese and no result too ?
I m in OSX 10.7.5
and 43.4 for pd-extended
Do you know where is the problem ?
philippe
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Philippe,
According to : http://fr.wikipedia.org/wiki/Unicode You need to send the good [string( value to [text3d]. As you can see for japanese, it seems to be (in hexa) between 3040 and 30FF. Convert this in decimal and it should be OK. Maybe between 12352 and 12543 ? ;) And if i am right you need a Gem version > 0.93. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 10/02/2013 17:14, philippe boisnard a écrit :
Hello
Thank you for your help. I know what you explain to me, but I have a real bug because I have tried with pd 0.42.5 and gem 0.93.3 = no result I have tested too with pd 0.43.4 and gem 0.93.3 and it 's the same. I don't know where is the problem …..
Is that someone who has a mac with OSX 10.7.5 and the same pd-configuration could try?
thank you
philippe
Le 10 févr. 2013 à 23:54, Jack a écrit :
Le 10/02/2013 04:18, philippe boisnard a écrit :
Hello
I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use
[number I [string( I [text3d]
but I have no result in the other languages than english or french.
I try to use japanese and no result too ?
I m in OSX 10.7.5
and 43.4 for pd-extended
Do you know where is the problem ?
philippe
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Philippe,
According to : http://fr.wikipedia.org/wiki/Unicode You need to send the good [string( value to [text3d]. As you can see for japanese, it seems to be (in hexa) between 3040 and 30FF. Convert this in decimal and it should be OK. Maybe between 12352 and 12543 ? ;) And if i am right you need a Gem version > 0.93. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Have you tried with another font ? ++
Jack
Hello
Yes Jack, I have tried with all number between 0 and 65335 I have only the french, english and accents (0-300) when I test [string $1( Perhaps it's a problem of pointer in the path ? I don't know.. I have no problem with kanji, when I use firefox or textedit ….. Have you tested on your computer ?
best regards from Japan ….
philippe
PS : for japanese, I do 2 performances in Tokyo : @ the french Institut and @ Ginza apple store Le 11 févr. 2013 à 01:14, philippe boisnard a écrit :
Hello
Thank you for your help. I know what you explain to me, but I have a real bug because I have tried with pd 0.42.5 and gem 0.93.3 = no result I have tested too with pd 0.43.4 and gem 0.93.3 and it 's the same. I don't know where is the problem …..
Is that someone who has a mac with OSX 10.7.5 and the same pd-configuration could try?
thank you
philippe
Le 10 févr. 2013 à 23:54, Jack a écrit :
Le 10/02/2013 04:18, philippe boisnard a écrit :
Hello
I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use
[number I [string( I [text3d]
but I have no result in the other languages than english or french.
I try to use japanese and no result too ?
I m in OSX 10.7.5
and 43.4 for pd-extended
Do you know where is the problem ?
philippe
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Philippe,
According to : http://fr.wikipedia.org/wiki/Unicode You need to send the good [string( value to [text3d]. As you can see for japanese, it seems to be (in hexa) between 3040 and 30FF. Convert this in decimal and it should be OK. Maybe between 12352 and 12543 ? ;) And if i am right you need a Gem version > 0.93. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 10/02/2013 23:23, philippe boisnard a écrit :
Hello
Yes Jack, I have tried with all number between 0 and 65335 I have only the french, english and accents (0-300) when I test [string $1( Perhaps it's a problem of pointer in the path ? I don't know.. I have no problem with kanji, when I use firefox or textedit ….. Have you tested on your computer ?
best regards from Japan ….
philippe
PS : for japanese, I do 2 performances in Tokyo : @ the french Institut and @ Ginza apple store Le 11 févr. 2013 à 01:14, philippe boisnard a écrit :
Hello
Thank you for your help. I know what you explain to me, but I have a real bug because I have tried with pd 0.42.5 and gem 0.93.3 = no result I have tested too with pd 0.43.4 and gem 0.93.3 and it 's the same. I don't know where is the problem …..
Is that someone who has a mac with OSX 10.7.5 and the same pd-configuration could try?
thank you
philippe
Le 10 févr. 2013 à 23:54, Jack a écrit :
Le 10/02/2013 04:18, philippe boisnard a écrit :
Hello
I hav a big problem : I have read thread about the integration of language in text3d but it does not work I try to use
[number I [string( I [text3d]
but I have no result in the other languages than english or french.
I try to use japanese and no result too ?
I m in OSX 10.7.5
and 43.4 for pd-extended
Do you know where is the problem ?
philippe
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Philippe,
According to : http://fr.wikipedia.org/wiki/Unicode You need to send the good [string( value to [text3d]. As you can see for japanese, it seems to be (in hexa) between 3040 and 30FF. Convert this in decimal and it should be OK. Maybe between 12352 and 12543 ? ;) And if i am right you need a Gem version > 0.93. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I just tested this patch (attached) and this font (http://www.ilovegkr.com/mmedia/fonts/epgyosho.ttf) and it works on Pd 0.44.1, Gem 0.93 and Ubuntu 12.04. Have a nice time in Japan. ++
Jack
Hello Jack
Thx I have understood the problem : it was that my all japanese font was not good because, immediatly with your package it was good !!! THXXXXXX ! I can transform my 2 installations with
bes regards and many thanks
philippe Le 11 févr. 2013 à 08:11, Jack a écrit :
Hi
My last problem, it's that I search to translate font character in hex ? somebody had a solution :
I read a .txt file, I want to translate msgfile in hex or an other solution ?
philippe
Le 11 févr. 2013 à 08:21, philippe boisnard a écrit :
Hello Jack
Thx I have understood the problem : it was that my all japanese font was not good because, immediatly with your package it was good !!! THXXXXXX ! I can transform my 2 installations with
bes regards and many thanks
philippe Le 11 févr. 2013 à 08:11, Jack a écrit :
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Phillippe,
I find a web tool ASCII converter. Is this helpful you at the moment?
ASCII converter http://www.mikezilla.com/exp0012.html
I am also curious of your performances at Apple store Ginza and the French Institution. Could you show the information?
Best,
Sei
-- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura
sei@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
2013/2/11 philippe boisnard philemon1@mac.com:
Hi
My last problem, it's that I search to translate font character in hex ? somebody had a solution :
I read a .txt file, I want to translate msgfile in hex or an other solution ?
philippe
Le 11 févr. 2013 à 08:21, philippe boisnard a écrit :
Hello Jack
Thx I have understood the problem : it was that my all japanese font was not good because, immediatly with your package it was good !!! THXXXXXX ! I can transform my 2 installations with
bes regards and many thanks
philippe Le 11 févr. 2013 à 08:11, Jack a écrit :
http://www.ilovegkr.com/mmedia/fonts/epgyosho.ttf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Seiichiro
Thank you for your help, but I want that directly in pd, because I can't create manually all kanji's value…. 1945 officials kanji ….
for my exhibitions and performances : 12-02-2012 I present @ apple store of Ganza @ 19 h >>> translation, a video/audio set programmed with pd and @ The French Insitut during one month I have 2 works : words city (it's a creation which works with web-participation) pd+bash+php and phAUTOmaton.
If you are @ Tokyo, I will be very happy to meet you.
best regards
philippe
Le 11 févr. 2013 à 15:22, Seiichiro MATSUMURA a écrit :
Hi Phillippe,
I find a web tool ASCII converter. Is this helpful you at the moment?
ASCII converter http://www.mikezilla.com/exp0012.html
I am also curious of your performances at Apple store Ginza and the French Institution. Could you show the information?
Best,
Sei
-- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura
sei@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
2013/2/11 philippe boisnard philemon1@mac.com:
Hi
My last problem, it's that I search to translate font character in hex ? somebody had a solution :
I read a .txt file, I want to translate msgfile in hex or an other solution ?
philippe
Le 11 févr. 2013 à 08:21, philippe boisnard a écrit :
Hello Jack
Thx I have understood the problem : it was that my all japanese font was not good because, immediatly with your package it was good !!! THXXXXXX ! I can transform my 2 installations with
bes regards and many thanks
philippe Le 11 févr. 2013 à 08:11, Jack a écrit :
http://www.ilovegkr.com/mmedia/fonts/epgyosho.ttf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura
sei@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ <japan_font2.pd><スクリーンショット 2013-02-11 15.18.44.jpg>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-11 07:37, philippe boisnard wrote:
Hello Seiichiro
Thank you for your help, but I want that directly in pd, because I can't create manually all kanji's value?. 1945 officials kanji ?.
well 1945 is not that much when it comes to computers :-)
anyhow zexy's [atoi] should do that.
fgamsdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-08 22:18, Ivica Ico Bukvic wrote:
But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name.
but only iemgut's [canvasname] allows you to also _rename_ a canvas under the hood. so that when you save or duplicate the patch it will show up under a new name (and possibly functionality).
mdfar IOhannes
iemgut's does everything pd-l2ork does plus it's been written by me :-)
On 2013-02-08 22:18, Ivica Ico Bukvic wrote:
But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name.
but only iemgut's [canvasname] allows you to also _rename_ a canvas under the hood. so that when you save or duplicate the patch it will show up under a new name (and possibly functionality).
mdfar IOhannes
iemgut's does everything pd-l2ork does plus it's been written by me :-)
Now that's a bold statement :-)
BTW, what is the advantage of canvasname? Seems to me that the only reason it exists is because having multiple instances of same abstractions makes it difficult to differentiate between them, which in case of pd-l2ork's preset_hub/preset_name is completely a non-issue.
Best wishes,
Ico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-11 18:31, Ivica Ico Bukvic wrote:
BTW, what is the advantage of canvasname?
the advantage over what? iemguts does not seek to compete with other objects. instead it mainly aims to provide low-level access to the patching system.
Seems to me that the only reason it exists is because having multiple instances of same abstractions makes it difficult to differentiate between them, which in case of pd-l2ork's preset_hub/preset_name is completely a non-issue.
i think you are mistaking [canvasname] for some user-driven feature of pd-l2ork. you might be able to implement such a feature with [canvasname], but it's not already the implementation. (and actually i think that it is not very good at implementing this very feature...)
in practice, i've been using this object to implement an automatic version control system for patching.
fgasdmkr IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Monday, February 11, 2013 12:39 PM Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-11 18:31, Ivica Ico Bukvic wrote:
BTW, what is the advantage of canvasname?
the advantage over what? iemguts does not seek to compete with other objects. instead it mainly aims to provide low-level access to the patching system.
Seems to me that the only reason it exists is because having multiple instances of same abstractions makes it difficult to differentiate between them, which in case of pd-l2ork's preset_hub/preset_name is completely a non-issue.
i think you are mistaking [canvasname] for some user-driven feature of pd-l2ork. you might be able to implement such a feature with [canvasname], but it's not already the implementation. (and actually i think that it is not very good at implementing this very feature...)
in practice, i've been using this object to implement an automatic version control system for patching.
And I use [f]x[+ 1] to count numbers, but I think we've covered the current possibilities for the OP to retrieve the patch directory and patch name.
-Jonathan
fgasdmkr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEZLMcACgkQkX2Xpv6ydvSntACfdUE30J3HKBU196CffckCoEFB qUYAoImVvyuRhmYVfcE5Gx6K9BAunu0b =tXu0 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Ivica Ico Bukvic -
Jack -
Jonathan Wilkes -
philippe boisnard -
Roman Haefeli -
Seiichiro MATSUMURA -
Òscar Martínez Carmona