[PD] Fwd: absolute vs relative filepath on oggread~

[Hans-Christoph Steiner]

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