There is no reason why not to incorporate both
behaviours, full-path and relative, so we have
a 'universal' solution. I'll get it to work,
hopefully it will be simple.

Victor

>
>
> 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
>

I have now a version that will use full-paths if
the user starts the filename with / (or with c:, d: etc on
Windows); otherwise it will use relative paths.

In CVS now.

Victor

At 19:02 04/08/2007, you wrote:
>There is no reason why not to incorporate both
>behaviours, full-path and relative, so we have
>a 'universal' solution. I'll get it to work,
>hopefully it will be simple.
>
>Victor
>
> >
> >
> > 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
> >
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

yikes - i'd almost rather use my one ugly line compared to that :)

Thanks for the example though.  Just thought there might be an  
existing opcode.

I'm creating a few examples / tutorials .. so wanted to keep the bar  
low .. but maybe it wouldn't hurt to show off some UDO stuff.

greg

On Aug 21, 2007, at 3:05 PM, Steven Yi wrote:

> Hi Greg,
>
> There's UDO's for this here:
>
> http://www.csounds.com/udo/displayOpcode.php?opcode_id=64
> http://www.csounds.com/udo/displayOpcode.php?opcode_id=94
>
> steven
>
> On 8/21/07, Greg Thompson  wrote:
>> Ok - I'm tired of looking - I've been searching the manual hoping  
>> to find a
>> convenient opcode for converting a MIDI note number into a  
>> frequency such as
>>
>> iPitch   notetohz 60
>>
>> There has to be an existing opcode that handles this type of  
>> request?  I'm
>> just lost amongst the large list right?
>>
>> To do this, I've just been using the following, which is unsightly  
>> at best.
>>
>> iPitch = 8.17579891564 * exp(0.0577622650 * p4)
>>
>>
>> greg
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>

icps cpsmidi --??

At 02:32 PM 8/21/2007, you wrote:
>Ok - I'm tired of looking - I've been searching the manual hoping to 
>find a convenient opcode for converting a MIDI note number into a 
>frequency such as
>
>iPitch   notetohz60
>
>There has to be an existing opcode that handles this type of 
>request?  I'm just lost amongst the large list right?
>
>To do this, I've just been using the following, which is unsightly at best.
>
>iPitch= 8.17579891564 * exp(0.0577622650 * p4)
>
>
>greg

David Mooney:  dmooney@city-net.com
Maxine Heller:  mheller@city-net.com
Opaque Melodies:  www.city-net.com/~moko/

according to the manual - there are no arguments - it just reads from  
internal values.  I want to pass the note number as a p-field, ya  
know?  Either way, it seems the consensus is, I'm on my own to handle  
the conversion - which is fine - but I just wanted to make sure I  
wasn't overlooking something that already existed.  For tutorial  
purposes, its easier just to use opcodes - I think its a clearer form  
of expression.

greg

On Aug 21, 2007, at 6:39 PM, David Mooney/Maxine Heller wrote:

> icps cpsmidi --??
>
> At 02:32 PM 8/21/2007, you wrote:
>> Ok - I'm tired of looking - I've been searching the manual hoping  
>> to find a convenient opcode for converting a MIDI note number into  
>> a frequency such as
>>
>> iPitch   notetohz60
>>
>> There has to be an existing opcode that handles this type of  
>> request?  I'm just lost amongst the large list right?
>>
>> To do this, I've just been using the following, which is unsightly  
>> at best.
>>
>> iPitch= 8.17579891564 * exp(0.0577622650 * p4)
>>
>>
>> greg
>
> David Mooney:  dmooney@city-net.com
> Maxine Heller:  mheller@city-net.com
> Opaque Melodies:  www.city-net.com/~moko/
>
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>