I note that Istvan Varga took it upon himself, without discussion or 
consultation, to remove some functions that I recently contributed to the 
Csound API.

He also edited the csound.lisp file so that it is no longer usable, leaving 
me to fix up his mistakes.

I have, of course, immediately restored the code and I will restore it again 
if I have to, though I am willing to discuss what I am doing, as I have been 
discussing it all along.

It is not proper for one developer, no matter how talented they are or how 
useful their work has proven -- and I freely acknowledge Istvan's worth on 
both counts -- on an open source project such as Csound to unilaterally 
remove or greatly modify the work of other developers.

It also is not proper to work on code without testing it.

The purpose of the work I am now doing, as I have discussed previously here, 
is to expose the Csound API to LISP. I will extend this to expose the API to 
Python, Java, and possibly Lua as well. This code may be built into the 
Csound shared library, or it may be built as a separate shared library, as 
we decide.

As part of this work, I have found that calling functions of the form (int, 
char**) for example in csoundCompile(int argc, char** argv) is not always 
the most convenient from the standpoint of the user of the API and not 
always the easiest to call from a foreign function. Therefore, I added

int csoundCompileCsd(CSOUND* csound, char *filename)
int csoundPerformCsd(CSOUND * csound, char *filename)

With these changes the Csound API is now easily usable directly from CLISP, 
and this binding should work on all CLISP-supported platforms including 
Linux, WIndows, and the Macintosh. Once this is working, I plan to change it 
from CLISP FFI to CFFI or UFFI, which should be usable with other 
implementations of LISP as well.

I also have contributed a set of functions to enable users of the API to 
programmatically build up a CSD file in memory, and especially, to append 
'i' events to the Csound score a line at a time, either as strings, or as 
floating-point pfields.

The purpose of these functions is so that the composer can 'embed' the 
Csound instruments and command-line options directly in the LISP, Python, or 
whatever file that constitutes a pieces. In my experience, this makes it 
harder to lose pieces of what one is working on, and speeds up the working 
process.

Regards,
Mike







-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I changed csound.lisp in an attempt to update it for changes made to
some API functions, but it appears that I should not have tampered
with it.
Your new API functions are redundant, do not add new functionality,
are very limited (do not allow for additional arguments or even compiling
an orc/sco pair instead of a csd), and are not useful for anything other
than saving two lines of code in a host application. I think the API is
better kept clean and minimal without spamming it with redundant functions.
You also broke the binary layout of the CSOUND structure.
I do not really care, though, as I decided not to commit any more code
to the csound5 CVS module for one year or when Csound5 is released,
whichever is later. If people think that I became an old relic that
only holds back the work of others, now there is a chance to do everything
on your own, I will not interfere. Feel free to add anything, rewrite
Csound in C++, integrate wrappers, or whatever you want.
I will still update the manual, and answer questions not related to
development on the lists, but it is time to take another long break
so that I have time to other things.

Michael Gogins wrote:

> I note that Istvan Varga took it upon himself, without discussion or 
> consultation, to remove some functions that I recently contributed to 
> the Csound API.
> 
> He also edited the csound.lisp file so that it is no longer usable, 
> leaving me to fix up his mistakes.
> 
> I have, of course, immediately restored the code and I will restore it 
> again if I have to, though I am willing to discuss what I am doing, as I 
> have been discussing it all along.
> 
> It is not proper for one developer, no matter how talented they are or 
> how useful their work has proven -- and I freely acknowledge Istvan's 
> worth on both counts -- on an open source project such as Csound to 
> unilaterally remove or greatly modify the work of other developers.
> 
> It also is not proper to work on code without testing it.
> 
> The purpose of the work I am now doing, as I have discussed previously 
> here, is to expose the Csound API to LISP. I will extend this to expose 
> the API to Python, Java, and possibly Lua as well. This code may be 
> built into the Csound shared library, or it may be built as a separate 
> shared library, as we decide.
> 
> As part of this work, I have found that calling functions of the form 
> (int, char**) for example in csoundCompile(int argc, char** argv) is not 
> always the most convenient from the standpoint of the user of the API 
> and not always the easiest to call from a foreign function. Therefore, I 
> added
> 
> int csoundCompileCsd(CSOUND* csound, char *filename)
> int csoundPerformCsd(CSOUND * csound, char *filename)
> 
> With these changes the Csound API is now easily usable directly from 
> CLISP, and this binding should work on all CLISP-supported platforms 
> including Linux, WIndows, and the Macintosh. Once this is working, I 
> plan to change it from CLISP FFI to CFFI or UFFI, which should be usable 
> with other implementations of LISP as well.
> 
> I also have contributed a set of functions to enable users of the API to 
> programmatically build up a CSD file in memory, and especially, to 
> append 'i' events to the Csound score a line at a time, either as 
> strings, or as floating-point pfields.
> 
> The purpose of these functions is so that the composer can 'embed' the 
> Csound instruments and command-line options directly in the LISP, 
> Python, or whatever file that constitutes a pieces. In my experience, 
> this makes it harder to lose pieces of what one is working on, and 
> speeds up the working process.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think that Michael made very clear in his email that your work and your
talents are greatly appreciated.  And I think that all of us feel this way!!
We would really hate to lose you (again!) over a little disagreement.

There has been a lot of discussion recently over many proposed features and
that is great!  Discussion helps everyone decide how best to proceed and
implement changes.  But it is important to remember that this is a community
project with multiple developers.  That means that decisions will not always
go the way of a single person.  And certainly, undoing the newly-committed
work of another developer without discussion is a practice to be avoided.

Please stay with us, Istvan.  Csound will benefit in so many ways if you do!

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/

Istvan Varga wrote on 10/18/05 5:07 AM:

> I do not really care, though, as I decided not to commit any more code
> to the csound5 CVS module for one year or when Csound5 is released,
> whichever is later. If people think that I became an old relic that
> only holds back the work of others, now there is a chance to do everything
> on your own, I will not interfere. Feel free to add anything, rewrite
> Csound in C++, integrate wrappers, or whatever you want.
> I will still update the manual, and answer questions not related to
> development on the lists, but it is time to take another long break
> so that I have time to other things.



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> I think that Michael made very clear in his email that your work and your
> talents are greatly appreciated.  And I think that all of us feel this way!!
> We would really hate to lose you (again!) over a little disagreement.
> 
> There has been a lot of discussion recently over many proposed features and
> that is great!  Discussion helps everyone decide how best to proceed and
> implement changes.

Well, good luck with implementing whatever you want. I certainly will
not interfere.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 18, 2005, at 5:07 AM, Istvan Varga wrote:

> (do not allow for additional arguments or even compiling
> an orc/sco pair instead of a csd)

I had been wondering how that would've been possible given the initial 
description ...

> I think the API is
> better kept clean and minimal without spamming it with redundant 
> functions.

!!

> I do not really care, though, as I decided not to commit any more code
> to the csound5 CVS module for one year or when Csound5 is released,
> whichever is later.

At least a sense of humor is maintained throughout it all.

>  If people think that I became an old relic that
> only holds back the work of others, now there is a chance to do 
> everything
> on your own, I will not interfere.

I'm not sure if I'm the only one who feels this way but I certainly 
acknowledge the role of certain developers like John ffitch for example 
to effectively 'veto' ideas that potentially enter the CVS module. It 
is only with this kind of monitoring that we can ensure maximum 
efficiency in development and an unparalleled consistency that would 
not otherwise be possible.

Hasn't Csound historically always had the need for "gatekeepers"?

>  Feel free to add anything, rewrite
> Csound in C++

OH NOES!!!!!!

> but it is time to take another long break
> so that I have time to other things.

And so the cyclic nature of things continues. I hope you can get some 
good rest in the meantime, you've sure earned it.


... I don't know about anyone else but I've just made about a dozen 
archived copies of the sources from now to last week! Hehe!


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net