What if?

Csound only comes in one variety, Csound Core. Csound Core is designed with
an interface layer.  Developers design plugins/add-ons to Csound Core using
this interface layer.  Users download and use Csound Core.  When a
particular user needs something more than Csound Core has to offer, they go
to the Csound Plugin page, find what they are looking for, download, and
install.  After the installation, Csound Core automatically recognizes the
plugin.  Csound Core does not need to be compiled, it just works.

Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound, FLTK
Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to turn
on/off installed plugins), etc.  Third party software also uses this same
interface layer to use Csound as an audio engine.

To me, this is nearly the ideal situation.  Is this possible. Absolutely! 
Plausible, maybe?

Best,
Jake

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
Sent from the Csound - General mailing list archive at Nabble.com.

> To me, this is nearly the ideal situation.  
indeed.

> Is this possible. Absolutely! 
this I don't know :)

Stef

Sure it is.  :)

Granted, it would require rebuilding Csound from the ground up - taking two
to three years to do so.  Which pretty much puts this into the realm of the
improbable, but still possible. I really need to dive into the code to get a
proper assessment of the situation.

Best,
Jake


Stéphane Rollandin wrote:
> 
>> Is this possible. Absolutely! 
> this I don't know :)
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24398841.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi Jake,

On 09/07/2009, at 2:02 AM, Jacob Joaquin wrote:

>
> What if?
>
> Csound only comes in one variety, Csound Core. Csound Core is  
> designed with
>
...
> Plugins include: Python, Java,
... but here you seem not to have understood the difference between  
_embedding_ (the python interpreter for eg,) in csound, in which case  
it does act like a plugin,
and _extending_  (python, java, c etc) with csound. In which cases  
csound acts like a plugin to csound.
This type of use of access to csound (through an Application Program  
Interface) eanbles other tools do not-sound-specific things (such as  
score-genertion, for eg)  better than csound probably ever could.

D.

> VST, CsoundAC, Audio Units, TclCsound, FLTK
> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users  
> to turn
> on/off installed plugins), etc.  Third party software also uses this  
> same
> interface layer to use Csound as an audio engine.
>
> To me, this is nearly the ideal situation.  Is this possible.  
> Absolutely!
> Plausible, maybe?
>
> Best,
> Jake
>
> -- 

________________________________________________
David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au

On 09/07/2009, at 7:57 AM, DavidW wrote:
...
> and _extending_  (python, java, c etc) with csound. In which cases  
> csound acts like a plugin to csound.

that should have read
and _extending_ (python, java, c etc) with csound. In which cases  
csound acts like a plugin to (python, java, c etc).

D.


________________________________________________
David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au

I was previously being short on details, as my goal with this thread is to
get people thinking, and hopefully, talking about Csound from the
user-experience side of things.  I get what you're saying and I do believe
that being able to both embed and extend is ideal.

I've started looking through the source.  Still trying to make heads or
tails out of all of it.  Sometime down the road, I'm hoping to be able to
prototype on a very small scale some of these ideas that I'm suggesting.

Best,
Jake



David Worrall wrote:
> 
> 
> On 09/07/2009, at 7:57 AM, DavidW wrote:
> ...
>> and _extending_  (python, java, c etc) with csound. In which cases  
>> csound acts like a plugin to csound.
> 
> that should have read
> and _extending_ (python, java, c etc) with csound. In which cases  
> csound acts like a plugin to (python, java, c etc).
> 
> D.
> 
> 
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:	  worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
> 
> 
> 
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24429864.html
Sent from the Csound - General mailing list archive at Nabble.com.

On the other hand, the developer-friendly version just has Csound and
then users figure out on their own how to interface with it.
Seems the reality is somewhere in the middle.
-Chuckk

On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin wrote:
>
> What if?
>
> Csound only comes in one variety, Csound Core. Csound Core is designed with
> an interface layer.  Developers design plugins/add-ons to Csound Core using
> this interface layer.  Users download and use Csound Core.  When a
> particular user needs something more than Csound Core has to offer, they go
> to the Csound Plugin page, find what they are looking for, download, and
> install.  After the installation, Csound Core automatically recognizes the
> plugin.  Csound Core does not need to be compiled, it just works.
>
> Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound, FLTK
> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to turn
> on/off installed plugins), etc.  Third party software also uses this same
> interface layer to use Csound as an audio engine.
>
> To me, this is nearly the ideal situation.  Is this possible. Absolutely!
> Plausible, maybe?
>
> Best,
> Jake
>
> --
> View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
http://www.badmuthahubbard.com

I don't believe there has to be a trade off between being user-friendly and
developer-friendly.

Going back to the original user story at the top of this thread, a system
like the one proposed could potentially be easier for developers, granted
after a lot of excruciating work initially.  Once that is done, we would
have a system in which developers only need to focus on the core engine,
core opcodes and the interface layer.  GUIs, scripting language support,
etc. would be clearly separated from the core source, reducing the overall
size of the core.  People wishing to extend (or embed) Csound would have to
work through the interface layer/API, and thus absolving the need to tamper
with the core source (except for potential interface issues).  I think this
would be a win/win for both core developers and third party developers.

It's been a long day, and I don't think I'm getting my point across, so
please excuse me if I'm just rambling.  :)

Best,
Jake



Chuckk Hubbard wrote:
> 
> On the other hand, the developer-friendly version just has Csound and
> then users figure out on their own how to interface with it.
> Seems the reality is somewhere in the middle.
> -Chuckk
> 
> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin
> wrote:
>>
>> What if?
>>
>> Csound only comes in one variety, Csound Core. Csound Core is designed
>> with
>> an interface layer.  Developers design plugins/add-ons to Csound Core
>> using
>> this interface layer.  Users download and use Csound Core.  When a
>> particular user needs something more than Csound Core has to offer, they
>> go
>> to the Csound Plugin page, find what they are looking for, download, and
>> install.  After the installation, Csound Core automatically recognizes
>> the
>> plugin.  Csound Core does not need to be compiled, it just works.
>>
>> Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound,
>> FLTK
>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to
>> turn
>> on/off installed plugins), etc.  Third party software also uses this same
>> interface layer to use Csound as an audio engine.
>>
>> To me, this is nearly the ideal situation.  Is this possible. Absolutely!
>> Plausible, maybe?
>>
>> Best,
>> Jake
>>
>> --
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
> 
> 
> 
> -- 
> http://www.badmuthahubbard.com
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
Sent from the Csound - General mailing list archive at Nabble.com.

This is the way it now is... or have I missed something?

Regards,
Mike

On 7/11/09, Jacob Joaquin  wrote:
>
> I don't believe there has to be a trade off between being user-friendly and
> developer-friendly.
>
> Going back to the original user story at the top of this thread, a system
> like the one proposed could potentially be easier for developers, granted
> after a lot of excruciating work initially.  Once that is done, we would
> have a system in which developers only need to focus on the core engine,
> core opcodes and the interface layer.  GUIs, scripting language support,
> etc. would be clearly separated from the core source, reducing the overall
> size of the core.  People wishing to extend (or embed) Csound would have to
> work through the interface layer/API, and thus absolving the need to tamper
> with the core source (except for potential interface issues).  I think this
> would be a win/win for both core developers and third party developers.
>
> It's been a long day, and I don't think I'm getting my point across, so
> please excuse me if I'm just rambling.  :)
>
> Best,
> Jake
>
>
>
> Chuckk Hubbard wrote:
>>
>> On the other hand, the developer-friendly version just has Csound and
>> then users figure out on their own how to interface with it.
>> Seems the reality is somewhere in the middle.
>> -Chuckk
>>
>> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin
>> wrote:
>>>
>>> What if?
>>>
>>> Csound only comes in one variety, Csound Core. Csound Core is designed
>>> with
>>> an interface layer.  Developers design plugins/add-ons to Csound Core
>>> using
>>> this interface layer.  Users download and use Csound Core.  When a
>>> particular user needs something more than Csound Core has to offer, they
>>> go
>>> to the Csound Plugin page, find what they are looking for, download, and
>>> install.  After the installation, Csound Core automatically recognizes
>>> the
>>> plugin.  Csound Core does not need to be compiled, it just works.
>>>
>>> Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound,
>>> FLTK
>>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to
>>> turn
>>> on/off installed plugins), etc.  Third party software also uses this same
>>> interface layer to use Csound as an audio engine.
>>>
>>> To me, this is nearly the ideal situation.  Is this possible. Absolutely!
>>> Plausible, maybe?
>>>
>>> Best,
>>> Jake
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
> --
> View this message in context:
> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

I guess that proves it's a good idea.
It's true that when I compile Csound, I leave out all of the GUI
stuff, including FLTK, since I'm more comfortable with Python/Tk and
Pure Data. This last time I left out the Loris and STK opcodes because
I couldn't get them to compile, so I suppose what I end up with is
pretty core. But the default from the installers probably has a lot
that most 3rd-party developers won't use.
-Chuckk



On Sun, Jul 12, 2009 at 4:31 AM, Michael Gogins wrote:
> This is the way it now is... or have I missed something?
>
> Regards,
> Mike
>
> On 7/11/09, Jacob Joaquin  wrote:
>>
>> I don't believe there has to be a trade off between being user-friendly and
>> developer-friendly.
>>
>> Going back to the original user story at the top of this thread, a system
>> like the one proposed could potentially be easier for developers, granted
>> after a lot of excruciating work initially.  Once that is done, we would
>> have a system in which developers only need to focus on the core engine,
>> core opcodes and the interface layer.  GUIs, scripting language support,
>> etc. would be clearly separated from the core source, reducing the overall
>> size of the core.  People wishing to extend (or embed) Csound would have to
>> work through the interface layer/API, and thus absolving the need to tamper
>> with the core source (except for potential interface issues).  I think this
>> would be a win/win for both core developers and third party developers.
>>
>> It's been a long day, and I don't think I'm getting my point across, so
>> please excuse me if I'm just rambling.  :)
>>
>> Best,
>> Jake
>>
>>
>>
>> Chuckk Hubbard wrote:
>>>
>>> On the other hand, the developer-friendly version just has Csound and
>>> then users figure out on their own how to interface with it.
>>> Seems the reality is somewhere in the middle.
>>> -Chuckk
>>>
>>> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin
>>> wrote:
>>>>
>>>> What if?
>>>>
>>>> Csound only comes in one variety, Csound Core. Csound Core is designed
>>>> with
>>>> an interface layer.  Developers design plugins/add-ons to Csound Core
>>>> using
>>>> this interface layer.  Users download and use Csound Core.  When a
>>>> particular user needs something more than Csound Core has to offer, they
>>>> go
>>>> to the Csound Plugin page, find what they are looking for, download, and
>>>> install.  After the installation, Csound Core automatically recognizes
>>>> the
>>>> plugin.  Csound Core does not need to be compiled, it just works.
>>>>
>>>> Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound,
>>>> FLTK
>>>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to
>>>> turn
>>>> on/off installed plugins), etc.  Third party software also uses this same
>>>> interface layer to use Csound as an audio engine.
>>>>
>>>> To me, this is nearly the ideal situation.  Is this possible. Absolutely!
>>>> Plausible, maybe?
>>>>
>>>> Best,
>>>> Jake
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
http://www.badmuthahubbard.com

I've been developing Csound GUI applications for about three or four
years and not once have I had the need to go near the core Csound
engine. It's through that FLTK is tied up with the Csound but if you
use the API you don't need to do any messing with Csound.

Rory.


2009/7/12 Chuckk Hubbard :
> I guess that proves it's a good idea.
> It's true that when I compile Csound, I leave out all of the GUI
> stuff, including FLTK, since I'm more comfortable with Python/Tk and
> Pure Data. This last time I left out the Loris and STK opcodes because
> I couldn't get them to compile, so I suppose what I end up with is
> pretty core. But the default from the installers probably has a lot
> that most 3rd-party developers won't use.
> -Chuckk
>
>
>
> On Sun, Jul 12, 2009 at 4:31 AM, Michael Gogins wrote:
>> This is the way it now is... or have I missed something?
>>
>> Regards,
>> Mike
>>
>> On 7/11/09, Jacob Joaquin  wrote:
>>>
>>> I don't believe there has to be a trade off between being user-friendly and
>>> developer-friendly.
>>>
>>> Going back to the original user story at the top of this thread, a system
>>> like the one proposed could potentially be easier for developers, granted
>>> after a lot of excruciating work initially.  Once that is done, we would
>>> have a system in which developers only need to focus on the core engine,
>>> core opcodes and the interface layer.  GUIs, scripting language support,
>>> etc. would be clearly separated from the core source, reducing the overall
>>> size of the core.  People wishing to extend (or embed) Csound would have to
>>> work through the interface layer/API, and thus absolving the need to tamper
>>> with the core source (except for potential interface issues).  I think this
>>> would be a win/win for both core developers and third party developers.
>>>
>>> It's been a long day, and I don't think I'm getting my point across, so
>>> please excuse me if I'm just rambling.  :)
>>>
>>> Best,
>>> Jake
>>>
>>>
>>>
>>> Chuckk Hubbard wrote:
>>>>
>>>> On the other hand, the developer-friendly version just has Csound and
>>>> then users figure out on their own how to interface with it.
>>>> Seems the reality is somewhere in the middle.
>>>> -Chuckk
>>>>
>>>> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin
>>>> wrote:
>>>>>
>>>>> What if?
>>>>>
>>>>> Csound only comes in one variety, Csound Core. Csound Core is designed
>>>>> with
>>>>> an interface layer.  Developers design plugins/add-ons to Csound Core
>>>>> using
>>>>> this interface layer.  Users download and use Csound Core.  When a
>>>>> particular user needs something more than Csound Core has to offer, they
>>>>> go
>>>>> to the Csound Plugin page, find what they are looking for, download, and
>>>>> install.  After the installation, Csound Core automatically recognizes
>>>>> the
>>>>> plugin.  Csound Core does not need to be compiled, it just works.
>>>>>
>>>>> Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound,
>>>>> FLTK
>>>>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to
>>>>> turn
>>>>> on/off installed plugins), etc.  Third party software also uses this same
>>>>> interface layer to use Csound as an audio engine.
>>>>>
>>>>> To me, this is nearly the ideal situation.  Is this possible. Absolutely!
>>>>> Plausible, maybe?
>>>>>
>>>>> Best,
>>>>> Jake
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
>
> --
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I'm looking through the source and manual and have identified some items
which may be considered non-core items (this is an entirely different
debate, so just consider these to be examples): CsoundAC, CsoundVST,
TclCsound, FLTK Widgets, Virtual MIDI Keyboard, Loris Opcodes, LADPSA,
Python opcodes, Image Processing opcodes, Cscore.

I'm suggesting that these are kept separate from the core source, and be
treated as plugins. This would mean the source for these are no longer
included in Csound5.x.x.tar.gz, no longer referenced in Building Csound, and
gathered into a single plug-in subsection in the manual that informs users
of their existence and function, but exclude documentation.  Each plugin is
kept as its own package, whether as a binary, source, or both, and come with
its own documentation.

In addition, being able to make and install a plugin should not require the
recompilation of a Csound binary.

Assuming the Loris line of opcodes are not part of Csound Core, and that
Csound Core is installed on a users system.  In order for the user to use
the loris opcodes, they would need to download a pre-built binary for their
system and install, or download the source, make and install.  No
recompilation of the existing Csound binary is necessary.  The loris opcodes
are now present with 'csound -z', and work as they do now.

If Csound is already capable of everything that I've just mentioned, then
that's great.  The goal here is to untangle Csound.  Having a clean and
organized environment will make Csound more developer-friendly, and
potentially have the side-effect of improving extensibility/embeddability.

I have this theory that we can grow the Csound community by making
everything inside-and-out more friendly to work with.  As the Csound
community grows, more people will volunteer to help grow Csound.

Best,
Jake


Michael Gogins-2 wrote:
> 
> This is the way it now is... or have I missed something?
> 
> Regards,
> Mike
> 
> On 7/11/09, Jacob Joaquin  wrote:
>>
>> I don't believe there has to be a trade off between being user-friendly
>> and
>> developer-friendly.
>>
>> Going back to the original user story at the top of this thread, a system
>> like the one proposed could potentially be easier for developers, granted
>> after a lot of excruciating work initially.  Once that is done, we would
>> have a system in which developers only need to focus on the core engine,
>> core opcodes and the interface layer.  GUIs, scripting language support,
>> etc. would be clearly separated from the core source, reducing the
>> overall
>> size of the core.  People wishing to extend (or embed) Csound would have
>> to
>> work through the interface layer/API, and thus absolving the need to
>> tamper
>> with the core source (except for potential interface issues).  I think
>> this
>> would be a win/win for both core developers and third party developers.
>>
>> It's been a long day, and I don't think I'm getting my point across, so
>> please excuse me if I'm just rambling.  :)
>>
>> Best,
>> Jake
>>
>>
>>
>> Chuckk Hubbard wrote:
>>>
>>> On the other hand, the developer-friendly version just has Csound and
>>> then users figure out on their own how to interface with it.
>>> Seems the reality is somewhere in the middle.
>>> -Chuckk
>>>
>>> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin
>>> wrote:
>>>>
>>>> What if?
>>>>
>>>> Csound only comes in one variety, Csound Core. Csound Core is designed
>>>> with
>>>> an interface layer.  Developers design plugins/add-ons to Csound Core
>>>> using
>>>> this interface layer.  Users download and use Csound Core.  When a
>>>> particular user needs something more than Csound Core has to offer,
>>>> they
>>>> go
>>>> to the Csound Plugin page, find what they are looking for, download,
>>>> and
>>>> install.  After the installation, Csound Core automatically recognizes
>>>> the
>>>> plugin.  Csound Core does not need to be compiled, it just works.
>>>>
>>>> Plugins include: Python, Java, VST, CsoundAC, Audio Units, TclCsound,
>>>> FLTK
>>>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows users to
>>>> turn
>>>> on/off installed plugins), etc.  Third party software also uses this
>>>> same
>>>> interface layer to use Csound as an audio engine.
>>>>
>>>> To me, this is nearly the ideal situation.  Is this possible.
>>>> Absolutely!
>>>> Plausible, maybe?
>>>>
>>>> Best,
>>>> Jake
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24450177.html
Sent from the Csound - General mailing list archive at Nabble.com.

Jake,

I don't mean to confuse the issue.  And I think you are raising and  
suggesting incredibly important issues and proposing
some important solutions too.

In my teaching and work, I tend to think of FLTK widgets and virtual  
keyboard as rather "core" items - or functionalities.

and,

The image processing opcodes are a part of my newest catalog and were  
very important in the OLPC work.

For instance, Ian McCurdy's instruments are an incredible collection  
and incredibly comprehensive and important set of tutorials - for the  
beginner to intermediate.

They rely on FLTK.  (have you checked them out lately?)

It is true that I often teach more than 3/4 of the semester at Berklee  
without getting to FLTK.  And now, with QuteCsound's fantastic  
widgets, I usually introduce
these to my students rather than the FLTK stuff - but.... for someone  
who is NOT in my class.  The McCurdy Collection is a major Csound  
Course in itself.

(Thanks Ian)

-dB

Dr. Richard Boulanger  -  rboulanger@berklee.edu



On Jul 12, 2009, at 12:36 PM, Jacob Joaquin wrote:

>
> I'm looking through the source and manual and have identified some  
> items
> which may be considered non-core items (this is an entirely different
> debate, so just consider these to be examples): CsoundAC, CsoundVST,
> TclCsound, FLTK Widgets, Virtual MIDI Keyboard, Loris Opcodes, LADPSA,
> Python opcodes, Image Processing opcodes, Cscore.
>
> I'm suggesting that these are kept separate from the core source,  
> and be
> treated as plugins. This would mean the source for these are no longer
> included in Csound5.x.x.tar.gz, no longer referenced in Building  
> Csound, and
> gathered into a single plug-in subsection in the manual that informs  
> users
> of their existence and function, but exclude documentation.  Each  
> plugin is
> kept as its own package, whether as a binary, source, or both, and  
> come with
> its own documentation.
>
> In addition, being able to make and install a plugin should not  
> require the
> recompilation of a Csound binary.
>
> Assuming the Loris line of opcodes are not part of Csound Core, and  
> that
> Csound Core is installed on a users system.  In order for the user  
> to use
> the loris opcodes, they would need to download a pre-built binary  
> for their
> system and install, or download the source, make and install.  No
> recompilation of the existing Csound binary is necessary.  The loris  
> opcodes
> are now present with 'csound -z', and work as they do now.
>
> If Csound is already capable of everything that I've just mentioned,  
> then
> that's great.  The goal here is to untangle Csound.  Having a clean  
> and
> organized environment will make Csound more developer-friendly, and
> potentially have the side-effect of improving extensibility/ 
> embeddability.
>
> I have this theory that we can grow the Csound community by making
> everything inside-and-out more friendly to work with.  As the Csound
> community grows, more people will volunteer to help grow Csound.
>
> Best,
> Jake
>
>
> Michael Gogins-2 wrote:
>>
>> This is the way it now is... or have I missed something?
>>
>> Regards,
>> Mike
>>
>> On 7/11/09, Jacob Joaquin  wrote:
>>>
>>> I don't believe there has to be a trade off between being user- 
>>> friendly
>>> and
>>> developer-friendly.
>>>
>>> Going back to the original user story at the top of this thread, a  
>>> system
>>> like the one proposed could potentially be easier for developers,  
>>> granted
>>> after a lot of excruciating work initially.  Once that is done, we  
>>> would
>>> have a system in which developers only need to focus on the core  
>>> engine,
>>> core opcodes and the interface layer.  GUIs, scripting language  
>>> support,
>>> etc. would be clearly separated from the core source, reducing the
>>> overall
>>> size of the core.  People wishing to extend (or embed) Csound  
>>> would have
>>> to
>>> work through the interface layer/API, and thus absolving the need to
>>> tamper
>>> with the core source (except for potential interface issues).  I  
>>> think
>>> this
>>> would be a win/win for both core developers and third party  
>>> developers.
>>>
>>> It's been a long day, and I don't think I'm getting my point  
>>> across, so
>>> please excuse me if I'm just rambling.  :)
>>>
>>> Best,
>>> Jake
>>>
>>>
>>>
>>> Chuckk Hubbard wrote:
>>>>
>>>> On the other hand, the developer-friendly version just has Csound  
>>>> and
>>>> then users figure out on their own how to interface with it.
>>>> Seems the reality is somewhere in the middle.
>>>> -Chuckk
>>>>
>>>> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin>>> >
>>>> wrote:
>>>>>
>>>>> What if?
>>>>>
>>>>> Csound only comes in one variety, Csound Core. Csound Core is  
>>>>> designed
>>>>> with
>>>>> an interface layer.  Developers design plugins/add-ons to Csound  
>>>>> Core
>>>>> using
>>>>> this interface layer.  Users download and use Csound Core.  When a
>>>>> particular user needs something more than Csound Core has to  
>>>>> offer,
>>>>> they
>>>>> go
>>>>> to the Csound Plugin page, find what they are looking for,  
>>>>> download,
>>>>> and
>>>>> install.  After the installation, Csound Core automatically  
>>>>> recognizes
>>>>> the
>>>>> plugin.  Csound Core does not need to be compiled, it just works.
>>>>>
>>>>> Plugins include: Python, Java, VST, CsoundAC, Audio Units,  
>>>>> TclCsound,
>>>>> FLTK
>>>>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows  
>>>>> users to
>>>>> turn
>>>>> on/off installed plugins), etc.  Third party software also uses  
>>>>> this
>>>>> same
>>>>> interface layer to use Csound as an audio engine.
>>>>>
>>>>> To me, this is nearly the ideal situation.  Is this possible.
>>>>> Absolutely!
>>>>> Plausible, maybe?
>>>>>
>>>>> Best,
>>>>> Jake
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>> -- 
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24450177.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Don't read too much into that list.  I included everything I could identify
that might be considered non-core, knowing I was going overboard.  Had I
kept going, I might have included OSC and MIDI.  :)

That being said.  If installing plugins were essentially no-brainers, it
wouldn't make a difference whether or not certain functionality was core or
not.  For example, I recently installed Sphinx docs to document the python
package I'm working on.  This is what I had to do to install Sphinx, using
Python eggs:

$ sudo easy_install
http://pypi.python.org/packages/2.5/S/Sphinx/Sphinx-0.6.2-py2.5.egg#md5=2ab5663b74eb7c654311696529e7b708

(that third parameter is just the link)

I didn't even have to download the file, it did it for me.  Imagine
something like that Csound.  Extending Csound, if implemented just right,
would be nearly seamless.

A Csound GUI, such as QuteCsound could be designed to list all available
plugins at any given moment, where the user just check-marks the plugins
they want and then click the install.

Best,
Jake



csounder wrote:
> 
> Jake,
> 
> I don't mean to confuse the issue.  And I think you are raising and  
> suggesting incredibly important issues and proposing
> some important solutions too.
> 
> In my teaching and work, I tend to think of FLTK widgets and virtual  
> keyboard as rather "core" items - or functionalities.
> 
> and,
> 
> The image processing opcodes are a part of my newest catalog and were  
> very important in the OLPC work.
> 
> For instance, Ian McCurdy's instruments are an incredible collection  
> and incredibly comprehensive and important set of tutorials - for the  
> beginner to intermediate.
> 
> They rely on FLTK.  (have you checked them out lately?)
> 
> It is true that I often teach more than 3/4 of the semester at Berklee  
> without getting to FLTK.  And now, with QuteCsound's fantastic  
> widgets, I usually introduce
> these to my students rather than the FLTK stuff - but.... for someone  
> who is NOT in my class.  The McCurdy Collection is a major Csound  
> Course in itself.
> 
> (Thanks Ian)
> 
> -dB
> 
> Dr. Richard Boulanger  -  rboulanger@berklee.edu
> 
> 
> 
> On Jul 12, 2009, at 12:36 PM, Jacob Joaquin wrote:
> 
>>
>> I'm looking through the source and manual and have identified some  
>> items
>> which may be considered non-core items (this is an entirely different
>> debate, so just consider these to be examples): CsoundAC, CsoundVST,
>> TclCsound, FLTK Widgets, Virtual MIDI Keyboard, Loris Opcodes, LADPSA,
>> Python opcodes, Image Processing opcodes, Cscore.
>>
>> I'm suggesting that these are kept separate from the core source,  
>> and be
>> treated as plugins. This would mean the source for these are no longer
>> included in Csound5.x.x.tar.gz, no longer referenced in Building  
>> Csound, and
>> gathered into a single plug-in subsection in the manual that informs  
>> users
>> of their existence and function, but exclude documentation.  Each  
>> plugin is
>> kept as its own package, whether as a binary, source, or both, and  
>> come with
>> its own documentation.
>>
>> In addition, being able to make and install a plugin should not  
>> require the
>> recompilation of a Csound binary.
>>
>> Assuming the Loris line of opcodes are not part of Csound Core, and  
>> that
>> Csound Core is installed on a users system.  In order for the user  
>> to use
>> the loris opcodes, they would need to download a pre-built binary  
>> for their
>> system and install, or download the source, make and install.  No
>> recompilation of the existing Csound binary is necessary.  The loris  
>> opcodes
>> are now present with 'csound -z', and work as they do now.
>>
>> If Csound is already capable of everything that I've just mentioned,  
>> then
>> that's great.  The goal here is to untangle Csound.  Having a clean  
>> and
>> organized environment will make Csound more developer-friendly, and
>> potentially have the side-effect of improving extensibility/ 
>> embeddability.
>>
>> I have this theory that we can grow the Csound community by making
>> everything inside-and-out more friendly to work with.  As the Csound
>> community grows, more people will volunteer to help grow Csound.
>>
>> Best,
>> Jake
>>
>>
>> Michael Gogins-2 wrote:
>>>
>>> This is the way it now is... or have I missed something?
>>>
>>> Regards,
>>> Mike
>>>
>>> On 7/11/09, Jacob Joaquin  wrote:
>>>>
>>>> I don't believe there has to be a trade off between being user- 
>>>> friendly
>>>> and
>>>> developer-friendly.
>>>>
>>>> Going back to the original user story at the top of this thread, a  
>>>> system
>>>> like the one proposed could potentially be easier for developers,  
>>>> granted
>>>> after a lot of excruciating work initially.  Once that is done, we  
>>>> would
>>>> have a system in which developers only need to focus on the core  
>>>> engine,
>>>> core opcodes and the interface layer.  GUIs, scripting language  
>>>> support,
>>>> etc. would be clearly separated from the core source, reducing the
>>>> overall
>>>> size of the core.  People wishing to extend (or embed) Csound  
>>>> would have
>>>> to
>>>> work through the interface layer/API, and thus absolving the need to
>>>> tamper
>>>> with the core source (except for potential interface issues).  I  
>>>> think
>>>> this
>>>> would be a win/win for both core developers and third party  
>>>> developers.
>>>>
>>>> It's been a long day, and I don't think I'm getting my point  
>>>> across, so
>>>> please excuse me if I'm just rambling.  :)
>>>>
>>>> Best,
>>>> Jake
>>>>
>>>>
>>>>
>>>> Chuckk Hubbard wrote:
>>>>>
>>>>> On the other hand, the developer-friendly version just has Csound  
>>>>> and
>>>>> then users figure out on their own how to interface with it.
>>>>> Seems the reality is somewhere in the middle.
>>>>> -Chuckk
>>>>>
>>>>> On Wed, Jul 8, 2009 at 7:02 PM, Jacob Joaquin>>>> >
>>>>> wrote:
>>>>>>
>>>>>> What if?
>>>>>>
>>>>>> Csound only comes in one variety, Csound Core. Csound Core is  
>>>>>> designed
>>>>>> with
>>>>>> an interface layer.  Developers design plugins/add-ons to Csound  
>>>>>> Core
>>>>>> using
>>>>>> this interface layer.  Users download and use Csound Core.  When a
>>>>>> particular user needs something more than Csound Core has to  
>>>>>> offer,
>>>>>> they
>>>>>> go
>>>>>> to the Csound Plugin page, find what they are looking for,  
>>>>>> download,
>>>>>> and
>>>>>> install.  After the installation, Csound Core automatically  
>>>>>> recognizes
>>>>>> the
>>>>>> plugin.  Csound Core does not need to be compiled, it just works.
>>>>>>
>>>>>> Plugins include: Python, Java, VST, CsoundAC, Audio Units,  
>>>>>> TclCsound,
>>>>>> FLTK
>>>>>> Widgets, Virtual MIDI Keyboard, LADSPA, Plugin Manager (allows  
>>>>>> users to
>>>>>> turn
>>>>>> on/off installed plugins), etc.  Third party software also uses  
>>>>>> this
>>>>>> same
>>>>>> interface layer to use Csound as an audio engine.
>>>>>>
>>>>>> To me, this is nearly the ideal situation.  Is this possible.
>>>>>> Absolutely!
>>>>>> Plausible, maybe?
>>>>>>
>>>>>> Best,
>>>>>> Jake
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24393267.html
>>>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24444776.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> -- 
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24450177.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24450667.html
Sent from the Csound - General mailing list archive at Nabble.com.

i think I am confused.  Csound5 has plugins which are simple to use. 
Things like Loris are optionalas it is.  As a developer I have to ensure
that all plugins in the CVS compile and are available.  The original
design was to allow 3rd party plugins, not necessarily LGPL, to be made
available.
  There is a packaging issue, what to put in what package.  For example in
OpenSuSE emacs is not one package but a lot, and you can chose what to
install.  We have made that available; it i just that no one i using it!

My coe cound and your core csound are probably VERY different (I have no
GUI, No fancy graphics etc....)]

==John ff

I'm trying to make the case that optional features be placed outside of the
main csound source, and treated as plugins.

There will be plugins, such as Loris, that would be considered officially
sanctioned Csound plugins, that would still be hosted at the Cound CVS and
maintained by Csound devs.  Other plugins would be developed by
third-parties, but would be listed in the Csound online plugins directory. 
And then there would be those pet projects by Csound devs and others in the
community that have the potential to become officially sanctioned as first
party plugins, after passing some sort of community standard.

Here are some loose guidelines as to what may determine if a feature is core
or not:

* Is it optional?
* Does it rely on a non-vital external library to build? (libsndfile would
be considered vital)
* Has it reached maturity?  (thoroughly tested, well documented)
* Is it cross-platform among the major systems (*nix, windows, mac, olpc,
etc)

As for what is Csound Core?  I may have been unintentionally confusing two
different topics:  The core Csound source code and the core Csound installer
proposed by Michael Gogins as a windows installer in this thread:

http://www.nabble.com/Windows-installers-tt24325333.html

In terms of what I've been talking about in this thread, I've been referring
mostly to the source code.

As for what I use, I just use my favorite text editor of choice and a couple
of open terminal windows.  No GUI or fancy graphics for me, either.  :)

Best,
Jake






jpff-2 wrote:
> 
> i think I am confused.  Csound5 has plugins which are simple to use. 
> Things like Loris are optionalas it is.  As a developer I have to ensure
> that all plugins in the CVS compile and are available.  The original
> design was to allow 3rd party plugins, not necessarily LGPL, to be made
> available.
>   There is a packaging issue, what to put in what package.  For example in
> OpenSuSE emacs is not one package but a lot, and you can chose what to
> install.  We have made that available; it i just that no one i using it!
> 
> My coe cound and your core csound are probably VERY different (I have no
> GUI, No fancy graphics etc....)]
> 
> ==John ff
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24451640.html
Sent from the Csound - General mailing list archive at Nabble.com.

>
> I'm trying to make the case that optional features be placed outside of
> the
> main csound source, and treated as plugins.
>
>

Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are ones
that cannot be factored out. Engine is essential....

Still sounds like packaging

Okay, I think I see why my terminology is a bit confusing.  I've been using
the term plugin in a somewhat generic fashion, where 'plugin' seems to have
an existing specific meaning in Csound.  So perhaps it is indeed packaging
in which I'm referring to.  So let me sure I have this right.

Being that the loris opcodes requires a special-case external dependency, it
would be better if loris was removed from the main Csound source.  Instead,
loris should be placed into its own package, separate from the core Csound
source code, in which users could install later.  The package would include
documentation, source to the loris opcodes, and perhaps the binaries.

Plugin unit generators/opcodes that do depend on external dependencies would
still be part of the csound core source.  e.g. biquad.

Other parts of Csound that may be separated from the core Csound source and
broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK Widgets
(maybe not this one), Virtual MIDI Keyboard (maybe not this one, etiher),
Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, Cscore. 

Best,
Jake






jpff-2 wrote:
> 
>>
>> I'm trying to make the case that optional features be placed outside of
>> the
>> main csound source, and treated as plugins.
>>
>>
> 
> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are ones
> that cannot be factored out. Engine is essential....
> 
> Still sounds like packaging
> 
> 
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
Sent from the Csound - General mailing list archive at Nabble.com.

I'm not sure whether you are talking about building, or about installation.

For installation on Linux, most of the things you talk about already
are separate packages.

For installation on Windows, the next installer will provide the user
options on which subsets of Csound to install.

For building, the build system already offers options for building or
not building each of these things.

I would urge you to consider that what one user considers 'optional'
or 'outside' Csound is not necessarily the same as what another user
would. In such a case, I think it is better to be inclusive rather
than exclusive.

But perhaps I'm not quite hearing what you are trying to say.

Regards,
Mike

On 7/12/09, Jacob Joaquin  wrote:
>
> Okay, I think I see why my terminology is a bit confusing.  I've been using
> the term plugin in a somewhat generic fashion, where 'plugin' seems to have
> an existing specific meaning in Csound.  So perhaps it is indeed packaging
> in which I'm referring to.  So let me sure I have this right.
>
> Being that the loris opcodes requires a special-case external dependency, it
> would be better if loris was removed from the main Csound source.  Instead,
> loris should be placed into its own package, separate from the core Csound
> source code, in which users could install later.  The package would include
> documentation, source to the loris opcodes, and perhaps the binaries.
>
> Plugin unit generators/opcodes that do depend on external dependencies would
> still be part of the csound core source.  e.g. biquad.
>
> Other parts of Csound that may be separated from the core Csound source and
> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK Widgets
> (maybe not this one), Virtual MIDI Keyboard (maybe not this one, etiher),
> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, Cscore.
>
> Best,
> Jake
>
>
>
>
>
>
> jpff-2 wrote:
>>
>>>
>>> I'm trying to make the case that optional features be placed outside of
>>> the
>>> main csound source, and treated as plugins.
>>>
>>>
>>
>> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are ones
>> that cannot be factored out. Engine is essential....
>>
>> Still sounds like packaging
>>
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Let's say I have Csound built on my system with no optional configurations. 
Can I build each option individually as I need them, without re-compiling
Csound?  E.G. FLTK, OSC, STK, Loris, etc.

Best,
Jake


Michael Gogins-2 wrote:
> 
> I'm not sure whether you are talking about building, or about
> installation.
> 
> For installation on Linux, most of the things you talk about already
> are separate packages.
> 
> For installation on Windows, the next installer will provide the user
> options on which subsets of Csound to install.
> 
> For building, the build system already offers options for building or
> not building each of these things.
> 
> I would urge you to consider that what one user considers 'optional'
> or 'outside' Csound is not necessarily the same as what another user
> would. In such a case, I think it is better to be inclusive rather
> than exclusive.
> 
> But perhaps I'm not quite hearing what you are trying to say.
> 
> Regards,
> Mike
> 
> On 7/12/09, Jacob Joaquin  wrote:
>>
>> Okay, I think I see why my terminology is a bit confusing.  I've been
>> using
>> the term plugin in a somewhat generic fashion, where 'plugin' seems to
>> have
>> an existing specific meaning in Csound.  So perhaps it is indeed
>> packaging
>> in which I'm referring to.  So let me sure I have this right.
>>
>> Being that the loris opcodes requires a special-case external dependency,
>> it
>> would be better if loris was removed from the main Csound source. 
>> Instead,
>> loris should be placed into its own package, separate from the core
>> Csound
>> source code, in which users could install later.  The package would
>> include
>> documentation, source to the loris opcodes, and perhaps the binaries.
>>
>> Plugin unit generators/opcodes that do depend on external dependencies
>> would
>> still be part of the csound core source.  e.g. biquad.
>>
>> Other parts of Csound that may be separated from the core Csound source
>> and
>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK Widgets
>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one, etiher),
>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, Cscore.
>>
>> Best,
>> Jake
>>
>>
>>
>>
>>
>>
>> jpff-2 wrote:
>>>
>>>>
>>>> I'm trying to make the case that optional features be placed outside of
>>>> the
>>>> main csound source, and treated as plugins.
>>>>
>>>>
>>>
>>> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are
>>> ones
>>> that cannot be factored out. Engine is essential....
>>>
>>> Still sounds like packaging
>>>
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453191.html
Sent from the Csound - General mailing list archive at Nabble.com.

>
> Let's say I have Csound built on my system with no optional
> configurations.
> Can I build each option individually as I need them, without re-compiling
> Csound?  E.G. FLTK, OSC, STK, Loris, etc.
>
> Best,
> Jake

Yes as long as you haave the headers for the same API version

Actually not sre aout FLTK -- that is too enbedded for my taste, but that
has been argumed endlessly

==John ff

That's great to hear.   Now if I was to compile and install one of these
optional configurations, without re-compiling Csound, where in the
documentation can I find instructions on how to do this?

Best,
Jake


jpff-2 wrote:
> 
>>
>> Let's say I have Csound built on my system with no optional
>> configurations.
>> Can I build each option individually as I need them, without re-compiling
>> Csound?  E.G. FLTK, OSC, STK, Loris, etc.
>>
>> Best,
>> Jake
> 
> Yes as long as you haave the headers for the same API version
> 
> Actually not sre aout FLTK -- that is too enbedded for my taste, but that
> has been argumed endlessly
> 
> ==John ff
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453328.html
Sent from the Csound - General mailing list archive at Nabble.com.

You should think about ways to continue supporting FLTK but not embed  
it so deeply into the core.  It should be mire of a plug-in.


Sent from my Arp 2600 ;-)


On Jul 12, 2009, at 6:52 PM, jpff@cs.bath.ac.uk wrote:

>>
>> Let's say I have Csound built on my system with no optional
>> configurations.
>> Can I build each option individually as I need them, without re- 
>> compiling
>> Csound?  E.G. FLTK, OSC, STK, Loris, etc.
>>
>> Best,
>> Jake
>
> Yes as long as you haave the headers for the same API version
>
> Actually not sre aout FLTK -- that is too enbedded for my taste, but  
> that
> has been argumed endlessly
>
> ==John ff
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

It seems to me that the _idea_ of being able to use a cut-down version  
(CDV) is a good one. However, what's included, what's not must be  
defined by the conceptual design of the system as a whole, rather than  
some definition based on some loose agreement between the current  
needs of individual users. Someone might want FLTK, someone else MIDI  
but not python, python and OSC but not MIDI, LORIS opcodes etc. Then  
others might want filters and soundfile processing but not synthesis.  
Trying to build a system on that sort of basis quickly becomes a  
nightmare.

SC is designed around the idea of a "sound server" and a language that  
supports/sends commands to it. While I'm not suggesting that is an  
optimal solution (I think there problems) the idea of functional  
segregation is a good idea. As Mike says, the current build options do  
provide various options, once you know what you're doing. But there  
doesn't seem to be any conceptual hierarchy beyond  shall a feature be  
included or not, as well as the important one of K and S rate. So if  
you're interested in building a version with X but not Y, conceptually  
it's quite simple but implementing it seems to require more of an in- 
depth understanding of the whole system than should be necessary.

If we have
Sound: [input, output, synthesis, processing ]
Graphic: [input, output, (synthesis, processing )]
SoundControl: [input, output, dynamic]
GraphicControl:[input, output, dynamic]

- and this is mirrored in the documentation-

The sources for each of these could be contained in various separate  
directories and it is clear what the limitations are - especially  
platform limitations. Perhaps separate directories for each platform  
as clearly indicated in directory name, including an AllPlat 'tag'
IMO there needs to be no more than a dozen files/directories in at the  
top level, including a separate directory for tests and other 'guru'  
experiments.

David

On 13/07/2009, at 8:23 AM, Michael Gogins wrote:

> I'm not sure whether you are talking about building, or about  
> installation.
>
> For installation on Linux, most of the things you talk about already
> are separate packages.
>
> For installation on Windows, the next installer will provide the user
> options on which subsets of Csound to install.
>
> For building, the build system already offers options for building or
> not building each of these things.
>
> I would urge you to consider that what one user considers 'optional'
> or 'outside' Csound is not necessarily the same as what another user
> would. In such a case, I think it is better to be inclusive rather
> than exclusive.
>
> But perhaps I'm not quite hearing what you are trying to say.
>
> Regards,
> Mike
>
> On 7/12/09, Jacob Joaquin  wrote:
>>
>> Okay, I think I see why my terminology is a bit confusing.  I've  
>> been using
>> the term plugin in a somewhat generic fashion, where 'plugin' seems  
>> to have
>> an existing specific meaning in Csound.  So perhaps it is indeed  
>> packaging
>> in which I'm referring to.  So let me sure I have this right.
>>
>> Being that the loris opcodes requires a special-case external  
>> dependency, it
>> would be better if loris was removed from the main Csound source.   
>> Instead,
>> loris should be placed into its own package, separate from the core  
>> Csound
>> source code, in which users could install later.  The package would  
>> include
>> documentation, source to the loris opcodes, and perhaps the binaries.
>>
>> Plugin unit generators/opcodes that do depend on external  
>> dependencies would
>> still be part of the csound core source.  e.g. biquad.
>>
>> Other parts of Csound that may be separated from the core Csound  
>> source and
>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK  
>> Widgets
>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one,  
>> etiher),
>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes,  
>> Cscore.
>>
>> Best,
>> Jake
>>
>>
>>
>>
>>
>>
>> jpff-2 wrote:
>>>
>>>>
>>>> I'm trying to make the case that optional features be placed  
>>>> outside of
>>>> the
>>>> main csound source, and treated as plugins.
>>>>
>>>>
>>>
>>> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps  
>>> are ones
>>> that cannot be factored out. Engine is essential....
>>>
>>> Still sounds like packaging
>>>
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

________________________________________________
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
- MARCS Auditory Laboratories: marcs.uws.edu.au

So you're talking about building.
.
The answer to your question is yes. You pass the name of the target to
SCons, but the name of the target is not always obvious.

I use a shell script to build, with all my SConstruct options
predefined, plus some additional wildard options. Then I can just say
./build.sh myplugin.so to build my plugin opcode. I have done this and
it works fine. It should work other targets as well.

Hope this helps,
Mike

On 7/12/09, Jacob Joaquin  wrote:
>
> Let's say I have Csound built on my system with no optional configurations.
> Can I build each option individually as I need them, without re-compiling
> Csound?  E.G. FLTK, OSC, STK, Loris, etc.
>
> Best,
> Jake
>
>
> Michael Gogins-2 wrote:
>>
>> I'm not sure whether you are talking about building, or about
>> installation.
>>
>> For installation on Linux, most of the things you talk about already
>> are separate packages.
>>
>> For installation on Windows, the next installer will provide the user
>> options on which subsets of Csound to install.
>>
>> For building, the build system already offers options for building or
>> not building each of these things.
>>
>> I would urge you to consider that what one user considers 'optional'
>> or 'outside' Csound is not necessarily the same as what another user
>> would. In such a case, I think it is better to be inclusive rather
>> than exclusive.
>>
>> But perhaps I'm not quite hearing what you are trying to say.
>>
>> Regards,
>> Mike
>>
>> On 7/12/09, Jacob Joaquin  wrote:
>>>
>>> Okay, I think I see why my terminology is a bit confusing.  I've been
>>> using
>>> the term plugin in a somewhat generic fashion, where 'plugin' seems to
>>> have
>>> an existing specific meaning in Csound.  So perhaps it is indeed
>>> packaging
>>> in which I'm referring to.  So let me sure I have this right.
>>>
>>> Being that the loris opcodes requires a special-case external dependency,
>>> it
>>> would be better if loris was removed from the main Csound source.
>>> Instead,
>>> loris should be placed into its own package, separate from the core
>>> Csound
>>> source code, in which users could install later.  The package would
>>> include
>>> documentation, source to the loris opcodes, and perhaps the binaries.
>>>
>>> Plugin unit generators/opcodes that do depend on external dependencies
>>> would
>>> still be part of the csound core source.  e.g. biquad.
>>>
>>> Other parts of Csound that may be separated from the core Csound source
>>> and
>>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK Widgets
>>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one, etiher),
>>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, Cscore.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>>
>>>
>>>
>>>
>>> jpff-2 wrote:
>>>>
>>>>>
>>>>> I'm trying to make the case that optional features be placed outside of
>>>>> the
>>>>> main csound source, and treated as plugins.
>>>>>
>>>>>
>>>>
>>>> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are
>>>> ones
>>>> that cannot be factored out. Engine is essential....
>>>>
>>>> Still sounds like packaging
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453191.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

This does help. Is build.sh part of the Csound source, or a custom script for
personal use?

Best,
Jake


Michael Gogins-2 wrote:
> 
> So you're talking about building.
> .
> The answer to your question is yes. You pass the name of the target to
> SCons, but the name of the target is not always obvious.
> 
> I use a shell script to build, with all my SConstruct options
> predefined, plus some additional wildard options. Then I can just say
> ./build.sh myplugin.so to build my plugin opcode. I have done this and
> it works fine. It should work other targets as well.
> 
> Hope this helps,
> Mike
> 
> On 7/12/09, Jacob Joaquin  wrote:
>>
>> Let's say I have Csound built on my system with no optional
>> configurations.
>> Can I build each option individually as I need them, without re-compiling
>> Csound?  E.G. FLTK, OSC, STK, Loris, etc.
>>
>> Best,
>> Jake
>>
>>
>> Michael Gogins-2 wrote:
>>>
>>> I'm not sure whether you are talking about building, or about
>>> installation.
>>>
>>> For installation on Linux, most of the things you talk about already
>>> are separate packages.
>>>
>>> For installation on Windows, the next installer will provide the user
>>> options on which subsets of Csound to install.
>>>
>>> For building, the build system already offers options for building or
>>> not building each of these things.
>>>
>>> I would urge you to consider that what one user considers 'optional'
>>> or 'outside' Csound is not necessarily the same as what another user
>>> would. In such a case, I think it is better to be inclusive rather
>>> than exclusive.
>>>
>>> But perhaps I'm not quite hearing what you are trying to say.
>>>
>>> Regards,
>>> Mike
>>>
>>> On 7/12/09, Jacob Joaquin  wrote:
>>>>
>>>> Okay, I think I see why my terminology is a bit confusing.  I've been
>>>> using
>>>> the term plugin in a somewhat generic fashion, where 'plugin' seems to
>>>> have
>>>> an existing specific meaning in Csound.  So perhaps it is indeed
>>>> packaging
>>>> in which I'm referring to.  So let me sure I have this right.
>>>>
>>>> Being that the loris opcodes requires a special-case external
>>>> dependency,
>>>> it
>>>> would be better if loris was removed from the main Csound source.
>>>> Instead,
>>>> loris should be placed into its own package, separate from the core
>>>> Csound
>>>> source code, in which users could install later.  The package would
>>>> include
>>>> documentation, source to the loris opcodes, and perhaps the binaries.
>>>>
>>>> Plugin unit generators/opcodes that do depend on external dependencies
>>>> would
>>>> still be part of the csound core source.  e.g. biquad.
>>>>
>>>> Other parts of Csound that may be separated from the core Csound source
>>>> and
>>>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK
>>>> Widgets
>>>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one,
>>>> etiher),
>>>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes,
>>>> Cscore.
>>>>
>>>> Best,
>>>> Jake
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> jpff-2 wrote:
>>>>>
>>>>>>
>>>>>> I'm trying to make the case that optional features be placed outside
>>>>>> of
>>>>>> the
>>>>>> main csound source, and treated as plugins.
>>>>>>
>>>>>>
>>>>>
>>>>> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are
>>>>> ones
>>>>> that cannot be factored out. Engine is essential....
>>>>>
>>>>> Still sounds like packaging
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453191.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453845.html
Sent from the Csound - General mailing list archive at Nabble.com.

It's customized, but there are variants of it in CVS. You could
customize one of these yourself. The same goes for customizing
custom.py, you could create a build.jj.sh that calls SCons with
custom.jj.py.

Regards,
Mike

On 7/12/09, Jacob Joaquin  wrote:
>
> This does help. Is build.sh part of the Csound source, or a custom script
> for
> personal use?
>
> Best,
> Jake
>
>
> Michael Gogins-2 wrote:
>>
>> So you're talking about building.
>> .
>> The answer to your question is yes. You pass the name of the target to
>> SCons, but the name of the target is not always obvious.
>>
>> I use a shell script to build, with all my SConstruct options
>> predefined, plus some additional wildard options. Then I can just say
>> ./build.sh myplugin.so to build my plugin opcode. I have done this and
>> it works fine. It should work other targets as well.
>>
>> Hope this helps,
>> Mike
>>
>> On 7/12/09, Jacob Joaquin  wrote:
>>>
>>> Let's say I have Csound built on my system with no optional
>>> configurations.
>>> Can I build each option individually as I need them, without re-compiling
>>> Csound?  E.G. FLTK, OSC, STK, Loris, etc.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>> Michael Gogins-2 wrote:
>>>>
>>>> I'm not sure whether you are talking about building, or about
>>>> installation.
>>>>
>>>> For installation on Linux, most of the things you talk about already
>>>> are separate packages.
>>>>
>>>> For installation on Windows, the next installer will provide the user
>>>> options on which subsets of Csound to install.
>>>>
>>>> For building, the build system already offers options for building or
>>>> not building each of these things.
>>>>
>>>> I would urge you to consider that what one user considers 'optional'
>>>> or 'outside' Csound is not necessarily the same as what another user
>>>> would. In such a case, I think it is better to be inclusive rather
>>>> than exclusive.
>>>>
>>>> But perhaps I'm not quite hearing what you are trying to say.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On 7/12/09, Jacob Joaquin  wrote:
>>>>>
>>>>> Okay, I think I see why my terminology is a bit confusing.  I've been
>>>>> using
>>>>> the term plugin in a somewhat generic fashion, where 'plugin' seems to
>>>>> have
>>>>> an existing specific meaning in Csound.  So perhaps it is indeed
>>>>> packaging
>>>>> in which I'm referring to.  So let me sure I have this right.
>>>>>
>>>>> Being that the loris opcodes requires a special-case external
>>>>> dependency,
>>>>> it
>>>>> would be better if loris was removed from the main Csound source.
>>>>> Instead,
>>>>> loris should be placed into its own package, separate from the core
>>>>> Csound
>>>>> source code, in which users could install later.  The package would
>>>>> include
>>>>> documentation, source to the loris opcodes, and perhaps the binaries.
>>>>>
>>>>> Plugin unit generators/opcodes that do depend on external dependencies
>>>>> would
>>>>> still be part of the csound core source.  e.g. biquad.
>>>>>
>>>>> Other parts of Csound that may be separated from the core Csound source
>>>>> and
>>>>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK
>>>>> Widgets
>>>>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one,
>>>>> etiher),
>>>>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes,
>>>>> Cscore.
>>>>>
>>>>> Best,
>>>>> Jake
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> jpff-2 wrote:
>>>>>>
>>>>>>>
>>>>>>> I'm trying to make the case that optional features be placed outside
>>>>>>> of
>>>>>>> the
>>>>>>> main csound source, and treated as plugins.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Still not sure I follow.  Plugin opocodes are in Opcodes.   OOps are
>>>>>> ones
>>>>>> that cannot be factored out. Engine is essential....
>>>>>>
>>>>>> Still sounds like packaging
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html
>>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453191.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453845.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com