I suspect there is some misunderstanding here. When I say "plugin" I mean
nothing more nor less than implementing GEN routines and opcode routines in
shared libraries, using a standard registration function and the usual i, k,
and a rate functions, so that Csound can locate and load these opcodes at
run time, writing them into the opcode table so that they can be used in
orcs and scos.

I am not talking about enabling Csound to use VST plugins or to itself
become a VST or DirectX plugin (though those are worthwhile tasks, in my
opinion).

I'm talking about making it possible for anyone to contribute to Csound
without breaking it, and their contributions would be instantly usable.

-----Original Message-----
From: Matt J. Ingalls 
To: Fred Floberg 
Cc: tlv@tuna.net ; csound@maths.ex.ac.uk

Date: Wednesday, January 20, 1999 2:27 PM
Subject: Re: plug in architecture?


>
>i dont like the plug-in model.  only exists because of primitive operating
>systems and [korporate fasc!sm]
>
>getting more and more excited about BeOS--timing-aware audio streams
>throughout OS (between other applications) no need for plug-ins.
>e
>energy spent would be best used toward creating applications that
>knew/supported/used csound (Cecelia, etc) rather than twisting csound to
>support industry standard.
>
>best thing would be strip csound bloatware into freeware synth library
>that all us hacks could write our own stuff with (or stream to, lets not
>forget beos)
>
>or perhaps phil burk's jsyn(jason) and its c libs its based on is what im
>looking for or perhaps other people know of others???
>
>-matt
>
>
>
>

> nothing more nor less than implementing GEN routines and opcode routines in
> shared libraries, using a standard registration function and the usual i, k,
  oh yes, of course -- i remember same discussion about a year ago. yes
this is definitely needed - csound is becoming major bloatware...

but personally im seaching to see if maybe something out there
(jsyn/WUSY/supercollider/SOAL/?) that maybe is already a "csound with
everything youve always wished for added" -- 

> without breaking it, and their contributions would be instantly usable.

	and reduce/simplify core csound...

(now to your longer letter)

sorry michael. you had explained to me that you were not referring to VST
type etc. plug-ins. next time i'll try to post when the info is still fresh
in my mind kontanaur.
tolve

>I suspect there is some misunderstanding here. When I say "plugin" I mean
>nothing more nor less than implementing GEN routines and opcode routines in
>shared libraries, using a standard registration function and the usual i, k,
>and a rate functions, so that Csound can locate and load these opcodes at
>run time, writing them into the opcode table so that they can be used in
>orcs and scos.
>
>I am not talking about enabling Csound to use VST plugins or to itself
>become a VST or DirectX plugin (though those are worthwhile tasks, in my
>opinion).
>
>I'm talking about making it possible for anyone to contribute to Csound
>without breaking it, and their contributions would be instantly usable.
>
>-----Original Message-----
>From: Matt J. Ingalls 
>To: Fred Floberg 
>Cc: tlv@tuna.net ; csound@maths.ex.ac.uk
>
>Date: Wednesday, January 20, 1999 2:27 PM
>Subject: Re: plug in architecture?
>
>
>>
>>i dont like the plug-in model.  only exists because of primitive operating
>>systems and [korporate fasc!sm]
>>
>>getting more and more excited about BeOS--timing-aware audio streams
>>throughout OS (between other applications) no need for plug-ins.
>>e
>>energy spent would be best used toward creating applications that
>>knew/supported/used csound (Cecelia, etc) rather than twisting csound to
>>support industry standard.
>>
>>best thing would be strip csound bloatware into freeware synth library
>>that all us hacks could write our own stuff with (or stream to, lets not
>>forget beos)
>>
>>or perhaps phil burk's jsyn(jason) and its c libs its based on is what im
>>looking for or perhaps other people know of others???
>>
>>-matt
>>
>>
>>
>>