Re: Why can't i access /dev/dsp or /dev/snd on my XO
What you say does not make any sense to me. The MIDI standard is *one* of many, and in fact the poorest of them all. Besides Csound is probably the most used computer music language with composers of Computer Music and its score an integral part of it. But it is not the only way that can be used to run it: MIDI, OSC, API event calls, etc., are also possible. If anything we should promote better standards than limit ourselves to a very poor one. Victor - Original Message - From: Albert Cahalan [EMAIL PROTECTED] To: victor [EMAIL PROTECTED] Cc: devel@lists.laptop.org Sent: Sunday, January 20, 2008 1:29 AM Subject: Re: Why can't i access /dev/dsp or /dev/snd on my XO On Jan 19, 2008 4:33 PM, victor [EMAIL PROTECTED] wrote: I can't speak for TamTam because I am not involved in their design details, but I can say this, Csound's standard score preceeds MIDI by at least a decade (or two if you consider where it came from). It is much more flexible to convey musical data than MIDI. There are MIDI to csound score converters, but that is beside the point, because Csound can play MIDI files directly, receive realtime MIDI data and even output it. There is no problem whatsoever, with the proper instruments, Csound will be a MIDI synthesizer like any other. The main thing is, that it is not limited to it (thank goodness...). How about showing some support for standards by dropping the non-standard stuff? You can #ifdef it. Maybe you can even save a few bytes. If you really must, you can embed the non-standard stuff into a MIDI file. It's better to avoid non-standard stuff entirely of course, and any extended MIDI file had better play decently on a standard MIDI player. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
Perhaps you are referring to the language rather than the API, when you say it is ghastly. The API is quite neat. I don't have any problems with the language, but some people don't like it. Perhaps you might be interested in looking at the things I am doing to integrate Csound to Sugar a bit more. If so, drop me a note. Victor - Original Message - From: M. Edward (Ed) Borasky [EMAIL PROTECTED] To: Albert Cahalan [EMAIL PROTECTED] Cc: victor [EMAIL PROTECTED]; devel@lists.laptop.org Sent: Sunday, January 20, 2008 4:25 AM Subject: Re: Why can't i access /dev/dsp or /dev/snd on my XO Albert Cahalan wrote: On Jan 19, 2008 4:33 PM, victor [EMAIL PROTECTED] wrote: I can't speak for TamTam because I am not involved in their design details, but I can say this, Csound's standard score preceeds MIDI by at least a decade (or two if you consider where it came from). It is much more flexible to convey musical data than MIDI. There are MIDI to csound score converters, but that is beside the point, because Csound can play MIDI files directly, receive realtime MIDI data and even output it. There is no problem whatsoever, with the proper instruments, Csound will be a MIDI synthesizer like any other. The main thing is, that it is not limited to it (thank goodness...). How about showing some support for standards by dropping the non-standard stuff? You can #ifdef it. Maybe you can even save a few bytes. If you really must, you can embed the non-standard stuff into a MIDI file. It's better to avoid non-standard stuff entirely of course, and any extended MIDI file had better play decently on a standard MIDI player. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel One of the main reasons I got an XO was because it has CSound. It's a ghastly API, but it's been around for years and there are thousands of working instruments! There's a huge book on it, and I doubt very seriously if anyone will ever come up with a digital sound analysis and synthesis tool set as comprehensive without investing a lot of effort re-inventing a bunch of wheels, levers, inclined planes and such. By the way -- I've been meaning to check to see if this is in Trac, but the csound-manual and csound-tutorial RPMs in the repository appear to be empty. I can install them, but there isn't anything on the machine after I do. I'm also attempting to get some of the Planet CCRMA software loaded on the system. At this point, all I really want is Common Music -- I don't need another synthesizer since I have CSound, and I don't need a music notation program. If anyone else has already done this, I'd love to hear about it. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
[EMAIL PROTECTED] writes: DatabaseVersionError: Flint version file /media/2FD2-5097/.olpc.store/index/iamflint is version 200709120 but I only understand 200706140 This will be because the Xapian package was accidentally updated to 1.0.4 recently, then your database was updated with this version which automatically upgrades the format, then the Xapian package version was dropped back to 1.0.2, which now can't read the upgraded database. The easiest fix is probably to just rebuild the database. Cheers, Olly ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
On Sun, 20 Jan 2008, Olly Betts wrote: [EMAIL PROTECTED] writes: DatabaseVersionError: Flint version file /media/2FD2-5097/.olpc.store/index/iamflint is version 200709120 but I only understand 200706140 This will be because the Xapian package was accidentally updated to 1.0.4 recently, then your database was updated with this version which automatically upgrades the format, then the Xapian package version was dropped back to 1.0.2, which now can't read the upgraded database. The easiest fix is probably to just rebuild the database. yep, doing a rm -r of .olpc.store fixed the problem David Lang Cheers, Olly ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
It's not a matter of trying to get a non-standard format across. Not all; it is a matter of supporting more possibilities. Besides, as I pointed out, MIDI will play alright on Csound, even if it is a poor way of conveying musical data. But hey, if MIDI looks damn good to you, it is worthless trying to say anything else. Good luck. Victor - Original Message - From: Albert Cahalan [EMAIL PROTECTED] To: victor [EMAIL PROTECTED]; devel@lists.laptop.org Sent: Sunday, January 20, 2008 10:18 AM Subject: Re: Why can't i access /dev/dsp or /dev/snd on my XO On Jan 20, 2008 3:27 AM, victor [EMAIL PROTECTED] wrote: What you say does not make any sense to me. The MIDI standard is *one* of many, and in fact the poorest of them all. Besides Csound is probably the most used computer music language with composers of Computer Music and its score an integral part of it. I know every developer wants to believe that their own file format is a standard (and a good one too!), but come on now. I went looking for stuff that supports csound. I found **one** program, about 5 wrappers (at least one of which also supported MIDI), and **zero** hardware. The situation with MIDI is radically different; there are a tremendous number of MIDI programs and devices. Perhaps it will be more obvious this way: Notice that the XO ships with a paint program. Suppose that the author invented a nifty new image format. Would it be good to use this format? Notice that the XO ships with a word processor. This word processor could use RTF, OpenDocument, OOXML, TeX, *roff, XHTML... or a custom format that the authors just happen to have invented. What do you think, go with the custom format? Notice that the XO lets you record sound. The most popular unpatented format was used. The authors could have invented their own sound format and used that though. See any problems with doing that? But it is not the only way that can be used to run it: MIDI, OSC, API event calls, etc., are also possible. Excellent. You're ready to drop the non-standard stuff. If anything we should promote better standards than limit ourselves to a very poor one. MIDI looks damn good to me. If you really think you have it beat though, go get an RFC and an ISO standard. Get multiple major hardware manufacturers to start building your new standard into their hardware. See if you can get Microsoft and Apple to follow. Then maybe it will be time to begin the process of slowly saying goodbye to MIDI. Only then does the format belong on the XO. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
Ok, the problem is that by mistake some unstable builds had a too new version of xapian. We reverted to the known-good older version but it cannot read the indexes created or modified by the later version. Just do this in the terminal with the SD card mounted: mv /media/2FD2-5097/.olpc.store /media/2FD2-5097/.olpc.store.bk After rebooting, the SD card should be correctly recognized by the Journal. Tomeu On Sat, 2008-01-19 at 18:24 -0800, [EMAIL PROTECTED] wrote: similar effects, but what I'm seeing is after a full power cycle. I'm not doing a suspend attached is the sugar logfile David Lang On Sat, 19 Jan 2008, Tomeu Vizoso wrote: Date: Sat, 19 Jan 2008 20:02:02 -0500 From: Tomeu Vizoso [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: New update.1 build 682 Hi, looks like you have found http://dev.laptop.org/ticket/4013 . Could you check, please? Should work in latest joyride builds. Thanks, Tomeu On Sat, 2008-01-19 at 18:00 -0800, [EMAIL PROTECTED] wrote: sorry for the delay in responding (I've been traveling for the last week) attached is the messages file, it looks like the system is trying to unmount the SD card immediatly after boot (2 seconds) I'll enable the sugar debugging and go into the journal immediatly after boot and then see if there is anything interesting there. I'll be upgrading to a new build as soon as the RC is released. David Lang On Wed, 16 Jan 2008, Tomeu Vizoso wrote: Date: Wed, 16 Jan 2008 10:29:25 -0500 From: Tomeu Vizoso [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: New update.1 build 682 Can you give some more details? Particularly, see http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets and also /var/log/messages would be of interest. Thanks, Tomeu On Wed, 2008-01-16 at 07:18 -0800, [EMAIL PROTECTED] wrote: I can't get the journal to see the SD card with this build. I can see it from the command line just fine. David Lang On Tue, 15 Jan 2008, Build Announcer Script wrote: Date: Tue, 15 Jan 2008 15:00:03 -0500 (EST) From: Build Announcer Script [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: New update.1 build 682 http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build682/ -Paint-15.xo +Paint-17.xo -Read-38.xo +Read-40.xo -Record-49.xo +Record-50.xo -Terminal-5.xo +Terminal-8.xo -Web-83.xo +Web-84.xo +bash.i386 0:3.2-19.fc7 -bash.i386 0:3.2-9.fc7 -gnash.i386 0:0.8.1-1.olpc2 +gnash.i386 0:0.8.1-2.olpc2.20071226cvs -gnash-plugin.i386 0:0.8.1-1.olpc2 +gnash-plugin.i386 0:0.8.1-2.olpc2.20071226cvs -hulahop.i386 0:0.4.0-1.olpc2 +hulahop.i386 0:0.4.0-2.olpc2 -initscripts.i386 0:8.54.1-15.olpc2 +initscripts.i386 0:8.54.1-17.olpc2 -libabiword.i386 0:2.6.0.svn20071106-1 +libabiword.i386 0:2.6.0.svn20071127-1 -libabiword-plugins.i386 0:2.6.0.svn20071106-1 +libabiword-plugins.i386 0:2.6.0.svn20071127-2 -libxml2.i386 0:2.6.29-1.fc7 +libxml2.i386 0:2.6.31-1.fc7 -libxml2-python.i386 0:2.6.29-1.fc7 +libxml2-python.i386 0:2.6.31-1.fc7 -mingetty.i386 0:1.07-5.2.2 +mingetty.i386 0:1.07-9.olpc2 -ohm.i386 0:0.1.1-6.1.20080102git.fc7 +ohm.i386 0:0.1.1-6.3.20080102git.fc7 -olpc-utils.i386 0:0.63-1.olpc2 +olpc-utils.i386 0:0.63-2.olpc2 -pyabiword.i386 0:0.6.0.svn20071106-1 +pyabiword.i386 0:0.6.0.svn20071127-1 -rainbow.noarch 0:0.7.6-1.olpc2 +rainbow.noarch 0:0.7.8-1.olpc2 -sugar-evince.i386 0:2.20.0-4.olpc2 +sugar-evince.i386 0:2.20.1.1-1.olpc2 -sugar-evince-python.i386 0:2.20.0-4.olpc2 +sugar-evince-python.i386 0:2.20.1.1-1.olpc2 -sugar.i386 0:0.75.7-1 +sugar.i386 0:0.75.8-1 -totem.i386 0:2.18.2-11 +totem.i386 0:2.18.2-12 -totem-mozplugin.i386 0:2.18.2-11 +totem-mozplugin.i386 0:2.18.2-12 -totem-plparser.i386 0:2.18.2-11 +totem-plparser.i386 0:2.18.2-12 -xkeyboard-config.noarch 0:1.1-7.20071130cvs.olpc2 +xkeyboard-config.noarch 0:1.1-8.20071130cvs.olpc2 -xulrunner.i386 0:1.9-0.beta1.9.olpc2 +xulrunner.i386 0:1.9-0.beta2.1.olpc2 --- Paint-17 --- * Make the fix for #5586 work with security. (tomeu) --- Read-40 --- * Fix zoom-to-width (tomeu), #5866 --- Record-50 --- * #4525 updates * #5899 workaround * #5830 fix --- Web-84 --- * Use ellipsis, #5765 (rwh) * Implement can_close(), #5493 (rwh) -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org
Re: Update.1 testing
I know that we're supposed to all be developers here, and know how to change the firmware in our sleep; but it would be great to include a link to instructions. I searched the wiki - http://wiki.laptop.org/go/Manual_Firmware_Install is worse than useless, and http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the wrong place (why include separate instructions on each firmware build page, instead of having a general instructions page?) and also does not tell you how to do it using SD instead of USB or internal. I'll take responsibility for putting the instructions on the wiki and making appropriate links to them, if someone tells me how to do it with SD. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC and GLX
After compiling in mesa source to get GLX working on the FC7-based builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to Ubuntu which gets 65 fps, this is rather poor. I think the Ubuntu performance shows that 3D (albeit simple 3D) is very possible and worthwhile. I've tried the amd and fbdev drivers - they make no performance difference. Neither does i386 versus i586 (w/ mmx and 3dnow! included in cflags). I haven't tried DRI. I don't understand how it would help if I understand DRI correctly, but perhaps I'm missing something. I have no idea if processes that are re-niced automatically, or have some sort of resource limitation. I'm using the default xorg.conf. I hope the problem is something simple that I'm not seeing. Thanks. -Bryan Duff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
Jameson Chema Quinn wrote: I know that we're supposed to all be developers here, and know how to change the firmware in our sleep; but it would be great to include a link to instructions. I searched the wiki - http://wiki.laptop.org/go/Manual_Firmware_Install is worse than useless, and http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the wrong place (why include separate instructions on each firmware build page, instead of having a general instructions page?) and also does not tell you how to do it using SD instead of USB or internal. I'll take responsibility for putting the instructions on the wiki and making appropriate links to them, if someone tells me how to do it with SD. Will you also take responsibility for handling the complaints I get (have gotten) for not having the manual installation instructions in each relnotes page? The procedure for SD is similar to that for USB, except that you use sd: instead of u: to specify the device. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
On Jan 20, 2008 1:07 PM, Mitch Bradley [EMAIL PROTECTED] wrote:
Jameson Chema Quinn wrote:
I know that we're supposed to all be developers here, and know how to
change the firmware in our sleep; but it would be great to include a
link to instructions. I searched the wiki -
http://wiki.laptop.org/go/Manual_Firmware_Install is worse than
useless, and
http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the
wrong place (why include separate instructions on each firmware build
page, instead of having a general instructions page?) and also does
not tell you how to do it using SD instead of USB or internal.
I'll take responsibility for putting the instructions on the wiki and
making appropriate links to them, if someone tells me how to do it
with SD.
Will you also take responsibility for handling the complaints I get
(have gotten) for not having the manual installation instructions in
each relnotes page?
Simple. Put the manual install instructions in
http://wiki.laptop.org/go/Manual_Firmware_Install and then, in each relnotes
page add {{:Manual_Firmware_Install}}, which will include the text of that
page in the one it is as a template in.
If you want to be even cooler, in Manual_Firmware_Install, put the tags
onlyinclude and /onlyinclude on the stuff that you want to be included.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
On Sun, 20 Jan 2008, Tomeu Vizoso wrote: Ok, the problem is that by mistake some unstable builds had a too new version of xapian. We reverted to the known-good older version but it cannot read the indexes created or modified by the later version. Just do this in the terminal with the SD card mounted: mv /media/2FD2-5097/.olpc.store /media/2FD2-5097/.olpc.store.bk After rebooting, the SD card should be correctly recognized by the Journal. yes, after removing this dir it's recognised again. thanks. David Lang Tomeu On Sat, 2008-01-19 at 18:24 -0800, [EMAIL PROTECTED] wrote: similar effects, but what I'm seeing is after a full power cycle. I'm not doing a suspend attached is the sugar logfile David Lang On Sat, 19 Jan 2008, Tomeu Vizoso wrote: Date: Sat, 19 Jan 2008 20:02:02 -0500 From: Tomeu Vizoso [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: New update.1 build 682 Hi, looks like you have found http://dev.laptop.org/ticket/4013 . Could you check, please? Should work in latest joyride builds. Thanks, Tomeu On Sat, 2008-01-19 at 18:00 -0800, [EMAIL PROTECTED] wrote: sorry for the delay in responding (I've been traveling for the last week) attached is the messages file, it looks like the system is trying to unmount the SD card immediatly after boot (2 seconds) I'll enable the sugar debugging and go into the journal immediatly after boot and then see if there is anything interesting there. I'll be upgrading to a new build as soon as the RC is released. David Lang On Wed, 16 Jan 2008, Tomeu Vizoso wrote: Date: Wed, 16 Jan 2008 10:29:25 -0500 From: Tomeu Vizoso [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: New update.1 build 682 Can you give some more details? Particularly, see http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets and also /var/log/messages would be of interest. Thanks, Tomeu On Wed, 2008-01-16 at 07:18 -0800, [EMAIL PROTECTED] wrote: I can't get the journal to see the SD card with this build. I can see it from the command line just fine. David Lang On Tue, 15 Jan 2008, Build Announcer Script wrote: Date: Tue, 15 Jan 2008 15:00:03 -0500 (EST) From: Build Announcer Script [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: New update.1 build 682 http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build682/ -Paint-15.xo +Paint-17.xo -Read-38.xo +Read-40.xo -Record-49.xo +Record-50.xo -Terminal-5.xo +Terminal-8.xo -Web-83.xo +Web-84.xo +bash.i386 0:3.2-19.fc7 -bash.i386 0:3.2-9.fc7 -gnash.i386 0:0.8.1-1.olpc2 +gnash.i386 0:0.8.1-2.olpc2.20071226cvs -gnash-plugin.i386 0:0.8.1-1.olpc2 +gnash-plugin.i386 0:0.8.1-2.olpc2.20071226cvs -hulahop.i386 0:0.4.0-1.olpc2 +hulahop.i386 0:0.4.0-2.olpc2 -initscripts.i386 0:8.54.1-15.olpc2 +initscripts.i386 0:8.54.1-17.olpc2 -libabiword.i386 0:2.6.0.svn20071106-1 +libabiword.i386 0:2.6.0.svn20071127-1 -libabiword-plugins.i386 0:2.6.0.svn20071106-1 +libabiword-plugins.i386 0:2.6.0.svn20071127-2 -libxml2.i386 0:2.6.29-1.fc7 +libxml2.i386 0:2.6.31-1.fc7 -libxml2-python.i386 0:2.6.29-1.fc7 +libxml2-python.i386 0:2.6.31-1.fc7 -mingetty.i386 0:1.07-5.2.2 +mingetty.i386 0:1.07-9.olpc2 -ohm.i386 0:0.1.1-6.1.20080102git.fc7 +ohm.i386 0:0.1.1-6.3.20080102git.fc7 -olpc-utils.i386 0:0.63-1.olpc2 +olpc-utils.i386 0:0.63-2.olpc2 -pyabiword.i386 0:0.6.0.svn20071106-1 +pyabiword.i386 0:0.6.0.svn20071127-1 -rainbow.noarch 0:0.7.6-1.olpc2 +rainbow.noarch 0:0.7.8-1.olpc2 -sugar-evince.i386 0:2.20.0-4.olpc2 +sugar-evince.i386 0:2.20.1.1-1.olpc2 -sugar-evince-python.i386 0:2.20.0-4.olpc2 +sugar-evince-python.i386 0:2.20.1.1-1.olpc2 -sugar.i386 0:0.75.7-1 +sugar.i386 0:0.75.8-1 -totem.i386 0:2.18.2-11 +totem.i386 0:2.18.2-12 -totem-mozplugin.i386 0:2.18.2-11 +totem-mozplugin.i386 0:2.18.2-12 -totem-plparser.i386 0:2.18.2-11 +totem-plparser.i386 0:2.18.2-12 -xkeyboard-config.noarch 0:1.1-7.20071130cvs.olpc2 +xkeyboard-config.noarch 0:1.1-8.20071130cvs.olpc2 -xulrunner.i386 0:1.9-0.beta1.9.olpc2 +xulrunner.i386 0:1.9-0.beta2.1.olpc2 --- Paint-17 --- * Make the fix for #5586 work with security. (tomeu) --- Read-40 --- * Fix zoom-to-width (tomeu), #5866 --- Record-50 --- * #4525 updates * #5899 workaround * #5830 fix --- Web-84 --- * Use ellipsis, #5765 (rwh) * Implement can_close(), #5493 (rwh) -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
Simple. Put the manual install instructions in
http://wiki.laptop.org/go/Manual_Firmware_Install and then, in each
relnotes page add {{:Manual_Firmware_Install}}, which will include the text
of that page in the one it is as a template in.
If you want to be even cooler, in Manual_Firmware_Install, put the tags
onlyinclude and /onlyinclude on the stuff that you want to be included.
I've done this - and, even cooler, I used a template parameter so that you
can have the instructions refer to the right version, like this:
{{:Manual_Firmware_Install|version=q2d09}} .
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
Sorry all - this thread re got me riled, I have to jump in on Victor's side here... On 20 Jan 2008, at 10:18, Albert Cahalan wrote: I know every developer wants to believe that their own file format is a standard (and a good one too!), but come on now. I went looking for stuff that supports csound. I found **one** program, about 5 wrappers (at least one of which also supported MIDI), and **zero** hardware. The situation with MIDI is radically different; there are a tremendous number of MIDI programs and devices. Sorry Albert, but I think you may be *slightly* missing the point of Csound. - It *does* handle MIDI files really well - It's a very well established format that has been around decades, long before MIDI. - There is no hardware support for it, since it has always been a *software* sound design and manipulation tool and was designed for that job, unlike MIDI which was designed as a hardware protocol and had all manner of additional responsibilities foisted on it later. - Lots of computer music, at many levels from hobby users to serious research, gets done with Csound. It is a credible and viable option, and quite possibly the *correct* option for an *education focussed* platform. Perhaps it will be more obvious this way: Notice that the XO ships with a word processor. This word processor could use RTF, OpenDocument, OOXML, TeX, *roff, XHTML... or a custom format that the authors just happen to have invented. What do you think, go with the custom format? Perhaps it will be more obvious this way: - MIDI is like a plain text format for music. - Csound is like a rich text, it allows considerably more subtle nuances. Subtle nuances are the heart of music. The Csound program can handle this rich text, but it can also read the plain text (MIDI) when it has too. Another point that people are skipping over here is the subtle cultural bias (maybe that should be Cultural Bias in a project like this, where it matters that we avoid bias!) that MIDI introduces. This *really* bothers me for a tool we are planning to deploy in large numbers in many different cultures. The basic MIDI design implicitly assumes a western style scale, with essentially equal-temperament, and a minimum interval of a semitone. [Of course, we grew up with music expressed with those constraints, and most western listeners hear equal-temperament as it if were correct (if they can hear it at all!) - but that's very much a learned response. To ears raised on more natural musical voicing, it sounds really artificial, forced and un-natural.] Now, it is *possible* to correct these problems in MIDI (e.g. by messing with the tuning on a per-note basis, that sort of thing) but it is non-trivial. So people will use the defaults, and that's probably a Bad Thing. Csound, on the other hand, is readily capable of true temperament, or micro-tonal scales, or etc.. That's got to be a good thing. MIDI looks damn good to me. Sure - and plain text is The Way to code software. We all use it all the time. But for a more fancy-shmancy document you want some sort of fancy editor. Horses for courses - but if you have to choose just one, pick the fancy one, since it can work as the simple one when it has too. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
Jameson Chema Quinn wrote:
Simple. Put the manual install instructions in
http://wiki.laptop.org/go/Manual_Firmware_Install and then, in
each relnotes page add {{:Manual_Firmware_Install}}, which will
include the text of that page in the one it is as a template in.
If you want to be even cooler, in Manual_Firmware_Install, put the
tags onlyinclude and /onlyinclude on the stuff that you want
to be included.
I've done this - and, even cooler, I used a template parameter so that
you can have the instructions refer to the right version, like this:
{{:Manual_Firmware_Install|version=q2d09}} .
Thanks, that will make it easier to maintain new versions of the page.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
RE: Testing the Wireless driver changes
After downloading the firmware, the ARM is told by the boot2 to jump to a specific location of the internal memory. If the firmware is not downloaded, the boot2 starts the grab the firmware from the Flash and jumps to the same location of the internal memory once that is done. The flash tool does not figure out anything here. The boot2 code is smart enough to figure that out. Best Regards, Ronak From: Michail Bletsas [mailto:[EMAIL PROTECTED] Sent: Saturday, January 19, 2008 10:23 AM To: Dan Williams; Ronak Chokshi Cc: Ricardo Carrano; devel; David Woodhouse; Giannis Galanis; [EMAIL PROTECTED] Subject: Re: Testing the Wireless driver changes Does the Boot2 code take care of figuring out the correct address to write the thick firmware to, or does the flash tool have to figure out the address to write it to? Normally this address is embedded in the firmware flash file header, is there an address the tool should check for to verify, or is that address completely irrelevant because the boot2 code is smart enough to figure out where to put it? Dan, You have to ask Ronak that. Right now the flash writing logic lives in the firmware. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
On Jan 20, 2008 6:46 PM, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
AC not present
Am I missing something here? I also downloaded q2d09.rom.{sha1,md5,asc}
to the same place just in case, but it didn't make a difference.
Plug in the AC adapter to the wall.
-ffm
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
Jeremy Fitzhardinge wrote: ok flash n:\boot\q2d09.rom Reading n:\boot\q2d09.rom Got firmware version: CL1 Q2D09 Q2D Checking integrity ... AC not present Duh. I just realized this is referring to the fact that its not plugged into mains power rather than anything to do with the Checking integrity... line. I guess there's always a way to misinterpret the plainest message. J ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO wireless firmware, etc.
On Jan 20, 2008 10:10 AM, RHS Linux User [EMAIL PROTECTED] wrote: Hi, I have been following XO for some time. I see you are looking for someone to help with open firmware for the Marvel chipset. Indeed. Have you looked at the Wiki page on the effort? http://wiki.laptop.org/go/Marvell_microkernel and sign yourself up. Can you answer any of the questions there? Are you on the OLPC devel mailing list? You can sign up at http://lists.laptop.org/ Our IRC channel is #olpc http://wiki.laptop.org/go/Communication_channels I AM willing to help. I have considerable RF experience along with low level software. Regards realtime OSs, I write my own. And doing 96k of code doesn't seem that difficult. Even the RF part is not that tough. That said, I think a MUCH more useful direction would be to document the 'mesh' protocol in sufficient detail so anyone could duplicate it with whatever hardware, including the RF protocol and timers. That is the point of the 802.11s standard work. I suspect you will discover that Marvell is STRONGLY opposed to this effort despite their statements otherwise. And also that this is the part EFF is most as strongly in favor of. No surprises there. No worries, either. I am glad to see that the Linux end of the driver is getting some work. This is a good place to begin. Personally despite the considerable work envolved, I think a 2nd implementation using an open radio chip and one of the ADC-FPGA combinations readily available would be well worth the effort. It could serve as a reference platform to ensure production radios really work correctly as well as offering a way to add other devices by other manufacturers to the XO mesh system. I can introduce you to other people working on Open Source Hardware if you like. I am open to whatever suggestions you might have regards how I might help with your efforts. Take a look at the existing Wiki pages and code, and we'll discuss it further. Good luck with the XO program. warm regards from COLD Concord, NH USA --anonymous for now-- [EMAIL PROTECTED] Thank you. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
Mitch Bradley wrote:
Jameson Chema Quinn wrote:
Simple. Put the manual install instructions in
http://wiki.laptop.org/go/Manual_Firmware_Install and then, in
each relnotes page add {{:Manual_Firmware_Install}}, which will
include the text of that page in the one it is as a template in.
If you want to be even cooler, in Manual_Firmware_Install, put the
tags onlyinclude and /onlyinclude on the stuff that you want
to be included.
I've done this - and, even cooler, I used a template parameter so that
you can have the instructions refer to the right version, like this:
{{:Manual_Firmware_Install|version=q2d09}} .
Thanks, that will make it easier to maintain new versions of the page.
I'm not having much success with these instructions. I downloaded
q2d09.rom into /versions/boot/current/boot, rebooted into OFW and typed
flash n:\boot\q2d09.rom as the instructions say. However I get:
ok flash n:\boot\q2d09.rom
Reading n:\boot\q2d09.rom
Got firmware version: CL1 Q2D09 Q2D
Checking integrity ...
AC not present
ok
Am I missing something here? I also downloaded q2d09.rom.{sha1,md5,asc}
to the same place just in case, but it didn't make a difference.
Thanks,
J
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Project Hosting Application: Lab
I have a significant majority of the base code written for Lab and plan to
get at least a working standalone version within the next few weeks.
1. Project name : Lab Activity
2. Existing website, if any : None as of yet
3. One-line description : A scientific analysis and interface activity
4. Longer description : This activity is designed to allow full-featured
: analysis of data collected from the XO Mic in
port,
: networked XOs, Measure log files, and numerous
: other sources. It aims to integrate _analysis_ of
: the data with the actual data collection.
5. URLs of similar projects : http://wiki.laptop.org/go/Measure
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URL
-
#1 nasa Nicholas Sinnott-Armstrong
https://www.cs.dartmouth.edu/~nasa/ssh2key.pub
Email: [EMAIL PROTECTED]
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar to
CVS and Subversion users, and that tends to work well for most projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
main tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a discussion tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the list
we chose to create above
[ ] A separate mailing list, projectname-git, should be created for commit
notifications
[X] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits to be
made
[ ] Translation arrangements have already been made at ___
12. Notes/comments:
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
jabber for non-wireless XO ?
I don't have any wireless. I do have a wired ethernet connection to a LAN (which in turn uses a proxy to reach the internet). Even when I specify in sugar-control-panel the name of a real server, my XO is not accessing jabber (the field in olpc-netstatus is shown blank). I believe my proxy can correctly pass requests for ports 5222-5223. Does telepathy work with a wired ethernet? Does it have a problem if the connection is through a proxy? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
Hi, There should be no particular reason why Ubuntu would have better *software* GL rendering performance than Fedora, although hardy ships with gcc 4.2, which could make a big difference. glxgears opens a window, but the software rendering performance will depend not just on that window, but also on the contents of the rest of the screen at the time. Perhaps the Ubuntu desktop had xfce in the background, and the OLPC desktop had the sugar home view, and perhaps there is a difference in rendering load between the two? (He said, with gale-force handwaving.) - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
Bryan Duff wrote: After compiling in mesa source to get GLX working on the FC7-based builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to Ubuntu which gets 65 fps, this is rather poor. One last thing: I'm very curious about this disparity: could you please provide more details? What versions of Mesa and the X servers have you been using? Was the depth exactly the same? Could you run glxinfo on both systems? How did you build the Fedora X server? What compiler did you use and what optimization flags? There should be no particular reason why Ubuntu would have better *software* GL rendering performance than Fedora, although hardy ships with gcc 4.2, which could make a big difference. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
(please forgive minor mistakes as I was in a hurry and I had no time to double-check some of the facts reported below. Feel free to point out corrections, of course). Bryan Duff wrote: After compiling in mesa source to get GLX working on the FC7-based builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to Ubuntu which gets 65 fps, this is rather poor. I think the Ubuntu performance shows that 3D (albeit simple 3D) is very possible and worthwhile. Nobody ever thought 3D was impossible or unfeasible on an full blown x86 CPU at 466MHz, when it very clearly was possible even on the 8bit, 1MHz, C64 with no hardware floating point support. My question is: why are you trying so hard to achieve *unaccelerated*, *indirect*, *GLX* support when it would be much easier and faster to just use OpenGL in-process and then XPutImage the resulting buffer? I've tried the amd and fbdev drivers - they make no performance difference. Neither does i386 versus i586 (w/ mmx and 3dnow! included in cflags). Of course it makes no difference because the server-side software renderer gets used in both cases. And this renderer happens to be exactly the same code of Mesa, only built in a slightly different way. There's no need to run benchmarks to find this out. A simple inspection of the source code would reveal that there are no hardware accelerated paths in Mesa for the Geode. Although, some primitive form of GL acceleration could certainly be implemented for very trivial operations. I haven't tried DRI. I don't understand how it would help if I understand DRI correctly, but perhaps I'm missing something. I have no idea if processes that are re-niced automatically, or have some sort of resource limitation. Uh? DRI is the in-kernel support for DMA, command queue completion interrupts and now TTM and memory management for *direct* rendering clients. On the other hand, the indirect (i.e. server side) rendering path you're using historically happened without DRI's help because it was unaccelerated anyway. The X server still had some interaction with DRI in order to coordinate window management operations with direct rendering clients. Recently, Kristian Høgsberg did a huge architectural shift in order to add 3D acceleration to the server-side Mesa renderer. This is AIGLX. While AIGLX is somewhat slower than direct rendering due to the overhead of the GLX wire protocol, and generally not recommended for 3D intensive games, it is no doubt the way to go to achieve 3D desktop effects, and to redirect 3D clients to off-screen buffers so that their output can be further processed. At this time, the AIGLX effort is halfway finished: the basic features work beautifully and efficiently, but XVideo does not yet play by the rules, and mouse input keeps ignoring the 3D transformations. Another big show stopper for a fully 3D Linux desktop is that it needs aggressive graphics card memory usage in a multitasking environment, which requires a sophisticated memory manager with a smart swap-in policy to keep things fast on a crowded desktop. Although an implementation already exists, the underlying design is still being debated and could possibly undergo further changes before it will find its way into the kernel. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
