initial commit

1 files changed, 68 insertions, 0 deletions

diff --git a/interfaces.h b/interfaces.h
new file mode 100644
index 0000000..0210ad8
--- /dev/null
+++ b/interfaces.h
@@ -0,0 +1,68 @@
+/*
+Native linux applicatioon with no graphic interface
+runs as a daemon and is managed remotely via socket etc
+
+debian - -any problems with proprietary codecs etc?
+
+is it called from ruby on rails?
+is the best way a RESTful interface?
+
+what's the best library to create a native server that implements http RESTful server
+??boost++??
+
+rendering- begins a thread
+eventually - manage threads and create new servers on EC2
+
+eventually - detailed memory management
+"rendering engine will probably be completely rewritten"
+
+the part that WON'T be rewritten is the meta-language that templates are written in
+
+renderGraph is a graph of loaded objects
+method to traverse graph, get preview image etc
+node knows where it sits on the canvas **here** - GUI doesn't keep its own state
+properties of a node - connections + time
+nodes are timeline based as well as flow- timeline is created when the song is analysed-
+
+node-time interface
+1- timeless node - applies equally to all frames
+2- node with in and out points - mainly for footage 
+3- node with absolute keyframes - added manually to relate to an actual song
+4- node with meta-keyframes - belonging to a template, these relate to instantiable music feature cues
+
+2 types of graphs - instanced and abstract
+
+
+*/
+
+class rotor_renderer() {
+	startRender(rotor_renderSettings *settings);
+	rotor_renderStatus getRenderStatus(rotor_threadID id);
+	rotor_renderProcess *activeRenders;
+};
+
+class rotor_renderSettings() {
+	vector<string> inputFiles;
+	rotor_renderGraphDescription graph;
+	string output;
+};
+
+class rotror_renderProcess() {
+};
+
+class rotor_managerInterface() {
+	TCPserver server;
+}
+
+class rotor_renderGraphManager() {
+	rotor_renderGraph renderGraph;
+	
+};
+
+class rotor_renderGraph() {
+};
+
+class rotor_renderNode() {
+};
+
+