Thanks for raising this important issue!

I've been concerned about this ever since I started working with computer music. As you may or may not know, there are several classic works of computer music, or computer music software, that have been lost due to the obsolescence of their computer hardware, operating system, or programming language -- including John Chowning's classic pieces, initially realized in SAIL, now fortunately re-realized.

I've personally experienced this kind of obsolescence. I used to use a freebie PC sequencer that went obsolete, so all the pieces I did in this sequencer are now toast. I have the MIDI sequences so I can re-render them in Csound, but I can't edit the compositions (which were hierarchies of sequences).

And I've experienced it in my own software! I have migrated my compositional algorithms from standalone Windows C++ programs, to the Java version of Silence, to CsoundAC. Pieces done in the old software are now dead. I still have the MIDI sequences and the Csound orcs and scos, so I can improve the Csound arrangements and rendering quality, but I can't edit or vary the compositional algorithms any more.

Obviously, open source tools are essential for serious music that has some aspiration to live for more than a few years. 

The hope is that basic programs such as Csound and Python will continue to be maintained with backward compatibility, and if backward compatibility breaks, it will still be possible to rebuild the older versions from sources and run them, if necessary on emulators. After all, people are still making "chip tunes" for the Yamaha SID and Commodore 64 on PC emulator software. This is the model for us!

I think that if the software in question is central enough -- C, C++, Python, Java, let's hope Csound -- it will still be possible to build and run the software indefinitely into the future, thanks to scholarly interest in the history of computing and the maintenance of compilers, emulators, and so on.

Regards,
Mike

-----Original Message-----
>From: Steven Yi 
>Sent: Jul 23, 2008 1:22 PM
>To: csound@lists.bath.ac.uk, blue users mailing list 
>Subject: [Csnd] The case for open source
>
>Hi All,
>
>I just saw a link to this from a Linux Audio mailing list that Tascam
>is ceasing development of Gigastudio:
>
>http://www.filmmusicmag.com/?p=1738
>
>This kind of thing has really been an issue for me, that closed source
>software that goes into an unsupported state severely limits the
>lifespan and history of computer music works.  I've discussed
>long-term software in lectures and about considering what you are
>investing time/money in in terms of future work.  I have referenced
>the issues that affected Apple users moving from OS9 to OSX, then
>again from PPC to Intel, how my friend was affected in half of his
>plugins were never ported to Intel, thus severely limiting his ability
>to open or reuse aspects of his project (basically he would need to
>keep an OSX PPC machine around if he ever wanted to look at the
>project again).
>
>Anyways, it's these kinds of situations that I am very concerned about
>when I think about computer music and the history of it.  I am a
>strong advocate for open source as well as investing in technologies
>based on virtual machines or interpreters where possible to protect
>investments of time/work.  Just wanted to bring this up for discussion
>as I think it's an important point involving our our work.
>
>Thanks,
>steven
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 24/07/2008, at 4:52 AM, Michael Gogins wrote:
...
> Obviously, open source tools are essential for serious music that  
> has some aspiration to live for more than a few years.
I agree completely! Not just for the music to live, but also for  
composers to be able to continue to develop their thinking to a  
certain depth and integrity over a period of time longer than the  
period to the next OS upgrade! I'm sure there are others than me on  
this list that have written software in numerous languages only to  
find they had to waste years converting both accrued tools and whole  
environments as obsolescence set in.
If it wasn't for the importance (to my way of thinking) of having an  
interpreted language. I would have just stuck to C(++) for decades.  
Each move through APL Forth to Python for this work was taken  
deliberately to maintain the interpretative aspect. Else, just go back  
to C. This is the reason why I personally have never really seen the  
need for Java. The situation is different today than in the pre- 
realtime audio days: all those 1000's of hours hacking Z80 and 680X0  
assembler don't bear thinking about!
None of which should be interpreted as wanting to discourage  
experimentation: Its essential! Processing is fun and a Csound  
interface to it is exciting, but it is still experimental and so needs  
to be handled with risk aversion strategies, like not entrusting one's  
entire finances to coffee futures!
> The hope is that basic programs such as Csound and Python will  
> continue to be maintained with backward compatibility, and if  
> backward compatibility breaks, it will still be possible to rebuild  
> the older versions from sources and run them, if necessary on  
> emulators. After all, people are still making "chip tunes" for the  
> Yamaha SID and Commodore 64 on PC emulator software. This is the  
> model for us!
And importantly, if/when C/python outlive their usefulness, that their  
replacements will be long enough coming to be seen coming. There is a  
corollary to this and that is the power of embracing the 3rd-party  
library approach. I've written about this elsewhere (eg ICoMCS paper  
at http://www.avatar.com.au/sonipy/) so I won't bang on about it here  
other than  to say that the library modularisation of Csound is a  
significant step in ensuring its long-term viability, and thus  
attractiveness. The more general routines can be 'outsourced' to wider  
software-concerned-others, the greater the survival chances. This is  
one reason (apart from the horrible sound) that I won't do any serious  
work in Max.  What happens when Cycling falls over?
Also, whilst open source is a necessary condition, it is not a  
sufficient one. A simple example suffices: Suppose I find I need to do  
some multidimensional data manipulation and I'm working in that other  
beautiful child of MusicV, Supercollider. No such tools exist within  
that environment, so what choice do I have? Well, I could take some  
time out and get on with the task of writing the tools myself, perhaps  
encouraging others to get involved. Fine, but what about the next  
time, or what about having to maintain it when the SC and/or OS  
changes? And all the time I know that out there Numpy exists and is  
probably better than what I would write, and is maintained by its own  
fanatics (bless them) and likely to evolve through OS upgrades. And  
when python becomes obsolete, as it will, all the people using Numpy  
will need something to do what it currently does. For me the choice is  
clear: tinker with custom exotics in the spare time and use as much  
bog-standard tools as possible without compromising musical integrity  
otherwise.

And the same can be said for Portaudio, UIs and OSs. Isn't it  
interesting that C and unix are still around and in-fact have been  
revived? I'm currently working on an intel Mac but the moment Apple  
decide to depart Unix, I'll be out of here asap unless it is to a more  
universally adopted environment. We all know that just making Csound  
libraries instantiable on various current platforms  is time-consuming  
enough!

D.
________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg

Steven Yi wrote:

> So from my point of view, Java is actually one of the safest languages
> and development platforms for building long-term software.

And the Pythonesque scripty goodness is available on the Java platform 
to: think of Groovy, Jython, &c.  I truly love Python in a way that few 
other languages have captured my fancy, but Java seems more appropriate 
for real-timish things like sound production, especially on modern hardware.

-- JK

-- 
I do not particularly want to go where the money is -
  it usually does not smell nice there. -- A. Stepanov