caseybasichis
commented
11 years ago Hey hey, I was out at the Dentist getting four crowns... a royal p...
From your description you say "TTDictionary is not an object is not directly capable of such reflection without the use of other classes"
I am not that familiar with the TTDictionary, but in the case you describe wouldn't a Factory for creating TTDictionaries suffice as the type "TTDictionary" would always be the same and known in advance?
If all objects (except Dictionaries) inherit from TTObject and all input and output TTDictionaries, isn't that kind of behavior already possible?
I could have this totally confused. I am not familiar with the Max and Data side of Jamoma. If someone could point me to where these topics are documented I could dig into it more.
In regards to Haskell, what I was describing was more "inspired" by Haskell, not an attempt to interface the two directly.
This is probably a question for a dyed in the wool haskeller, but I imagine porting Jamoma there would be extremely difficult, requiring a total rewrite and redesign. The way C++ packages usually interface with it is through the Foreign Function Interface - a monadic C interface.
There are tools that automatically create FFI functions for all of the objects in a C++ library. They don't work perfectly but they can save a lot of work. That said, there is not guarantee of realtime behavior, My experience is that function calls seem to happen instantly, but they Haskell community is always warning about the realtime aspect.
I'm very interested in what you guys are up to with the TTDictionary redesign, I just need to get my head around it and the surrounding workflow as it would manifest in c++.
This relates to #123 (TTDictionary design)
Based on a conversation with @caseybasichis and other lingering doubts I've had on my own...
The last point above potentially offers a mechanism to begin addressing Casey's questions about reflection. In Jamoma all objects are capable of reflection and introspection, but TTDictionary is not an object is not directly capable of such reflection without the use of other classes.
For example, we may:
This is not exactly what SuperCollider does, but there is some resonance to this way of thinking. Which further suggests... We should also think of alternative graph representations beyond the Max-like graphical representation. For example SuperCollider and Haskell.
The reflection/introspection of dictionaries might be used in a Haskell-like (?) environment. If the type for the input/output of an object are the same then you know they can be connected -- you know the types because you ask the object/node. Only the input node is data to be processed - the rest of the nodes are processing output from the nodes feeding them.
Just to capture an additional (unrelated?) thought. I don't have a firm understanding of functional languages like Haskell -- but does the above imply that branching is not possible in such a graph? If so then it limits the problem domain significantly for this case... but we should be thinking about the other cases too...