[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] SC-history [was: linux - hacking UGens]

On Oct 21, 2004, at 5:39 PM, Arie van Schutterhoef wrote:

I never gave Irix a thought.
-My memory seem to be in pretty good shape (even at this
 time of day, rather night over here); found in the on line
 archive at your site:
 message to the list dated Wed Jan 29 13:03:18 1997, telling:

'I am still working on SC 1.1b6. This will fix more bugs and add a few functions. It should be out by the end of Feb. This message discusses
    plans for the future rewritten SuperCollider program.

    The first version of the new SuperCollider virtual machine will run
on the BeOS. Once the Apple/Next OS comes out then it will be ported
    to that. Circumstances may lead to an SGI port as well. (Assuming
    K.Taylor at SGI does agree to lend me a box).'

he never did.

But also something that looks like a predated SC3:

"Multiprocessing, multitasking capable. Each operating system thread
    can contain a separate virtual machine 'Process'. Each virtual
    machine 'Process' can contain multiple time sliced 'Threads'.
    Processes communicate by messaging, their address spaces (GC
    environments), are separate. Virtual machine Threads share all the
    data of their Process. The reason for this architecture is for
    efficient garbage collection. There are no good real time
    multiprocessor garbage collection algorithms which do not suffer
    periods of blocking or excessive copying. This architecture allows
    the use of a simple and fast real time uniprocessor garbage
    collection algorithm for each Process. The messaging model allows
    sending data between Processes but prevents passing object
    references between Processes. Typically there will be a Process per
CPU for computing audio streams. Each of these will be basically the
    same scheduling/DSP loop as the current SuperCollider architecture.
    In addition you will be able to start additional Processes to do
    background tasks, user interface tasks, etc.'

this is a description of the architecture of SC3d5, not SC server.
When I wrote the macros for SC server, both BeOS and Irix were memories.