Some news from the hardcore work.
I made huge progress.
These are good news.
I was almost sure about my design so I decided to begin to code.
Here are some technical bits, as clear as possible.
Feel free to ask more if you want/need it.
The modular way
My first idea was to keep that huge system very modular in order to change it, alter it, improve it at my very own rhythm which means sometimes each day, sometimes not during 2 weeks.
In a lot of fields, decoupling things is a nice way to follow if you want to do it modular.
You can change a module, then replug the new one to the whole context without to have to rebuild everything each time.
Legacy desktop & company developers have to deal with HUGE studies before to begin even the first row of code.
At this very first step, they study all dependencies, the dependencies of dependencies etc.
Totally useful & boring especially the final purpose.
In my case, I did that til a particular limit beyond of what I wouldn’t have kept the pleasure of this project’s design
Don’t forget, I choose to take a road not to have a boring life.
The brain is a JAVA core
You knew that.
Even if JS in Max 6 is very fast because it uses a JIT compiler (Just In Time compiler) as specified by one of the developers there (end of the page), I’d prefer to be safer and use a compiled language.
A lot of boring debate about the speed of JAVA over JS and under C just bores me.
Using JAVA is quite fast and much more powerful & efficient considering the developement time & process than C.
Max contains a C SDK of course.
I read & write C without too much errors & warnings… but it would have slow the design step.
If I had very big issues with JAVA, I could translate the core to C. It wouldn’t be that hard but it wouldn’t be sure it would solve the problems.
BTW, no problems for the moment.
No charge tests made yet, of course, but the design is clean.
Then, the JAVA core is responsible of :
- all objects creation (read about object a bit later)
- references to all objects parameters
- the interface between the GUI and objects
- the interface between the system and the physical controllers (3D movements/rotations & sounds/visuals alterations)
- the way to store/retrieve all parameters inside a map ( a map is a set with all objects, all parameters set up for the show or for a particular purpose)
Basically, the JAVA Core is really the brain of this system.
At that point, I didn’t split it. Maybe I will do that.
In Max6, you can use more than one MXJ object instantiating
The nice schematic to read is this one:
It means I could split my Core into smaller pieces without too much difficulties
The Objects are the visible part
An objects is almost each time visual, and can be also sounding.
Each object as a kind of autonomous behaviour, driven at the beginning by the Core and some other entities like the master clock.
The modularity appears very strongly for objects.
Indeed, I want to have NO limits.
Using my way (I mean the whole architecture), I can design some special objects bits I would like to use only this time, or maybe always. I can design this particular glowing sphere linked to this type of sound and producing that vroroooooooouuuuroooooooshiiiiiiiiiiii when you are near from it.
Every can be integrated.
It is possible because the object interface with the system will be very light and everytime the same without constraining the system. Indeed, the fact the objects are autonomous is a good point in that design.
Each object has a visual representation in the 3D space. It means some are like pulsating entities, some others are proteiforms etc.
Each object can be a sound generator too.
Busses are necessary
Data busses are a nice way to keep information propagation a bit sorted & organized.
In Max6, this can be done by using that bunch of cords/cables, but we can also use pair receive/send objects.
Those latest are useful and works exactly like a cables, but without cable.
It can prevent the patcher to be messy too much.
In myUniverse, I’m using abstractions (=kind of patchers reusable easily and easily maintainable too)
Those abstractions fits with the global myUniverse interface and implement some receive, some send objects.
Like that, by creating some abstractions, they are automatically connected to the correct data busses.
This can also be done using cords, I mean, the fact they would be connected automatically, but it would kill the patch aesthetic which is totally important in order to keep pleasure & maintainability
The GUI will be cute
I’m currently hesitating about the GUI.
At first, why a GUI ?
myUniverse will be all about creating 3D maps.
Those maps could be programmed.
But the best idea is to use a GUI and that one will help to design my 3D maps.
I’ll use that 3D navigation feature even to compose my maps.
The GUI will provide buttons and list and sliders for objects creation/modification/remove/configuration.
It will be plugged to the JAVA Core in order to inform it of all modifications done, and the JAVA Core will inform all objects to move or whatever..
The GUI will have to provide a display too.
That display will be probably split in 2 displays in order to represent two views/projections of my 3D space.
This will be the place where I’ll put my objects.
It will have to handle the object selection. I select an object, I modify its properties.
I’d like to use an external program to do that.
It would be safer to use that and to plug it into the JAVA Core using OSC protocol, maybe.
This will be a nice way to cut things into pieces.
I think about Processing or OpenFrameworks for that.
OpenFrameworks is my preffered one today because I begin to know it a lot.
Indeed, I’m using it for all my iOS application stuff as a wrapper to iOS SDK.
A good point is also the fact it is easy to create new libraries for it and I’d be very happy to use the ofxUI by Reza.
To separate parts is a nice way to, in case of performances improvements, keep the room to use more than one computer.
In my head and in my notes, at this point, I’d have 3 parts running in 3 different programs:
- Brain + Visuals = JAVA/Max6/Jitter
- Sounds = Super Collider
- GUI = OpenFrameworks
Between them, the fastest & safe OSC protocol.
That’s all for today.
I hope you like my adventure ; the adventure is a project itself.
I hope to be able to show you a lot of things this week.
Popular Posts ( 30 days )
- The Max for Live Guide english version reviewed/edited by Mark Towers 885 views
- Disrupt!on 836 views
- Options.txt in Ableton Live 9 and secret features 671 views
- Max for Live Ultimate Zen Guide 661 views
- Ableton Live 9 Python remote scripts 631 views
- Ableton PUSH and VST 623 views
- Did you know the [bon]ome ? 416 views