Just some comments on the recent page "span 0.0.1 dev notes july 2013"
(my comments are in (xxx) :
import simple nodes and namespace mechanism into span
As the namespace has to be in span, the nodes concept must be inside span too.We can put the nodes and namespace function just after the project-management.
(currently in the maquette for tapemovie, nodes and namespace read/create happens after preferences, and then again after project load. -tm)
node declaration
The node declaration can handle instances and create the namespace using the quantity attributes. So node declaration and namespace building could be integrated into span.
(Yes! This would avoid some of the use of the span/inserts for loading tapemovie -tm)
Do we need a nodes dict?
Yes, because if we know that .nodes files are the real descriptor of the tree, we don't want to access all of them all the time. We just want to read once when you run the project for configurate it, and after all these files are added to the nodes dict. Because these descriptors files are on the hard drive, the loading of a lot od files could be a task we don't to do too many time. But the most important use of the dict is to describe the project, for example each nodes has a quantity attributes that describes how many time you use these functions.
(I don't understand the difference with what we have right now. "nodes" is already a dictionary because it is its own key in span dict. A central idea of span is that ALL the information that span needs is in span dict, so we shouldn't have a separate "dict" object for nodes. Another important reason to not have a separate dict is that node information could be stored in a project. In tapemovie, for example, certain node atributes are stored in a project like "quantity", "tags", "filename" and "description". These are saved to a project as defined by the "projectstructure", and I don't see why we should make a more complicated saving routine that looks for node information in a separate dict. As for reading the nodes too often, it seems to me that we only do this function at span creation and at project load. Since a project could change the way nodes are created, by pointing to a different modules path in tapemovie for example, the nodes key must be re-created at project load. We should review how this is currently working but I think we're close. -tm)
Do we need to save the nodes dict into the project
We want to save only the parts we change of the nodes dict. Because this is straightforward in the dev process to load. Add or/and replace node files on the hard drive and we want that it could be a process without having to clear nodes each time we want. So maybe this could be a developper preferences :
clearNodesWhenLoadingProject 0/1t's a developper preferences.
Because sometimes you want to rename some parameter, or use differents range for a same parameter in differents project but you don't want as many files as you have different use of the same parameter. So you will record only the "rules", for exemple a special range. The mechanism in nodes will not change the existing keys and values. This is the way we will use differents address.
(Again, since a project could potentially change the way nodes are created, I think it's normal that nodes be re-created at project load. The idea of projects is that they can make changes to the basic environment, so even though it makes for some redundancy, it is simpler and more flexible to make the nodes key at project load. -tm)
namespace dictionary
namespace instances methode
Add a quantity attributes will load multiples instance of this node. Node.1 or Node/1 Boths methods are OSC compliant. For me, it's difficult to change, because it's been a while (5 years) we're using the point version.
(Agreed. But I'm wondering if this isn't ONLY a question of how to access the namespace. Events can EASILY convert from and to the node.x method, and the setparam, getparam, sendparam functions of span.requests could also adapt to allow the node.x method. Structuring the namespace using node.x poses problems. Where do you put the attributes of "node"? Do you have a "node" key, and then node.x for the instances? Let's look into this, but I think that we could have a defined namespace structure, and accommodate other methods with span.requests and event editing. -tm)
UserLevel Preferences
I guess we should now introduce a userLevel tag for preferences, because we want to have different kind of preferences : Now, I think about 3 levels, but we could add more if possibles.
UserLevel 0 : it's preferences we want to see when asking for preferences. It's end-user preferences.
UserLevel 1 : it's preferences we want to see when developping an environment.
(Do you want to make userlevel tags for preferences keys? -tm)
Just some comments on the recent page "span 0.0.1 dev notes july 2013" (my comments are in (xxx) :
import simple nodes and namespace mechanism into span As the namespace has to be in span, the nodes concept must be inside span too.We can put the nodes and namespace function just after the project-management.
(currently in the maquette for tapemovie, nodes and namespace read/create happens after preferences, and then again after project load. -tm)
node declaration The node declaration can handle instances and create the namespace using the quantity attributes. So node declaration and namespace building could be integrated into span.
(Yes! This would avoid some of the use of the span/inserts for loading tapemovie -tm)
Do we need a nodes dict? Yes, because if we know that .nodes files are the real descriptor of the tree, we don't want to access all of them all the time. We just want to read once when you run the project for configurate it, and after all these files are added to the nodes dict. Because these descriptors files are on the hard drive, the loading of a lot od files could be a task we don't to do too many time. But the most important use of the dict is to describe the project, for example each nodes has a quantity attributes that describes how many time you use these functions.
(I don't understand the difference with what we have right now. "nodes" is already a dictionary because it is its own key in span dict. A central idea of span is that ALL the information that span needs is in span dict, so we shouldn't have a separate "dict" object for nodes. Another important reason to not have a separate dict is that node information could be stored in a project. In tapemovie, for example, certain node atributes are stored in a project like "quantity", "tags", "filename" and "description". These are saved to a project as defined by the "projectstructure", and I don't see why we should make a more complicated saving routine that looks for node information in a separate dict. As for reading the nodes too often, it seems to me that we only do this function at span creation and at project load. Since a project could change the way nodes are created, by pointing to a different modules path in tapemovie for example, the nodes key must be re-created at project load. We should review how this is currently working but I think we're close. -tm)
Do we need to save the nodes dict into the project We want to save only the parts we change of the nodes dict. Because this is straightforward in the dev process to load. Add or/and replace node files on the hard drive and we want that it could be a process without having to clear nodes each time we want. So maybe this could be a developper preferences :
clearNodesWhenLoadingProject 0/1t's a developper preferences.
Because sometimes you want to rename some parameter, or use differents range for a same parameter in differents project but you don't want as many files as you have different use of the same parameter. So you will record only the "rules", for exemple a special range. The mechanism in nodes will not change the existing keys and values. This is the way we will use differents address.
(Again, since a project could potentially change the way nodes are created, I think it's normal that nodes be re-created at project load. The idea of projects is that they can make changes to the basic environment, so even though it makes for some redundancy, it is simpler and more flexible to make the nodes key at project load. -tm)
namespace dictionary
namespace instances methode
Add a quantity attributes will load multiples instance of this node.
Node.1 or Node/1Boths methods are OSC compliant. For me, it's difficult to change, because it's been a while (5 years) we're using the point version.(Agreed. But I'm wondering if this isn't ONLY a question of how to access the namespace. Events can EASILY convert from and to the node.x method, and the setparam, getparam, sendparam functions of span.requests could also adapt to allow the node.x method. Structuring the namespace using node.x poses problems. Where do you put the attributes of "node"? Do you have a "node" key, and then node.x for the instances? Let's look into this, but I think that we could have a defined namespace structure, and accommodate other methods with span.requests and event editing. -tm)
UserLevel Preferences
I guess we should now introduce a userLevel tag for preferences, because we want to have different kind of preferences : Now, I think about 3 levels, but we could add more if possibles.
UserLevel 0 : it's preferences we want to see when asking for preferences. It's end-user preferences.
UserLevel 1 : it's preferences we want to see when developping an environment.
(Do you want to make userlevel tags for preferences keys? -tm)