« Return to Thread: The 'User-Friendly' Alternate Reality of Csound
Re: The 'User-Friendly' Alternate Reality of Csound
by Jacob Joaquin
::
Rate this Message:
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
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@gmail.com> 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"
« Return to Thread: The 'User-Friendly' Alternate Reality of Csound
| Free embeddable forum powered by Nabble | Forum Help |
