| Hello everyone,
I just posted a blog about my plans for Csoundo, but I want to repost
it here. More or less, I want to start collecting feedback early so I
can start incorporating the needs and wants of the community in
Csoundo. So if anyone has any suggestions, please let me know.
--------
The Future of Csoundo
Now that I’ve pushed Csoundo out the door, it’s time for me to take a
step back and look at where it’s at and where it’s going. As of this
moment, Csoundo is nothing more than the bare Csound essentials. It
can run a CSD, read and write to tables, generate score events, and
push/pull information via chn busses. Even with near minimum
functionality, so much is already possible, but that’s no reason to
stay content.
Over the last 3-4 weeks, I’ve been learning the Csound API while
trying to identify some of the big issues that need to be overcome in
order for Csound to be a viable platform for Processing. And even more
importantly, becoming intimately familiar with the Processing
philosophy. If Csoundo had a mission statement, it would go something
like this:
“Do everything the Processing way (or as close as possible)”
My vision for the design of Csoundo is that it will feel like
Processing when you use it. A simple example of something I can do to
achieve this goal is to study the naming conventions of Processing,
and apply what I learn to Csoundo’s methods. Little details like this
add up.
On the other side of the equation is Csound. I don’t want to hide that
it’s Csound under the hood, or pile on unnecessary constraints. I want
the full power of Csound to remain in the hands of users.
I’m going to post some notes I’ve made. They may not fully make sense,
but it’ll hopefully give you the sense of where this project is
heading.
* Support for 32 and 64 bit Csound, though only 32 bit support initially.
* Support for real time and non-real time Csound operations.
* Support synchronized and non-synchronized audio.
* Being able to defer redraw() to Csound. (optional)
* In instances in which more than one Csound kblock is performed per
Processing frame, have a method for collecting krate data into an
array that can be scanned by Processing. For examples, scanning an rms
signal for a peaked threshold value.
* Protect Csound data so that memory isn’t being read and written to
at the same time.
* Ensure that a Csound operation is completed before moving onto the next.
* Plays well with MIDI and OSC, including existing Processing
libraries themidibus, proMidi and oscP5.
* Set Csound command strings.
* Include pre-built synths and class interfaces for plug-n-play support.
* Get a list of f-tables in Csound’s memory.
* Proper documentation.
* Keep it simple.
--------
Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/
Slipmat - http://slipmat.noisepages.com/
Send bugs reports to the Sourceforge bug tracker
https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
|