The main window has been redesigned. The engine input frame is a mutant widget that can accomodate different styles of input selection (in the picture we have orc/sco pair, all-in-one .csd file and orc/generator) as well as most kinds of orc/sco pre-processing. At the moment you switch from between the input frames using the +/- buttons (ugly!). Settings are saved separately for each frame. From the programmer's point of view, writing a pre-processing plug-in now means to write a new engine input frame class.
The option window is still the same. As general GUI design guide line, I'm trying to use few complex windows instead of 10's of little windows. Should I put this option notebook in the main window with a toggle button for hiding/showind it?
As side effect of the routing re-design, the logger window as been simplified. From the only menu available you can still start an external generator, assigning the logged engine as default route.
PythonCsound intepreter console window: what's PythonCsound? PythonCsound is the whole Python stuff plus a simple interface to a running Csound synthesis engine.
Using the csound object and its send() method you can send events to Csound from within the Python interpreter.
Sure there are lots of things to do for this intepreter but you can already type in multi-line Python commands in the lower text widget, using the usual Gtk+ editing keys and use CTRL+ENTER to submit the code to the interpreter. Using CTRL+UPARROW and CTRL+DOWNARROW you can move back and forth in the command history. Standard output goes to the upper text widget.
This used to be a part of the logger window but now it is just an external event generator. We have a text entry (with history) where you can type a line event to be played in real time.
From this window you can set routes for events coming from a given external generator.
Keyboard event generator: an utility event generator. Want to do some better graphic for this?
This is sensitive pad, a nice configurable event generator. From its configuration window, you can bind csound score events to the following events on the pad: mouse button (1,2 or 3) press, mouse button (1, 2 or 3) release, mouse motion, mouse motion with button (1, 2 or 3) pressed. The mouse coordinates are re-scaled in the specified intervals (see spin buttons) and can be used inside the event string (see '%(x)f' and '%(y)f'). Sooner or later I'll make it able to execute arbitrary Python code. Someone is working to insert multiple controls.
This is the OSC version of the sensitive pad. From the Python point of view, both score and OSC version of the sensitive pad are subclasses of SensitivePad0 abstract base class. I'm not very happy of the user interface but you can bind an arbitrary function of the (scaled and translated) mouse coordinates to any mouse event.
A typical OSC pannel with sliders and a slider configuration window. I'd like to embed the configuration window in the pannel window.
CSFE 4.0 will probably be named SoundGlue.
This is the result of using the build sliders by method options from the OSC menu on a OSC example by Stefan Kersten.