OC Kernel 0.3 Works Great

Nicolas d'Alessandro — Tue, 17 Feb 2009 16:10:00 +0100

OpenCorn Kernel (ocKernel) 0.3.0 is now mainly re-developed.

Here are 3 really positive aspects of this version:

the kernel is now highly stable;
the CPU performances are outstanding: 15% of use with 16 slice/ola of really short frames (32 samples), see the screenshot;
the API is the most simple version ever, the slice and ola manipulations are acheived with 4 or 5 intuitive OpenCorn functions, such as "get a corn", "extract field from corn", "set value in the matrix", "send corns", etc.

Developers Meeting 1 - Doodle for March

Nicolas d'Alessandro — Wed, 11 Feb 2009 16:36:00 +0100

Here is the Doodle I setup in order to find a date in March for the first developer meeting of this version of OpenCorn: http://www.doodle.com/gy6vfv9ck67naqcc

OpenCorn 0.3 - Outlines

Nicolas d'Alessandro — Wed, 11 Feb 2009 11:41:00 +0000

Max or Pd stands as a really particular plateform where people from engineering and art are talking together, even indirectly. Indeed the fact that "objects" are written in C by some people (interested by learning it for getting advanced knowledges of the software and implementing or porting particular ideas) and then used by a larger community, probably interested by the result and in a more user-centered approach. But even considering advanced users, we see that Max or Pd object programming has been made quite simple by packaging the functions of these objets as a straightforward toolbox. Thus for the majority of Max/Pd objet contributors, it just consists in being aware of some specific concepts, related to these APIs and knowing where to embed their particular ideas as C functions. Only few people has a full computer science vision.

Thinking about extending Max or Pd (particularly with frame-based functions) is an interesting and even helpful challenge at a time where signal analysis and granulation are the tools for contemporary electroacoustic music. But we have to notice that there is no implementation of such a framework that is today interesting others than geeks.

Knowing this, we can highlight some points that would make a new attempt of such a extension more successful:

Max or Pd programmers would ideally not be too much disturbed by the extension, compared to their usual work. It means that the framework has to work as ponctual anchors in a usual Max/Pd C code and for sure not as a complete rebuilding of the sofware API, as FTM or Flext propose.
The focus has to be done on the few lines of C code that the Max/Pd developer wants to test on incoming frames. Indeed the thing that pushs somebody to go to programming is just related to the hacking of audio samples. Thus the time devoted to "context programming" (allocate memory, prepare audio buffers, remember reading positions, etc.) has to be minimal and really close to current Max/Pd context programming (defining ins/outs, arguments, etc).
Once more the functions that have to be learned by the user in order to modifiy the incoming audio samples have to be really intuitive and close of a high-level language, such as Matlab or even Max/Pd itself. For example, creating a whole section of C functions devoted to be used inside the code of the object and not related to the interface with frame-synchronous processing: compute FFTs, means, scaling, resampling, etc.
The performance and stability of such a framwork have to be comparable to Max or Pd itself and not giving the feeling that something extra has been plugged, creating odd connections with unstable and uncontrolable entities.

The question is what are the easy and current meeting points between the idea of a programmer and Max/Pd API:

The object structure with internal variables and a imposed header which "makes things working".
The idea of adding messages for which the object is aware, even for DSP.
The basic Max/Pd data format, as an "array of Atoms" (list of castable-on-the-fly datas).
The constructor (new) and the destructor (free) of the object, as to separate functions.
The DSP function, as a place for creating audio inputs and outputs.
The perform function as the place where the audio buffer is processing and pushed out.

The idea that we propose will be inserted smoothly into that body of habbits. It is called OpenCorn and based on these differnet aspects. We propose that "frames" (or more generally Corns) are one more type in the exsting Max/Pd API:

The basic capsule used to save and exchange informations is really close to an Atom (or even array of Atoms), but it accepts much more datatypes than what Max/Pd can do by default: audio grains, FFTs, etc.
All the initialization/free functions of OpenCorn are "sticking" the MSP procedure: just a few functions to add. For example, activating the OpenCorn interface in an object stands in a ocNewObject() function, that has to be added in the constructor, and the freeing procedures are in a ocFreeObject() function in the destructor.
The object scheduler of OpenCorn uses the MSP scheduler. It means that an object containing formatted datas is sychronised within an audio buffer cycle, with a relative value (in sample). The first implementation of OpenCorn would works sample-precision (= sync factor is an integer). Further versions of resynthesis object would support subsample-precision (= decimal sync factor) by applying a frame interpolation.
The OpenCorn "corns" (= synchronized data structures) are saved as extra allocated memory within the existing Max/Pd dynamic memory space. Thus a complex corn (e.g. an audio grain + FFT + pitch) corresponds to a simple address value (integer) and frames are passed by reference (no copies without explicit request -> frame cloning).
The addresses of the corns (actually summarizing them) are transfered with sample (or sub-sample) precision by stacking them and forcing a cast as t_float values (32 bits) inside the MSP audio buffer. OpenCorn objects thus use existing audio object ins/outs in order to exchange information. The only extra functions to be used by the programmer are primitives for packing/unpacking existing corns: ocAudioPack() and ocAudioUnpack().
The OpenCorn distribution would initially provides slicing (audio -> frames) and overlapping (frames -> audio) objects in order to help the programmer to make tests of their codes. The rest of the body of functions would progressively grow up thanks to the contribution of other users. It would defines a bipolar development community (the same as Pd) where the OpenCorn kernel is maintained by a small group of people and the API would be used by a larger community of hackers in order to disseminate OpenCorn usage in various contexts.

See you,
-Nicolas d'Alessandro

OpenCorn DevBlog

OC Kernel 0.3 Works Great

Developers Meeting 1 - Doodle for March

OpenCorn 0.3 - Outlines