- 1 JAVA Core knowing (almost) all.
- a bunch of objects
those visuals objects are autonomous. they are jitter based + some features like an integrated very small sequencer etc.
the sound engine is outside, and talk OSC.
I’m hesitating about the messaging system.
currently, each modification of object comes from the CORE. (I attached a light GUI sending message to the core which inform the objects)
Each object has one receive object "plugged" to the broadcast object bus in which a master tempo fire a bang.
Objects have to react to a bang by sending a message to the sound engine.
Question (at last)
should I make the object sending message directly, storing things in the CORE & a bit less but also in the object ?
should I make the object sending message to the CORE, and the CORE sending to the external ??
The idea is:
- first case, I’m storing a bit more in object but fire directly
- second case, I’m storing almost nothing in object but fire the core which fires the sound engine
Hey J. I’d definitely go route 1 and decouple the objects from the core as much as possible. If I have understood you correctly then this is much more expandable and scalable, you don’t want the core to become a bottleneck for all the processing of the other objects. Give the object enough state so they can do what they need to do – if this means some pieces of data are duplicated many times in each instance rather than stored once in the core then that’s fine
indeed, the core, if it has to know almost all for store/load preset, to communicate with my little GUI (basically an object editor), to propagate data from the GUI to objects, MUST NOT be the bottleneck at playing time.
I’ll do that: objects will know enough to be able to fire OSC messages by themselves :)
Intuitively, it seems safer.