The 'User-Friendly' Alternate Reality of Csound

[Jacob Joaquin]

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

[Stéphane Rollandin]

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

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

Stef



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

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 :)

[David Worrall]

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







Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[David Worrall]

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@... with body "unsubscribe csound"

[Jacob Joaquin]

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 [e-mail] with body "unsubscribe csound"

[Chuckk Hubbard]

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<jacobjoaquin@...> 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@... with body "unsubscribe csound"
>

--
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

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<[e-mail]> 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 [e-mail] with body "unsubscribe csound"
>



--
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email [e-mail] with body "unsubscribe csound"

[Michael Gogins-2]

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

Regards,
Mike

On 7/11/09, Jacob Joaquin <jacobjoaquin@...> 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<jacobjoaquin@...>
>> 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@... with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... 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@... 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@... with body "unsubscribe csound"

[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<michael.gogins@...> wrote:

> This is the way it now is... or have I missed something?
>
> Regards,
> Mike
>
> On 7/11/09, Jacob Joaquin <jacobjoaquin@...> 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<jacobjoaquin@...>
>>> 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@... with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... 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@... 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@... with body "unsubscribe csound"
>

--
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[RoryWalsh]

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 <badmuthahubbard@...>:

> 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<michael.gogins@...> wrote:
>> This is the way it now is... or have I missed something?
>>
>> Regards,
>> Mike
>>
>> On 7/11/09, Jacob Joaquin <jacobjoaquin@...> 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<jacobjoaquin@...>
>>>> 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@... with body "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@... 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@... 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@... with body "unsubscribe csound"
>>
>
>
>
> --
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe csound"

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

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 <[e-mail]> 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<[e-mail]>
>> 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 [e-mail] with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email [e-mail] 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 [e-mail] 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 [e-mail] with body "unsubscribe csound"

[csounder]

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@...



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 <jacobjoaquin@...> 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<jacobjoaquin@...
>>>> >
>>>> 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@... with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@... 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@... 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@... 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@... with body  
> "unsubscribe csound"

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

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  -  [e-mail]



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 <[e-mail]> 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<[e-mail]
>>>> >
>>>> 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 [e-mail] with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail] with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email [e-mail] with body "unsubscribe csound"

[jpff-2]

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@... with body "unsubscribe csound"

[Jacob Joaquin]

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 [e-mail] with body "unsubscribe csound"

[jpff-2]

>
> 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@... with body "unsubscribe csound"

[Jacob Joaquin]

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 [e-mail] with body "unsubscribe csound"

[Michael Gogins-2]

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 <jacobjoaquin@...> 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@... 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@... 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@... with body "unsubscribe csound"

[Jacob Joaquin]

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 <[e-mail]> 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 [e-mail] 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 [e-mail] 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 [e-mail] with body "unsubscribe csound"