Not that you would be able to call into LISP from Csound orcs as you suggest, though that would be cool and is possible via CLM, probably.

Rather, that Common Music or other LISP programs can call Csound as if Csound itself is a LISP package -- because it IS a LISP package.

Since good LISP implementations can accept callbacks from C code, this should mean that with at least some implementations of LISP, Csound can call back into user-written LISP code.

Regards,
Mike

-----Original Message-----
From: Ken 
Sent: Oct 21, 2005 1:29 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Language wrappers & frontends (was: More unasked for changes)

Michael Gogins wrote:

>Thanks for raising the issue of testing. I agree that a beta testing campaign is essential.
>
>I stick to my point about a definite identity, a definite standard set of things expected in a Csound distribution, and that it should include the wrappers. Including the wrappers doesn't prevent anyone from doing anything, even defining other wrappers. It just means that there is a standard set of expectations that Csound 5 can satisfy.
>
>In my view, the whole business is way too complicated, and I am trying my best to make it simpler. I know Istvan is trying to make it simpler also. He just doesn't have the right to unlilaterally determine the appropriate level of simplicity.
>
>If Csound 5 gets decent installers -- something Varga, ffitch, and myself have all worked on -- then it should be the case that most musicians will work from the binary installers. And if that happens, I am sure that we can count on Csound 5's user base growing dramatically.
>
>Regards,
>Mike
>
>-----Original Message-----
>From: Jean Piche 
>Sent: Oct 21, 2005 12:58 PM
>To: csound-devel@lists.sourceforge.net
>Subject: [Cs-dev] Language wrappers & frontends (was: More unasked for changes)
>
>
>
>I just want to make sure I understand the issue properly. Do you 
>suggest that Cs5 would include only certain wrappers for certain 
>languages? If there is a build-to-order branch of the CVS which 
>contains all libs for all wrappers and frontends, you dont think people 
>will build what they want and provide binaries for the rest of us who 
>are too impatient (musicians...)? The installation process for 
>musicians would be simply a matter of choosing the build that contains 
>what each desires, no?
>
>Sorry for the missleading subject line on my previous post. I also wish 
>to applaud Istvan's contribution and hope he will stay.  As an old 
>timer, I can tell you that this is not the first time there are 
>frictions of this kind. Some will recall the initial days of Cs3 dev. 
>Cs5, from what I can see, will be a defining moment in music 
>technology, not just computer music. Much of this will depend how the 
>distro is handled. BTW: is there a systematic beta testing run planned? 
>I mean a systematic beta campaign. I still see errors in Cs5 that date 
>back to Cs3.
>
>j
>
>
>
>__________________________________________
>http://jeanpiche.com
>
>
>On 05-10-21, at 12:31, Michael Gogins wrote:
>
>  
>
>>What you is technically feasible and even common, but it is not ideal. 
>>It complicates the installation process and creates confusion among 
>>musicians. If there is no technical reason not to build the wrappers 
>>into the core library, why not do it? That makes it even easier to 
>>build on to Csound.
>>
>>I've yet to hear a compelling technical reason not to build the 
>>wrappers in. There are no technical obstacles, no run time or install 
>>time dependencies. They will build and work on all the platforms 
>>Csound currently supports -- no question. So, what's the big deal? 
>>Sounds like a question of personal taste, which should not decide such 
>>an issue.
>>
>>In the history of computing, systems that offer too many choices have 
>>suffered grievously. LISP is an excellent example. It lost out to Java 
>>and C++ despite being a superior language conceptually, because Java 
>>(right away) and C++ (eventually) created standards to offer the same 
>>stuff in all environments and on all platforms. LISP is a language of 
>>great power spoken in a mulitude of contending dialects, which 
>>effectively cancel each other out.
>>
>>I don't want this kind of situation to happen in computer music, where 
>>it already happens too much.
>>
>>Suppose the Python interface to Csound is not standardized. Well, I 
>>have one. Someone else might have one too. So far, so good. Then a 
>>user comes along to write a Python composing program using Csound. The 
>>Python interface is not in the standard distribution, so he picks a 
>>Python interface at random. Then another user comes along to write 
>>another Python composing program, and he picks the other Python 
>>interface. Now, the two composing programs can't talk to each other, 
>>which is sad because they might have worked great with each other, and 
>>when the composers talk to each other about using Csound, they find it 
>>harder to understand each other than they would have if the interface 
>>was in the core and it was an automatic decision to just use it.
>>
>>Regards,
>>Mike
>>
>>-----Original Message-----
>>From: Jean Piche 
>>Sent: Oct 21, 2005 11:57 AM
>>To: csound-devel@lists.sourceforge.net
>>Subject: Re: [Cs-dev] Re: More unasked for changes
>>
>>
>>This is the opinion of a high-end user/frontend developper who can roll
>>his own but has developped a sane aversion to the process. The Cs5
>>engine builds easily and i must congratulate everyone for that. If i
>>understand the issue of frontends correctly, ideally, binaries should
>>come in all sorts of mixes for all platforms and be readily available
>>for download.  If i want a CsoundVST option, mixed with a tcl/tk lib, I
>>should be able to get that. If I prefer a LISP interpreter on top, I
>>should be able to have that too.  I know this requires work. This is a
>>community project and i am certain that many people will build from
>>separate libraries to include the options they want.
>>
>>Why not have a barebones engine sit in the distro, along with all
>>libraries necessary to build custom versions. As people build different
>>flavors, have them upload their binaries in a separate branch of the
>>CVS (?). That is pretty much how the old bath ftp site worked and it
>>was manageable.
>>
>>
>>j
>>
>>__________________________________________
>>http://jeanpiche.com
>>
>>
>>
>>-------------------------------------------------------
>>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
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>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
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>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
>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
>
>-------------------------------------------------------
>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
>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>  
>
what exactly does this mean, that i can include lisp code in my orc?

that would be awesome really, as i've been playing a little with cm's 
realtime features.  if you have any experience with kontakt 2 on win, 
there is a scripting  language that runs in each instrument, up to 5 
scripts, basically realtime algorithmic composition.

would other languages be able to use fltk?  i'm thinking of cm realtime 
algorithmic generators complete with gui and presets. 

k


-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/csound-devel





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