I have been away for a few days so to day I attempted to get back
uptodate.
gcc -DCSOUND_WITH_API -g -gstabs -O2 -DLINUX -Wall -DPIPES -DHAVE_FCNTL_H -DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_H -DHAVE_SYS_IOCTL_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_CTYPE_H -DHAVE_TERMIOS_H -DHAVE_STRING_H -DHAVE_DIRENT_H -DWINDOWS -DUSE_FLTK -DBETA -I. -IH -I/usr/local/include/python2.3 -I/usr/local/include -I/usr/include -I/usr/X11R6/include -c -o OOps/vpvoc.o OOps/vpvoc.c
gcc -DCSOUND_WITH_API -g -gstabs -O2 -DLINUX -Wall -DPIPES -DHAVE_FCNTL_H -DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_MALLOC_H -DHAVE_SYS_IOCTL_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_CTYPE_H -DHAVE_TERMIOS_H -DHAVE_STRING_H -DHAVE_DIRENT_H -DWINDOWS -DUSE_FLTK -fPIC -DBETA -I. -IH -I/usr/local/include/python2.3 -I/usr/local/include -I/usr/include -I/usr/X11R6/include -c -o Opcodes/OSC.os Opcodes/OSC.c
Opcodes/OSC.c: In function `osc_send_set':
Opcodes/OSC.c:29: structure has no member named `STRARG'
Opcodes/OSC.c:23: warning: `hh' might be used uninitialized in this function
Opcodes/OSC.c: In function `osc_send':
Opcodes/OSC.c:58: structure has no member named `STRARG2'
Opcodes/OSC.c:61: structure has no member named `STRARG2'
Opcodes/OSC.c:61: structure has no member named `STRARG3'
Opcodes/OSC.c:64: structure has no member named `STRARG2'
Opcodes/OSC.c:67: structure has no member named `STRARG2'
Opcodes/OSC.c:70: structure has no member named `STRARG2'
Opcodes/OSC.c:70: structure has no member named `STRARG3'
Opcodes/OSC.c:73: structure has no member named `STRARG2'
Opcodes/OSC.c:76: structure has no member named `STRARG2'
Opcodes/OSC.c:79: structure has no member named `STRARG2'
Opcodes/OSC.c:82: structure has no member named `STRARG2'
Opcodes/OSC.c:82: structure has no member named `STRARG3'
Opcodes/OSC.c:85: structure has no member named `STRARG2'
Opcodes/OSC.c:85: structure has no member named `STRARG3'
Opcodes/OSC.c:88: structure has no member named `STRARG2'
Opcodes/OSC.c:88: structure has no member named `STRARG3'
Opcodes/OSC.c:91: structure has no member named `STRARG2'
Opcodes/OSC.c:91: structure has no member named `STRARG3'
Opcodes/OSC.c:91: structure has no member named `STRARG4'
Opcodes/OSC.c: At top level:
/usr/local/include/lo/lo_endian.h:84: warning: `lo_swap64' defined but not used
scons: *** [Opcodes/OSC.os] Error 1
scons: building terminated because of errors.

What is going on?  This is worse than before the code freeze.  It
seems that things are changing faster than one can develop.  This code
built on Apr 24.  Now I am back to before last weekend.

==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> What is going on?  This is worse than before the code freeze.  It
> seems that things are changing faster than one can develop.  This code
> built on Apr 24.  Now I am back to before last weekend.

There are some changes related to how strings are handled.
In this particular case, OSC.c seems to only use string
arguments, and not multi-rate string/MYFLT types, so you
can fix the file by replacing all uses of p->STRARG with
casting the appropriate opcode argument from MYFLT* to char*.

Note that the 'S' type in opcode entries now only accepts
strings (fortunately, this is exactly what you want in OSC.c),
to allow for i-rate as well, use 'T', and for i/k-rate, use 'U'.
entry1.c and entry2.c are already modified to reflect this
change, as well as some plugin opcodes, but I do not build OSC.c,
so I did not notice these errors.

It is now possible to use simple string variables (of type 'S'
and 'gS' for global) in the orchestra, that's why there are
these changes. Also, string constants are automatically unquoted
- no need to call unquote() - and escape sequences like \n etc.
are converted.


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Does this mean that opcodes with an S type can no longer read soundfiles with a 
numeric extension ("soundin.1", "soundin.2", etc)? That would break a lot of 
older orchs reading soundfiles with that naming scheme, including a lot of the 
examples in the Csound book. It was not a scheme I had much use for, but it had 
its advantages for many who use(d) Csound a lot more than I do!

Richard Dobson



Istvan Varga wrote:

..
> Note that the 'S' type in opcode entries now only accepts
> strings (fortunately, this is exactly what you want in OSC.c),
> to allow for i-rate as well, use 'T', and for i/k-rate, use 'U'.
> entry1.c and entry2.c are already modified to reflect this
> change, as well as some plugin opcodes, but I do not build OSC.c,
> so I did not notice these errors.




-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Istvan" == Istvan Varga  writes:

 Istvan> jpff@codemist.co.uk wrote:
 >> What is going on?  This is worse than before the code freeze.  It
 >> seems that things are changing faster than one can develop.  This code
 >> built on Apr 24.  Now I am back to before last weekend.

 Istvan> There are some changes related to how strings are handled.
 Istvan> In this particular case, OSC.c seems to only use string
 Istvan> arguments, and not multi-rate string/MYFLT types, so you
 Istvan> can fix the file by replacing all uses of p->STRARG with
 Istvan> casting the appropriate opcode argument from MYFLT* to char*.

 Istvan> Note that the 'S' type in opcode entries now only accepts
 Istvan> strings (fortunately, this is exactly what you want in
 Istvan> OSC.c),

No it is not.  There are two arguments that are either numbers or
strings.

 Istvan> to allow for i-rate as well, use 'T', and for i/k-rate, use 'U'.
 Istvan> entry1.c and entry2.c are already modified to reflect this
 Istvan> change, as well as some plugin opcodes, but I do not build OSC.c,
 Istvan> so I did not notice these errors.

When were these changes 
a) discussed
b) announced?

This is an incompatible change which imposes significant requirements
on others.

 Istvan> It is now possible to use simple string variables (of type 'S'
 Istvan> and 'gS' for global) in the orchestra, that's why there are
 Istvan> these changes. Also, string constants are automatically unquoted
 Istvan> - no need to call unquote() - and escape sequences like \n etc.
 Istvan> are converted.

When did you ask about this?

Why did you not check that csound actually compiled before committing
all these changes?  I did an update before a build and commit.  As you
clearly understand what you have done please change tel code so it
works.

==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Dobson wrote:

> Does this mean that opcodes with an S type can no longer read soundfiles 
> with a numeric extension ("soundin.1", "soundin.2", etc)?

No, though you need to use T type (which means S-rate or i-rate) instead of S.
entry1.c and entry2.c are already updated for this change, as well as some of
the plugin opcodes.

> That would break a lot of older orchs reading soundfiles with that naming scheme, 
> including a lot of the examples in the Csound book. It was not a scheme 
> I had much use for, but it had its advantages for many who use(d) Csound 
> a lot more than I do!

As an example, here is how soundin handles file names now (note: p->XSTRCODE
is the equivalent of p->XINCODE for strings; that is, you can test
p->XSTRCODE & 1 to find out if the first input argument is a string,
p->XSTRCODE & 2 for the second arg, p->XSTRCODE & 4 for the third, etc.):

     csound->strarg2name(csound, p->sndin_.sfname, p->ifilno, "soundin.",
                                 p->XSTRCODE);

This function supports all the following:
   * file name as string constant
   * file name as string variable (S-type)
   * string p-field from score
   * strset index
   * "soundin.%d" style file names

So, not only is compatibility with old orchestras preserved, but it is
much easier now to "leap thru std hoops to get file name", to quote from
one of the source files.

For completeness, here is the documentation for csound->strarg2name():

/* create file name from opcode argument (string or MYFLT)      */
/*   ENVIRON *csound:                                           */
/*      pointer to Csound instance                              */
/*   char *s:                                                   */
/*      output buffer, should have enough space; if NULL, the   */
/*      required amount of memory is allocated and returned     */
/*   void *p:                                                   */
/*      opcode argument, is interpreted as char* or MYFLT*,     */
/*      depending on the 'is_string' parameter                  */
/*   const char *baseName:                                      */
/*      name prefix to be used if the 'p' argument is MYFLT,    */
/*      and it is neither SSTRCOD, nor a valid index to strset  */
/*      space.                                                  */
/*      For example, if "soundin." is passed as baseName, file  */
/*      names in the format "soundin.%d" will be generated.     */
/*      baseName may be an empty string, but should not be NULL */
/*   int is_string:                                             */
/*      if non-zero, 'p' is interpreted as a char* pointer and  */
/*      is used as the file name. Otherwise, it is expected to  */
/*      point to a MYFLT value, and the following are tried:    */
/*        1. if the value is SSTRCOD, the string argument of    */
/*           the current score event is used (string p-field)   */
/*        2. if the value, rounded to the nearest integer, is a */
/*           valid index to strset space, the strset string is  */
/*           used                                               */
/*        3. the file name is generated using baseName and the  */
/*           value rounded to the nearest integer, as described */
/*           above                                              */
/*      'is_string' is usually p->XSTRCODE for an opcode with   */
/*      only one string argument, otherwise it is               */
/*      p->XSTRCODE & (1 << (argno - 1))                        */
/*   return value:                                              */
/*      pointer to the output string; if 's' is not NULL, it is */
/*      always the same as 's', otherwise it is allocated with  */
/*      mmalloc() and the caller is responsible for freeing the */
/*      allocated memory with mfree() or csound->Free()         */

char *strarg2name(ENVIRON *csound, char *s, void *p, const char *baseName,
                                    int is_string);


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

>  Istvan> Note that the 'S' type in opcode entries now only accepts
>  Istvan> strings (fortunately, this is exactly what you want in
>  Istvan> OSC.c),
> 
> No it is not.  There are two arguments that are either numbers or
> strings.

Well, then you can use 'T' type for string or i-rate, or 'U' type for
string, i-rate, or k-rate. To find out if an argument is a string or
MYFLT, test p->XSTRCODE & (1 << (argno - 1)) - it is non-zero if the
argument is string. 'argno' is the argument index, starting from 1.

> When were these changes 
> a) discussed
> b) announced?

It was announced yesterday, although there was only one response from
Anthony Kozar, related to string variables - but not constants - having
a fixed (although can be changed from the command line) length.
This definitely is an issue worth discussing - dynamic length string
variables are useful, but are more difficult to handle from opcodes
(not enough to just cast the MYFLT* pointer to char*).

> This is an incompatible change which imposes significant requirements
> on others.

I already changed most opcodes for this, and am working on fixing any
remaining problems. I simply were not aware of your OSC opcode, and it
is not a build target by default, so I could not notice the errors.

> Why did you not check that csound actually compiled before committing
> all these changes?  I did an update before a build and commit.

I did check, just not with all the optional components enabled.

 > As you clearly understand what you have done please change tel code so it
> works.

I will fix OSC.c (unless you did so already) later today.


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Why did you change the semantic?  Why have I to chase after your
changes, which also affect the parser which gets harder to chase a
moving target.  You shoudl have left S alone and added T if you
thought it was necessary.  You have buggered my time, which is
seriuously limited by typing time.
==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

and also since ytopu introduced all these changes it is up to YOU to
change ALL the code not just the bits you like.
==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

We cannot *break*  the   soundin.1 thing!

Dr. B.

on 4/27/05 2:11 PM, Richard Dobson at richarddobson@blueyonder.co.uk wrote:

> Does this mean that opcodes with an S type can no longer read soundfiles with
> a 
> numeric extension ("soundin.1", "soundin.2", etc)? That would break a lot of
> older orchs reading soundfiles with that naming scheme, including a lot of the
> examples in the Csound book. It was not a scheme I had much use for, but it
> had 
> its advantages for many who use(d) Csound a lot more than I do!
> 
> Richard Dobson
> 
> 
> 
> Istvan Varga wrote:
> 
> ..
>> Note that the 'S' type in opcode entries now only accepts
>> strings (fortunately, this is exactly what you want in OSC.c),
>> to allow for i-rate as well, use 'T', and for i/k-rate, use 'U'.
>> entry1.c and entry2.c are already modified to reflect this
>> change, as well as some plugin opcodes, but I do not build OSC.c,
>> so I did not notice these errors.
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: (617) 747-2485   Office Fax: (617) 747-2564
 +  eMail: rboulanger@berklee.edu
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Instrument Catalog @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
________________________________________________________________________



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have now changed OSC.c and committed the new version. It seems to
compile without warnings with GCC 4.0, but I did not test the opcode
(not least because I do not know how it is intended to be used).


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Boulanger wrote:

> We cannot *break*  the   soundin.1 thing!

It is not broken, as already explained.


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi John:

  Although I'm not a developer I do see that the rate of changes can be 
a serious upset. Perhaps it's time to consider the use of a csound-dev 
IRC channel where communications can be much faster than email, 
especially SF email. The turnaround time here is lousy, I'm waiting 
hours or even days to see my messages, putting me out of sync with the 
latest changes and holding me back from tests (especially when time is 
in rather short supply). Frankly, email as a communications medium 
between developers these days is anachronistic. It's great for posting 
things like opcode documentation, but its delays are simply not helping 
the developers to stay abreast of each other's work. Further, email is 
awfully prone to misinterpretation, leaving the reader in suspension 
until clarification arrives. IRC has the advantage of being 
instantaneous and open (more people can communicate at once). The 
#ardour and #lad channels work very well, and I humbly submit that 
cs-dev long ago reached a state where a channel of its own could be an 
appropriate tool.

  Just my two pfennigs, of course.

Best,

dp


jpff@codemist.co.uk wrote:

>and also since ytopu introduced all these changes it is up to YOU to
>change ALL the code not just the bits you like.
>  
>




-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Dave Phillips  writes:

> Perhaps it's time to consider the use of a csound-dev IRC channel
> where communications can be much faster than email, especially SF
> email.

that's a good idea. OTOH, one good thing about mailing lists is that all
discussions are in the history. I mean, if one fixes something, it's
good to have it documented. is it possible to do it with IRC? (I know
one can save the IRC log, but is there a way to do it automatically?)

Pedro Kröger


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id5hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am so non-geeky that I don't even know for sure what an IRC channel is. I have 
always found email to be pretty instantaneous here; but then I don't use web 
portals or whatever to access it, just good-ol' Mozilla. Given the number of 
bees circling the honey-pot,  collisions are inevitable, and I doubt whether 
anything faster than email will result in fewer of them!

Richard Dobson




Pedro Kröger wrote:

> Dave Phillips  writes:
> 
> 
>>Perhaps it's time to consider the use of a csound-dev IRC channel
>>where communications can be much faster than email, especially SF
>>email.
> 
> 
> that's a good idea. OTOH, one good thing about mailing lists is that all
> discussions are in the history. I mean, if one fixes something, it's
> good to have it documented. is it possible to do it with IRC? (I know
> one can save the IRC log, but is there a way to do it automatically?)
> 
...



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Greetings:

  Best is to use both email and IRC for their strengths. It is possible 
to save chat in a logfile, but that's not really its purpose. Chat is 
about fast open dialog, much faster and more transparently open than an 
email list. By open I mean that the dialog can be viewed by all members 
of the chat, unless of course two or more developers wanted to open a 
private line (which is very easy to do). On #lad and #ardour the 
developers are working together in realtime, they can instantly compare 
code and maintain a working dialog.

  Email gets you a possibly archived exchange and a good means for 
presenting lengthier code to non-specific recipients. I think of email 
as deferred dialog, compared to IRC's realtime chat.

Best,

dp


Richard Dobson wrote:

> I am so non-geeky that I don't even know for sure what an IRC channel 
> is. I have always found email to be pretty instantaneous here; but 
> then I don't use web portals or whatever to access it, just good-ol' 
> Mozilla. Given the number of bees circling the honey-pot,  collisions 
> are inevitable, and I doubt whether anything faster than email will 
> result in fewer of them!
>
> Richard Dobson
>
>
>
>
> Pedro Kröger wrote:
>
>> Dave Phillips  writes:
>>
>>
>>> Perhaps it's time to consider the use of a csound-dev IRC channel
>>> where communications can be much faster than email, especially SF
>>> email.
>>
>>
>>
>> that's a good idea. OTOH, one good thing about mailing lists is that all
>> discussions are in the history. I mean, if one fixes something, it's
>> good to have it documented. is it possible to do it with IRC? (I know
>> one can save the IRC log, but is there a way to do it automatically?)
>>




-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id5hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The problem is that we do not work together in real time.  I overlap
with Steven sometimes, but otherwise there is no reasonable
time-meeting.  My Csound development time at present is 0430 to 0800
Universal time.  It also coincides with reading e-mail time. 
  Like Richard Dobson I know nothing about IRC.  Never used it, no
idea how to use it.  man -k shows nothing.  I like e-mail as it allows
time to think, consider the message, refine it.  With my dyslexia
direct typing is usually incomprehensible, while with email I can sit a
spelling checker in line to correct many of the errors.  You will not
see the spelling I have just used for "like", or how long it takes to
spell dyslexia!
==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

>The problem is that we do not work together in real time.  I overlap
>with Steven sometimes, but otherwise there is no reasonable
>time-meeting.  My Csound development time at present is 0430 to 0800
>Universal time.  It also coincides with reading e-mail time.
>
Yes, this is IRC's major drawback. But I think Istvan is located closer 
to your timezone, so it's possible you could communicate with him in 
realtime.

>  Like Richard Dobson I know nothing about IRC.  Never used it, no
>idea how to use it.  man -k shows nothing.
>
IRC is not an application per se, you have to use an IRC client. Odd 
that you guys aren't aware of it, IRC has been around on UNIX since at 
least 1988. On my system I use xchat, it's pretty nice, but there are 
dozens of other IRC clients.

Perhaps the next LAC should devote a workshop to advanced techniques of 
group development. I'm not being facetious: I imagine that many 
developers aren't aware of some of the tools that could help speed up 
and clarify development progress.

>I like e-mail as it allows
>time to think, consider the message, refine it.
>
If only more users actually did just that... ;-)

Again, IRC isn't really about that kind of comm.

>With my dyslexia
>direct typing is usually incomprehensible, while with email I can sit a
>spelling checker in line to correct many of the errors.  You will not
>see the spelling I have just used for "like", or how long it takes to
>spell dyslexia!
>  
>
Understood. However, spelling isn't an issue on IRC either. Maening 
cmoes acrsos eevn wehn vrey bdaly seplled. ;)

Anyway, it's just a helpful tool. If no-one wants to try it I guess 
we'll continue all comm with email. It doesn't matter much to me, except 
I'm still waiting on a fix for the Java problem I had. Steven's 
suggestion (comment out the offending line) allows compilation, but it 
isn't really a fix. Someone on the dev list added the code, so they 
ought to be able to advise regarding the problem. No big deal for me, 
but I'd like to know where the trouble lies.

Best,

dp




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net