[Sugar-devel] csound or olpcsound (was Re: hello and how can IJoin?)

[victor]

Yes, originally this was an XO-fedora only thing. However the
olpcsound 'lightweight' option is actually in the upstream sources
(as a build option). Currently it might be the case that it is i*86
only (not sure how well it would build on other archs). So if
packagers are interested in this, they can avail of that option.

Debian packages of Csound are being maintained by one of our
team, so they should be kept reasonably updated (as the Debian
cycle permits).

Regards

Victor

----- Original Message ----- 
From: "Jonas Smedegaard" <dr at jones.dk>
To: <sugar-devel at lists.sugarlabs.org>
Sent: Wednesday, February 11, 2009 3:32 PM
Subject: Re: [Sugar-devel] csound or olpcsound (was Re: hello and how can 
IJoin?)


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, Feb 11, 2009 at 02:37:17PM +0000, victor wrote:
>>> Actually, your expertise would be needed to get the csound packages
>>> into the distributions. Currently we have the standard Csound package
>>> [1] and the olpcsound [2] package in Fedora. We should decide which
>>> package we should move forward.
>>>
>>> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=76556
>>> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=77007
>>>
>>
>>Good, I am glad to dive in straightaway. This is my opinion:
>>
>>Csound-5.03 [1] is very old, there is actually a csound-5.07,
>>which is much newer. Olpcsound[2] is based on 5.08, the
>>last 'stable' version of  libcsound-5.1.
>>
>>The difference between the two packages is that olpcsound is
>>cut-down and adapted to the requirements of OLPC/XO. Now
>>these might not be the same requirements of sugar (as a platform
>>independent OS), but is smaller and lighter. It does not have any
>>of the CPU intensive DSP code fro spectral processing etc.
>
> Interesting. I was unaware of that optimization issue.
>
> Would it perhaps make sense for Distributions to generically offer
> multiple variants of the csound libraries, with and without
> CPU-intensive processing?
>
> If so, the best approach is to improve upstream CSound build routines to
> compile these library variants, differently named so they can be
> installed concurrently, rather than packagers needing to compile
> everything multiple times and provide conflicting packages.
>
>
> As a much simpler alternative, if you could isolate the patches and/or
> compile flags needed for XO-friendly builds, then packagers could add
> them, either just commented out or enabled through some environment
> flag, for easy package rebuilding by (sub)distros aiming specifically at
> low-end hardware.
>
>
>
> (Your discussion seems Fedora/Redhat-centric to me.  Tell me if I should
> simply keep silent with these more general comments)
>
>
>  - Jonas
>
> - -- 
> * Jonas Smedegaard - idealist og Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>   [x] quote me freely  [ ] ask before reusing  [ ] keep private
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmS740ACgkQn7DbMsAkQLh8zACcCkWi+7EJO0qs1G0UXXZ8ER1l
> HYYAn1tJdPz2WfRiphFiiqYzIGRDvqVL
> =mlsN
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel