Yay, I've just reported a bug!
On Tue, Feb 5, 2013 at 5:13 PM, Hans-Christoph Steiner <h...@at.or.at>wrote: > > 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 <h...@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 > >> > > > > > > > -- Òscar Martínez Carmona
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list