<div dir="ltr">Yay, I've just reported a bug! <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 5:13 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@at.or.at" target="_blank">hans@at.or.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In the Help menu, click on "Report a bug". :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
.hc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 02/05/2013 11:08 AM, ̉scar Martínez Carmona wrote:<br>
> Never done that before, excuse my idiocy and tell me how!<br>
> Thanx!<br>
><br>
><br>
> On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner <<a href="mailto:hans@at.or.at">hans@at.or.at</a>>wrote:<br>
><br>
>> On 02/05/2013 04:30 AM, Roman Haefeli wrote:<br>
>>> On Mon, 2013-02-04 at 19:58 +0100, ̉scar Martínez Carmona wrote:<br>
>>>> hey, still having problems with that, by now I'm doing it with the<br>
>>>> absolute filepath... maybe the solution it'll be making the main<br>
>>>> applicattion finding out the f*cking path and sending the whole thing<br>
>>>> to pd via OSC, or maybe trying it another day!<br>
>>><br>
>>> If I am not mistaken, it hasn't been mentioned yet (though IOhannes<br>
>>> assumed it very early) in this thread that [oggread~ ] oddly reads<br>
>>> relative to Pd's start location (unlike many other classes like<br>
>>> [textfile] or [readsf~ ] which read relative to the patch's location).<br>
>>><br>
>>> IMHO, this makes it very difficult for a patch writer to use relative<br>
>>> paths as the patch doesn't have any notion of where Pd was started from.<br>
>>> I consider the whole idea of reading relative to Pd's start location<br>
>>> flawed. A similar case is the 'open patch.pd path' message to [s pd].<br>
>>> Also this one reads relative to Pd's start location. However,<br>
>>> considering that it was implemented this way, because it probably<br>
>>> originates from the '-open' commandline flag, where it makes sense to<br>
>>> use a path relative to the current working directory for loading a<br>
>>> patch, this one is excused.<br>
>>><br>
>>> For you, this means if your OSC application knows where Pd was started<br>
>>> from, you need to make it use a path relative to that location.<br>
>>> Otherwise you you're left with using absolute paths. When dealing with<br>
>>> objects like [oggread~], I'd go for absolute paths, it's just seems<br>
>>> safer and saner to deal with.<br>
>>><br>
>>> (or someone fixes [oggread~ ], which I even wouldn't consider to break<br>
>>> backwards compatibility as the current implementation doesn't really<br>
>>> allow to use relativ paths in meaningful way)<br>
>>><br>
>>> Roman<br>
>><br>
>> I agree, relative should be relative to the patch. Please file a bug<br>
>> report on<br>
>> that.<br>
>><br>
>> .hc<br>
>><br>
>> _______________________________________________<br>
>> <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
>> UNSUBSCRIBE and account-management -><br>
>> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>><br>
><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>̉scar Martínez Carmona<br>
</div>