[Csnd] Next
Date | 2010-09-03 01:53 |
From | Michael Gogins |
Subject | [Csnd] Next |
I have just now uploaded the Windows installer for Csound 5.12.1 to SourceForge. I offer my sincere apologies for the delay in maintenance. At this time, only the double-precision sample size is supported. One notable new feature of this release is that QuteCsound will now run Python scripts, and can become the default composing environment for those who, like me, write music by writing Python code. I have removed my old csound-build.tx document and replaced it with an immediately readable, Microsoft Word format document, How_to_Build_Csound_on_Windows.doc, detailing all current steps required to build, test, and package Csound for Windows. As explained in this document, Csound for Windows is now built with the same compiler that comes with the Qt SDK. I think it is clear that using the Qt SDK in accordance with the instructions in my document greatly simplifies the task of building Csound from scratch on Windows although, for the life of me, I don't know why anyone would do so since the Linux build is already even more straightforward. Frankly, part of the delay was caused by my eagerness to help out with the development of multi-threaded Csound. The most promising implementation definitely appears to be ParCS. Now that John ffitch has fixed some parser bugs, I urge that the next release of Csound incorporate both the new parser and the ParCS code for multi-threaded Csound. On the ParCS side, the main work that remains to be done, as far as I can see, is to provide locks to synchronize all opcodes that could potentially introduce data races when running. I am very impressed by ParCS, and I think we all owe a debt of gratitude to Christopher Wilson and John ffitch for developing it. I can see that Andres Cabrera and his colleagues are working hard on some sort of new Python scripting capability in QuteCsound. Perhaps this also can be made available in the next release. Of course I am biased by long experience with Csound, but I try to keep abreast of what is happening in computer music and to know what is going on, and planned, in the development of the other major software synthesis systems. And I do try to be objective. But frankly, the ParCS branch of Csound is the most productive music programming environment I know about. The only remotely comparable systems are the SuperNova version of SuperCollider and Max/MSP. In SuperNova, parallel groups have been introduced into the system, and the user is responsible for programming these groups and placing suitable parallelizable blocks of code in them. A somewhat similar approach is taken in Max/MSP, where it is possible to configure poly~ to run individual instances of patches within poly~ on separate cores. Again, the user is responsible for balancing costs and benefits and organizing the parallelism. But in ParCS, the parallel constructs are invisible to the user. Regular Csound code is parsed into a data flow graph grouped by signal flow and variable assignment dependency. Each node in the graph is evaluated to see if it makes sense, balancing the cost of threading with the possible benefits of threading, to run its elements in parallel. Global variables are automatically synchronized, too. I think this design has much more of a future – especially because it already affords significant speedups in realistic situations. At ksmps of around 100 with compute-intensive instruments, every time the number of cores doubles, ParCS speeds up the performance by roughly 150%. -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel |
Date | 2010-09-03 05:04 |
From | "Marc D. Demers" |
Subject | [Csnd] RE: Next |
Hi Mike, I'm sure that I can speak for the whole Csound community in saying that you do not need to apologize for any delay (in fact since everyone is giving their time gratis...there is no deadline to meet, the concept of delay is not in this universe) in compiling the Windows version of Csound. The only thing we can say is: thank you for your commitment. Marc > Date: Thu, 2 Sep 2010 20:53:50 -0400 > From: michael.gogins@gmail.com > To: csound-devel@lists.sourceforge.net; csound@lists.bath.ac.uk > Subject: [Csnd] Next > > I have just now uploaded the Windows installer for Csound 5.12.1 to > SourceForge. I offer my sincere apologies for the delay in > maintenance. At this time, only the double-precision sample size is > supported. One notable new feature of this release is that QuteCsound > will now run Python scripts, and can become the default composing > environment for those who, like me, write music by writing Python > code. > > I have removed my old csound-build.tx document and replaced it with an > immediately readable, Microsoft Word format document, > How_to_Build_Csound_on_Windows.doc, detailing all current steps > required to build, test, and package Csound for Windows. As explained > in this document, Csound for Windows is now built with the same > compiler that comes with the Qt SDK. I think it is clear that using > the Qt SDK in accordance with the instructions in my document greatly > simplifies the task of building Csound from scratch on Windows > although, for the life of me, I don't know why anyone would do so > since the Linux build is already even more straightforward. > > Frankly, part of the delay was caused by my eagerness to help out with > the development of multi-threaded Csound. The most promising > implementation definitely appears to be ParCS. Now that John ffitch > has fixed some parser bugs, I urge that the next release of Csound > incorporate both the new parser and the ParCS code for multi-threaded > Csound. On the ParCS side, the main work that remains to be done, as > far as I can see, is to provide locks to synchronize all opcodes that > could potentially introduce data races when running. I am very > impressed by ParCS, and I think we all owe a debt of gratitude to > Christopher Wilson and John ffitch for developing it. > > I can see that Andres Cabrera and his colleagues are working hard on > some sort of new Python scripting capability in QuteCsound. Perhaps > this also can be made available in the next release. > > Of course I am biased by long experience with Csound, but I try to > keep abreast of what is happening in computer music and to know what > is going on, and planned, in the development of the other major > software synthesis systems. And I do try to be objective. But frankly, > the ParCS branch of Csound is the most productive music programming > environment I know about. The only remotely comparable systems are the > SuperNova version of SuperCollider and Max/MSP. > > In SuperNova, parallel groups have been introduced into the system, > and the user is responsible for programming these groups and placing > suitable parallelizable blocks of code in them. > > A somewhat similar approach is taken in Max/MSP, where it is possible > to configure poly~ to run individual instances of patches within poly~ > on separate cores. Again, the user is responsible for balancing costs > and benefits and organizing the parallelism. > > But in ParCS, the parallel constructs are invisible to the user. > Regular Csound code is parsed into a data flow graph grouped by signal > flow and variable assignment dependency. Each node in the graph is > evaluated to see if it makes sense, balancing the cost of threading > with the possible benefits of threading, to run its elements in > parallel. Global variables are automatically synchronized, too. > > I think this design has much more of a future – especially because it > already affords significant speedups in realistic situations. At ksmps > of around 100 with compute-intensive instruments, every time the > number of cores doubles, ParCS speeds up the performance by roughly > 150%. > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" > |
Date | 2010-09-03 05:36 |
From | Greg Schroeder |
Subject | [Csnd] Re: Next |
I'm dreadfully curious rather than critical . . . Is there any particular reason for .doc rather than, say, .pdf or .rtf, etc? Greg On Fri, Sep 3, 2010 at 9:53 AM, Michael Gogins |
Date | 2010-09-03 15:48 |
From | jean-pierre lemoine |
Subject | [Csnd] Re: Next |
Many thanks for this installer. Is crossfm part of this build. I have tried the example of the documentation and got a no legal opcode I have tries also csound -z, and no crossfm in the list Best jp On Fri, Sep 3, 2010 at 2:53 AM, Michael Gogins |
Date | 2010-09-03 16:03 |
From | john saylor |
Subject | [Csnd] Re: RE: Next |
hi On Fri, Sep 3, 2010 at 12:04 AM, Marc D. Demers |
Date | 2010-09-03 16:44 |
From | Michael Gogins |
Subject | [Csnd] Re: Re: RE: Next |
Then crossfm is not in this build. It is in CVS, but not in SConstruct. I am adding it now to SConstruct. In a few days there may be other things to fix up. Then I will upload another newer installer. On Fri, Sep 3, 2010 at 11:03 AM, john saylor |
Date | 2010-09-03 16:51 |
From | Michael Gogins |
Subject | [Csnd] Re: Re: RE: Next |
Rather, it is not in the installer script. I am looking to see if other new opcodes have been omitted. It would be nice if people who create new opcodes would add them to the installer script, it is not hard to do. Regards, Mike On Fri, Sep 3, 2010 at 11:44 AM, Michael Gogins |
Date | 2010-09-03 19:42 |
From | andy fillebrown |
Subject | [Csnd] Re: Re: Re: RE: Next |
Should I wait for the newer installer before updating the Windows download link on the csound.sourceforge.net page? Cheers, ~ andy.f On Fri, Sep 3, 2010 at 11:44 AM, Michael Gogins |
Date | 2010-09-03 20:27 |
From | Michael Gogins |
Subject | [Csnd] Re: Re: Re: Re: RE: Next |
It's up to you. It would be nice if I hear about the current installer from a number of users before I update it. Regards, Mike On Fri, Sep 3, 2010 at 2:42 PM, andy fillebrown |
Date | 2010-09-03 20:47 |
From | Oeyvind Brandtsegg |
Subject | [Csnd] Re: Re: Re: Re: Re: RE: Next |
oh, that should probably be done for modmatrix.dll as well. Sorry, I did not realize I should edit the installer. I edited and tried to commit now, but Tortoise gives me: "cvs commit: cannot commit with sticky date for file `csoundd.nsi'" A web search informs me that I should remove the sticky tags, but I'm unsure as I did not tag it. I tried deleting my file and updating from CVS to make sure it's clean, but it's still sticky tagged it seems. and +1 on the thank yous :-) Oeyvind 2010/9/3 Michael Gogins |
Date | 2010-09-03 21:29 |
From | Michael Gogins |
Subject | [Csnd] Re: Re: Re: Re: Re: Re: RE: Next |
That's all right, I took care of it, thanks for the information. Regards, Mike On Fri, Sep 3, 2010 at 3:47 PM, Oeyvind Brandtsegg |
Date | 2010-09-04 21:24 |
From | David Kirsh |
Subject | [Csnd] Re: Next |
What sad times are these, when someone puts in hours of highly skilled work for the good of the community, and then feels like they have to apologize for not doing it fast enough. Anyway, let me add another thank-you to the ones already published. While I'm at it, thanks also for the signal flow graph opcodes, which I just recently discovered. These are great for making instruments more easily re-used in different orchestras. David K. On Sep 2, 2010, at 8:53 PM, Michael Gogins wrote: > I have just now uploaded the Windows installer for Csound 5.12.1 to > SourceForge. I offer my sincere apologies for the delay in > maintenance. ... Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" |
Date | 2010-09-05 10:37 |
From | andy fillebrown |
Subject | [Csnd] Re: Re: Re: Re: Re: RE: Next |
Hi Michael, I tried the new installer and it's having the same problems as 5.11. When running QuteCsound, fluidOpcodes.dll causes crashes and virtual.dll / widgets.dll cause the clipboard to stop working. As before, removing all three from opcodedir make QuteCsound run trouble-free. Sorry to be the bearer of bad news =( Cheers, ~ andy.f On Fri, Sep 3, 2010 at 3:27 PM, Michael Gogins |
Date | 2010-09-05 15:56 |
From | Michael Gogins |
Subject | [Csnd] Re: Re: Re: Re: Re: Re: RE: Next |
Could you please email me the relevant message logs etc, stack traces if you can get them. I use fluidOpcodes and get no crashes during running. The virtual keyboard causes no crashes. I haven't tried FLTK opcodes except outside QuteCsound; they worked outside. I did, however, run into a problem with inconsistent versions of libglib-2.0-0.dll. Check to make sure that the one in the Csound bin directory comes first in your PATH. I had one from Graphviz that was causing problems similar to those you report (Fluidsynth links with this library). I removed the glib in Graphviz and my problems went away. Hope this helps, Mike On Sun, Sep 5, 2010 at 5:37 AM, andy fillebrown |
Date | 2010-09-24 11:21 |
From | "Sigurd Saue" |
Subject | [Cs-dev] Building problems (DSound and Mingw) |
More or less as an exercise I'm trying to build CSound on Windows following Michaels document. Some problems along the way has been sorted, but now I'm stuck. When I try to build FluidSynth I get the following compile error: In file included from c:/Develop/Fluidsynth/fluidsynth-1.1.2/src/drivers/fluid_dsound.c:30: c:\develop\opt\qt\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/dsound.h:13:17: error: sal.h: No such file or directory I guess this error will pop up anywhere that I try to include dsound.h in a MinGW build. I've turned off almost all configuration options for FluidSynth to no avail. Sigurd -----Original Message----- From: Michael Gogins [mailto:michael.gogins@gmail.com] Subject: [Cs-dev] Next ... I have removed my old csound-build.tx document and replaced it with an immediately readable, Microsoft Word format document, How_to_Build_Csound_on_Windows.doc, detailing all current steps required to build, test, and package Csound for Windows. ... ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
Date | 2010-09-24 13:52 |
From | Michael Gogins |
Subject | Re: [Cs-dev] Building problems (DSound and Mingw) |
I use the dsound.h from the Synthesis Toolkit in C++ to resolve this problem, I should update my document to reflect that. Regards, Mike On Fri, Sep 24, 2010 at 6:21 AM, Sigurd Saue |
Date | 2010-09-24 14:19 |
From | "Sigurd Saue" |
Subject | Re: [Cs-dev] Building problems (DSound and Mingw) |
That did the trick. Thanks a lot. Sigurd -----Original Message----- From: Michael Gogins [mailto:michael.gogins@gmail.com] Sent: 24. september 2010 14:52 To: Developer discussions Subject: Re: [Cs-dev] Building problems (DSound and Mingw) I use the dsound.h from the Synthesis Toolkit in C++ to resolve this problem, I should update my document to reflect that. Regards, Mike On Fri, Sep 24, 2010 at 6:21 AM, Sigurd Saue |