| It depends on whether the various packages are part of the canonical distribution of Csound 5. If they are, then it is a logistical nightmare. If they are not, but are separate projects based on the Csound API, then it is not a logistical nightmare.
However, for external developers to use the Csound API without compiling Csound themselves, the Csound API needs to be fairly stable. Ideally, it would become a standard package included with many distributions of the operating system.
One of the reasons that I contributed CsoundVST to the canonical Csound 5 package is that the API kept changing and breaking CsoundVST on me. In fact, I am not sure whether the API is stable enough yet to base external projects on without ongoing version conflicts. Realistically, Csound 5 will have to be out of beta before the API can be considered stable.
Nevertheless, I would like to see people try to use the API for external projects anyway, because only such uses will expose problems and gaps with the API so that they can be fixed.
Doing external projects with Python is easier, because the Python binding itself is part of the Csound 5 build system, and a Python API is more loosely bound than a C or C++ API.
-----Original Message-----
From: Iain Duncan
Sent: Mar 24, 2005 4:29 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Broken again
That is a dangerous assumption. We just did a live techno show last
night with nothing but csound, and zero screen output. The philosophy
behind my software design for my real time rig is that everything should
be controllable from midi controllers, and that if I need to reach for a
mouse or look at a screen, then the interface is too slow. The computer
sat on the floor.
That said, I think the FLTK stuff is cool, but is there any reason we
could not have various packages, ie csound, csound + FLTK, etc? Would
that just wind up being a logisitical nightmare? We can already compile
it without fltk and python, etc so what about binary releases that are
similar?
Iain
Art Hunkins wrote:
> On-screen graphic widgets - such as FLTK offers - are well-nigh essential
> for real-time Csound. So much so that unless FLTK or some other
> cross-platform graphic capability were included in Csound5, we'd be pretty
> much saying "no" to real-time usage.
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Michael Gogins"
> To:
> Sent: Thursday, March 24, 2005 9:34 AM
> Subject: Re: [Cs-dev] Broken again
>
>
>
>>Your point about libary compatibility for precompiled packages is in
>
> principle correct. This is a well-known problem and the Linux community is
> working to address it with ABI standards. Nevertheless the problem is not
> going away very soon.
>
>>However, this is all somewhat theoretical. What are people's actual
>
> experiences with installing Csound 5 with precompiled C++ on different
> versions of Linux? I'm not talking about CsoundVST here, but about
> widgets.cpp, fluidOpcodes, and cs4vst.
>
>>Of course, I am always running csound 5 on the system that compiled it. On
>
> Linux and Unix, I think it is considered acceptable to distribute a package
> in the form of source code and expect the user to compile it, which resolves
> this problem.
>
>>However, I don't mean to minimize the problem. Users increasingly expect
>
> precompiled packages, and especially for musicians this would be a big plus.
>
>>I initially opposed having the FLTK widgets in the Csound distribution,
>
> but I changed my mind because so many people seemed to find them useful or
> even essential. I would not oppose their removal if the Csound 5 community
> mostly agreed to remove them.
>
>>My points about bugs and speed are separate issues.
>>
>>-----Original Message-----
>>From: vanDongen/Gilcher
>>Sent: Mar 24, 2005 5:53 AM
>>To: csound-devel@lists.sourceforge.net
>>Subject: Re: [Cs-dev] Broken again
>>
>>On Tuesday 22 March 2005 15:27, Michael Gogins wrote:
>>
>>
>>>In my view, Csound would contain fewer bugs and run slightly faster if
>
> it
>
>>>were coded entirely in C++. This view is based on experience and
>>>experiments, not opinion. I am prepared to show code samples and
>>>experimental results to support this view. I would of course be very
>>>interested to review code samples and experimental results that
>
> demonstrate
>
>>>the opposite.
>>>
>>
>>My experience is not very extensive, so please correct me if I am wrong.
>>The biggest problem I have seen with C++ is binary incompatability
>
> between
>
>>libraries and applications using them. This is actually not that much of a
>>problem for me, just the nuisance that upgrading the compiler means
>>recompiling all my C++ libraries. And I don't upgrade my compiler that
>>often :)
>>
>>But for distributing binaries of programs using a shared libcsound it is a
>>real problem. The program won't run if it was compiled for a libcsound
>>compiled differently. Even a different optimization flag will break binary
>>compatibility I think. The only solution is to distribute a statically
>
> linked
>
>>private copy of libcsound with your application.
>>So I think that the ambition of csound5 as a platform independent library
>
> is
>
>>best served by it being pure C.
>>
>>(And yes, I think including widgets in core Csound5 was/is a mistake. For
>
> one
>
>>thing it assumes that csound will only be run on general purpose pc's, and
>>that as long as you support windows, Mac and linux you are cross platform.
>
> My
>
>>cell phone has a 400 MHz processor and stereo sound. Csound should run on
>>that, and it will but without the widgets. Including C++ and widgets in
>
> the
>
>>core csound, will just create a forks for other uses. )
>>
>>Gerard
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>>Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>>Embedded(r) & Windows Mobile(tm) platforms, applications & content.
>
> Register
>
>>by 3/29 & save $300
>
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
>>Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
>>Embedded(r) & Windows Mobile(tm) platforms, applications & content.
>
> Register
>
>>by 3/29 & save $300
>
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
>
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |