Kernel word recovery crack, Mobile themes website for samsung wave 525, Dekha ek khwab sony tv title song, Song zombies on your lawn, Bloody mary nerve endings mp3, Digittrade tv jukebox, Padosan songs mp3, Gold cup series 70 manual, Nieuwste versie van mozilla firefox en, Cant install spotify on mac, Web brute force password cracker, Belkin g peek driver windows 7

Jam Fabric (Working title)

January 12th, 2012 by Martijn Leave a reply »

I’ve been influenced a lot by the [puredata][pd] and [vvvv][vvvv] visual environments during the last years, and to a lesser extent by [SuperCollider][sc] and [ChucK][chuck], and now I’m starting work on my own take at a realtime multimedia performance framework. The focus is on collaborative distributed patching. Of course, there is a _scratch my own itch_ and _not invented here (NIH)_ component to this, and some may argue that I should contribute to any of the aforementionned projets instead, but it is my ambition to write something fresh and new from the ground up, starting with the experience gathered in similar projects. The goal here is to create a robust and well-defined platform, that is (relatively) easy to learn and to use, and that combines traditional imperative programming constructs with puredata style message passing.

I’m aiming for a few objectives:

– Modular hardware/library agnostic approach: JF will not be tied to any audio or video library in particular, but is extensible by “engine” plugins. This makes portablility that much easier.
– A well-defined API bridges client code and the processing engine, processing happens in its own memory space. This makes it possible to develop different client types, and provides maximum stability for live performances.
– Graphical programming of patches through a patcher-style user interface. The graphical client may run remotely.
– Programmatic programming of patches and processing objects, either through C++ or Javascript. It should be easy and fun to create new objects, with a minimum amount of setup code required.
– Multi-user collaborative editing and performances.
– Lightweight core: the engine must run on cheap low-performance hardware. A graphical client can connect remotely.
– A standard library of control, math, audio, video, openGL objects. The control objects must cover the same functionality as a modern scripting language does out of the box.
– Typed/Structured ports and connections with automatic conversion. Less wires and in the case of graphical patching, and generally less opportunities for errors. The automatic type conversion make interoperability easier.
– Coherent tree-based naming of objects and object definitions, combining concepts from DOM-trees and [Perl][perl][^1] modules.
– Self-contained documentation: the framework encourages developers of new objects to add documention strings. The graphical front-end uses this information as tooltips. Objects can be searched by name, tag or description. All this to make learning the environment easier.
– Test based development.

I’m using the [Qt][qt] toolkit as it supports much of the basic functionality (UI, network, XML, data structures) that I require, it is portable, and because in my opinion it is beautifully written.

I’ll try to detail each of these points in my next posts.

[^1]: You read this right. Perl. Perl can be as ugly as you want, but its module system and namespaces work great in practice. Just see [CPAN][cpan] !



Leave a Reply

Authorized tags:
[b]bold[/b] [u]underline[/u] [i]italic[/i] [url=http://link.url]link[/url] more