Thanx for your reply IOhannnes, I'll check that out later (whenever I got home after work), the weird thing is that with other externals [tabplay~] or [readsf~] that worked just fine, is there something diferent with this one? thanx!

On Wed, Jan 30, 2013 at 7:14 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-01-30 19:07, Òscar Martínez Carmona wrote:

...

Hi list, I'm having some trouble trying to open ogg files with [oggread~] when I send to it the name of the file via OSC. If I use the relative path in the open message [open ../samples/$1( I get these errors:

oggread~: file "/samples/filename.ogg" opened oggread~: error: could not open "/samples/filename.ogg" as an OggVorbis file oggread~: file closed due to error

I can solve the problem providing the whole path in the message or via OSC but, as you can understand, it ain't the most desirable solution!

It is there a bug or am I doing something wrong? I attach the patch for more detail.

what do you get when trying to open the files with relative filenames (without OSC)?

i suspect that you and [oggread~] have different directories they relate the "relative path" to.

fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEJYvMACgkQkX2Xpv6ydvTfggCffkLZTVOM8Qbp8mlobJFNedCq uwoAn38EFv7xaGSUTKUOtKelLgJxlOy8 =j2Ua -----END PGP SIGNATURE-----

---

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

e.g. some objects will try to locate a relative file in any of the search-paths you specified, whereas other's will only try to to find it relative to "their" path (whatever that is [*])

...

[*] i've forgotten but... it's either relative to the path Pd was started in, or relative to the path the main patch lives in, or

And this leads to a subtle gotchya that still catches me out;

The latter path (relative to where the patch lives) only makes sense after the patch has been saved. You can bang your head against a wall looking for errors in patch that _should_ work, and then notice that the canvas name is still "Untitled.pd"

IIRC the console report "file or directory not found" is unhelpful, because it does not distinguish the lack of a relative base path from an actual error in the file system or name. Something like;

Current working directory not set

would be really helpful if that can be trapped earlier.

I grumbled about this a long time ago, and still think it's a worthy cause to debate and establish a coherent "paths policy" within Pd (naming and defaults _as_well_as_ search order (which has been aired before))

cheers, Andy

On Thu, Jan 31, 2013 at 11:18:00AM +0100, IOhannes m zmoelnig wrote:

...

Current working directory not set

but there is _always_ a current working directory. even if your file has not beed saved.

You are right. I am confusing two things worth distinguishing, the current working directory and the path to the saved file. Analogously to other environments, C/Perl/Python etc, the distinction is something like that between the variables

CWD = Initially the directory from which the application was launched, but can change during an invokation

FILE = a path belonging to an asset of application, the path to a script or source module.

I'm not sure the latter exists in Pd, or if it would even be helpful if it did.

probably adding this simple message (at a more informational loglevel than the "file not found" error) would help more: "current working directory is ..." (substitute "..." with the real working directory)

Yes. The console could even prepend a path like Bash $PS, although many would be annoyed by that where the path grows long.

Just thinking aloud at this stage.

Andy

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-01-31 17:19, Òscar Martínez Carmona wrote:

what do you get when trying to open the files with relative filenames (without OSC)?

The same error! Looks that I need to provide the absolute path cause I cannot open the file even if I place it in the same patch's path.

i'm pretty confident that there is a way to open the file via a relative path. (e.g. by placing the files in the "correct" folder).

whether the file is "in the same path" as the patch or somehow relative to it, doesn't matter, as long as you find out what the "base-folder" of [oggread~] is.

I guess the solution will be using [getdir], as I read in a thread similar to this, to dinamically get the patch's path (this app should work in different computers so this is needed).

either use that, or use absolute filenames on OSC. (i don't know which program is sending the OSC-messages and how easy the sender can access this information; also i don't know whether you have one central sender that controls multiple computers with the same filenames (so you don't really know the absolute filename on the sender side...as they are different for each receiver)

Another question I have related to oggread~ is; I'm using it cause, as you can imagine, I can play .ogg files @ 320kbs that weight a quarter the .aif ones weight, but does it take much more cpu process?(aslong as it has to decode the file I supose there must be some computational cost in addition)

yes there is a trade off between time (CPU consumption) and space (memory consumption). in general you can assume that the higher you compress a file, the more CPU-power you will need to decode it. also note, that with some high-bandwidth media, compression can also help to overcome the bandwidth-limitation of your harddisk - this applies mainly to high-res video files, and you shouldn't enounter something similar with ogg files.

anyhow, there is only one way to check whether the additional CPU-power is acceptable in relation to the memory requirements: run the patch on the target computer.

gamsdr IOhannes

On 01/31/2013 20:50, Andy Farnell wrote:

On Thu, Jan 31, 2013 at 05:19:03PM +0100, Òscar Martínez Carmona wrote:

...

I guess the solution will be using [getdir], as I read in a thread similar

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 /. and even microsoft managed to accept paths with forward slashes as if they were backslashes (in their programming API)!

on w32, [openpanel] will return the paths delimited by /

fgamsdr IOhannes