There are lots of reasons why being able to use openpanel could be useful. The 'reset' command never seemed to work right for me, so what I like to do is use openpanel to send a path to a [symbol] object, and then bang that when I need to reload. It could also be useful for comparing two .csd files using the same Pd settings; easier to open a different .csd in the same patch than to duplicate the patch and change the csoundapi~ object. But, like I said, I got it working my way in my copy, so I have no complaints. I definitely don't want to suggest a change that would render your existing patches inoperable. -Chuckk On 8/3/07, Julian Peterson wrote: > > Hi Victor, Chuck... > > The current behavior of csoundapi CVS seems to be the best for my > purposes. Rarely do I use csoundapi to open multiple csds within one > patch. I would assume that most would use the object to create > custom interfaces for specific csound orchestras, as I do. For this > purpose, relative paths seems to be the best solution. > > I have not the skills in c to adequately read the behavior of > csoundapi, nor do I know much about the internals of PD. The current > implementation, which I requested of Victor, best matches my uses of > the object. (Thanks Victor-- to my ends it works great!). It might > not be the most "PD" of implementations, however. > > PD has a built-in path mechanism for the locating of objects and > abstractions. A quick test shows that the built-in textfile object > also uses this path mechanism to search for files (ie, the command > [read test.txt( locates the file if it is located in the same dir as > the parent patch or if it is located in any of the paths specified by > the --path command line flag). > > I would think that an ideal implementation of csoundapi would harness > this same built-in mechanism; however, since I don't know the full > details of how this is implemented internally, I have no sense of > weather or not this is difficult or even possible. > > I hate to send more work your way Victor, since I am completely happy > and satisfied with the current solution. It just seems that if there > are to be more changes, it should be to further the object's > compatibility with PD's current system. > > Thanks, all, for your continued work to improve csound. It's perhaps > not said enough how much we all appreciate the developers' time and > devotion. > > JP > > > > On Aug 3, 2007, at 12:11 PM, Victor Lazzarini wrote: > > > But that changes the behaviour of csoundapi~. I have > > done that following advice by Julian Peterson on how > > PD searches path. By the way, with that behaviour you > > can still use full paths, but they are now relative > > to the current directory (so you would do something > > like ../../topdir/csds/etc.csd). > > > > You have reverted basically the old behaviour which > > I was asked to change. > > > > Victor > > > > > > > > > >> > >> > >> I'm proud of myself. Instead of bothering you with > >> something, I fixed it. Sending an "open" message to > >> csoundapi~ would say that > >> /home/chuckk//home/chuckk/newpd.csd was not found. I went > >> into the source and commented out everything about strcpy > >> of curdir->s_name and "/", and changed strcat on the next > >> line to strcpy, in two places (I don't have it in front of > >> me). After trying a few things a few times, it now loads > >> correctly. I don't mind typing a whole path name into the > >> object. > >> > >> -Chuckk > >> > >> > >> On 8/2/07, Victor Lazzarini > >> wrote: > > >>> I'm glad it's fixed. > >>> No worries about bothering me. Nothing much to do > >>> between walks... > >>> > >>> Victor > >>> > >>>> > >>>> > >>>> On 8/2/07, Victor Lazzarini > >>>> wrote: > > >>>>> I think I found the bug: in csoundapi_tilde.c > >>>>> lines 84 & 263 > >>>>> > >>>>> static t_int *csoundapi_perform(int *w) > >>>>> > >>>>> should be > >>>>> > >>>>> static t_int *csoundapi_perform(t_int *w) > >>>>> > >>>>> and line > >>>>> > >>>>> int i, n, end = x->end, run = x->run; > >>>>> > >>>>> should be > >>>>> > >>>>> t_int i, n, end = x->end, run = x->run; > >>>>> > >>>>> I am positive this is the bug (it is A bug in > >>>>> 64bit CPUs, so I expect it to be the cause of > >>>>> your crashes). I can't change in CVS or test it > >>>>> now, will do when I am back to work. > >>>>> > >>>>> Chuck, can you test it for me? > >>>> > >>>> > >>>> You are correct, it works. I see that it has been > >>>> changed in CVS, too. Thanks, Victor, I shan't bother > >>>> you again during your break. I look forward to > >>>> bothering you afterward. > >>>> > >>>> -Chuckk > >>>> > >>> -- > >>> Send bugs reports to this list. > >>> To unsubscribe, send email to > >> csound-unsubscribe@lists.bath.ac.uk > > >> > >> > >> > >> -- > >> http://www.badmuthahubbard.com > >> > > -- > > Send bugs reports to this list. > > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk > > -- > Send bugs reports to this list. > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk > -- http://www.badmuthahubbard.com