[PD] absolute vs relative filepath on oggread~

IOhannes m zmoelnig zmoelnig at iem.at
Thu Jan 31 17:33:12 CET 2013


-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEKnMUACgkQkX2Xpv6ydvRt5wCg0zLhKW6i9xy+xfS3MGWQCdEe
3eMAn0Q4lTul9toq+RnuFL1dlu3Mi4Rt
=/cy4
-----END PGP SIGNATURE-----



More information about the Pd-list mailing list