templates - and span_settings location

Their location is defined in the patch, relative to span.maxpat. We thought about moving it to this path :

~/Library/Application Support/span/span_settings.json

And we will put the templates path as a preferences in span_settings… Maybe span_settings could be span_preferences??

Maybe we could move it later, when span will be more ready… it will be easier for development

Yesterday we made the span.load.json file, in order to load default-project-settings-info… It's really a nice enhancement, but we keep some users paths that could be changed. So it's not nice.

If we want to follow the appstore guidelines, the only approved locations for editing files from an application are :

~/Library/Application Support/ ~/Library/ ~/Library/Caches/

So maybe we could put a span.load.user in "~/Library/Application Support/" where we could add lines? It could be empty, or we could add settings-path, preference path and project-path? Or add some dict to merge with span.dict or both?

for your actual commit Tom, it could be like that

{ "settings" : { "file" : "here:/there/projects1/Environ ments/didascalie-net/tapemovie2/tm.settings.json" } , "preferences" : { "file" : "here:/there/projects1/Environ ments/didascalie-net/tapemovie2/tm.preferences.json" } , "project" : { "file" : "here:/there/projects1/Environ ments/didascalie-net/tapemovie2/tm.project.json" } }

I don't think span.load has any place in the ~/library/ As I understood span-load, it is specific to an "environment" - spannoyau.app, or tapemovie. There is nothing about that that a normal user would change.

The problem is just within the development team, since we're using the span repo to work on different environments, and each one is going to require a differences in the span.load.json.

Unfortunately, I think we need one more level of span.load. The current span.load should contain nothing but a reference to another json that could be span.load.reno and span.load.tom, or whatever. This would allow us to commit our span.loads and to see each other's span.loads to learn from what they're doing. All we would have to do is .gitignore the basic span.load.json.

All we have to do is put in a key "redirect" to an alternate file into the span.load. When we customize and environment to actually put it to use, we can easily put the contents of our span.load.perso into span.load.json.

I don't want to start using separate branches because I want us to see what the other is doing. I think it would be nice for you to have a dev folder in span too, so that our experiments and developments are transparent. Someday, when this is as big as jamoma, we can re-organize, but "au point où on est" I think we can offer ourselves a certain "confort"...

What do you think?

I don't like some span.load.perso other redirect.

What I suggest is to :

remove file keys from span.load.json
keep span.load.json in the same folder as span.maxpat and nobody edit it. it's only keys that span needs to work. I really don't like that span.load could be change. It hasn't to be.

What I suggest is really simply and I think easier.

span.load is the loading of default-values for field that needs values because these will be ask by span to work normally.
To make customisation for tapemovie default-project, when /span/load/done you will set some values in span dict. You do it from your patch, with some simple requests. setvalue settings::info::name tapemovie etc… You will declare some paths, ./media, ./events etc…
span main dict is the default-project, (without system sub-dict) We will be able later to choose what to include or exclude. And with the consolidate-to-a-folder option, all the paths declared in the paths dict are create, so a new tapemovie project is born with all these folders in a relative ways.
If we want to load a settings file from tapemovie, just load it and send it to span.requests when /span/load/done bangs. But it's done in tapemovie and it's over. We could not set a settings path in span for tapemovie/otherApp. It needs to be relative to tapemovie. Maybe we don't need any settings file, they could be load in the patch itself.

About preferences files, I really think that its place is in ~/Library/Application Support/span/span.preferences.json

And for project files, recent-projects are stored in the prefernces files, and the current one has its own path because you open it.

I hope to be as clear as possible

I think there is a slight difference in philosophy that we need to work out, as it relates to the vision of "what is span". I thought it was clear that span is NOT an application, but a database that defines a namespace, that can read and write values to this namespace, that opens the database up to network access for OSC sending and receiving and that can perform basic functions of event managing and mapping. It's in some ways a "protocol" but essentially it's a development environment with which to make applications (patches) that use these capabilities and thus maintain compatibility and interoperability. Since it is NOT an application, it should not write its own preferences file to ~/Library/Application Support/span/, but it SHOULD be able to write a preferences file in the name of the application/patch that is build with it.

We've talked a lot about the example of Wordpress. Wordpress is basically access to a database. It isn't it's own application, as the real application is php, but it allows one to build a website, which could be looked at as an application. Wordpress is not a motor that you communicate with from the outside. It is a system of database access that you adapt to the way you want to build your website, but your website is an integral part of wordpress.

when you say: "To make customisation for tapemovie default-project, when /span/load/done you will set some values in span dict. You do it from your patch, with some simple requests. setvalue settings::info::name tapemovie etc… You will declare some paths, ./media, ./events etc…"

...for me, span's potential is reduced. I want to be able to "make span become tapemovie" and not to "make tapemovie as a span client". Again, for me span is not an application but a "core" around which to build an application. I want the span protocol to be so robust that I can incorporate tapemovie's protocol within it. Having a customizable span-settings file was key to this. I think there is nothing wrong with having a span-load that creates the essential keys for span, but that it can call another file that adds other fields (a tm.settings instead of a span.settings). I was very pleased with the arrangement that we had yesterday where we clarified that the "settings" are what differentiates the applications built with span. Now this seems to be in question because this has to be done separately. I would have to create my own patch to merge the contents of the database, when it is so easy to just build into span the ability to merge an alternate settings file...

The beauty of span (and I think that span is "beautiful") is that you can do so much to configure the environment without having to do a bunch of patching...

There's something else that I don't understand. You keep talking about consolidating files as a basic function of span, but why does span need to point to files if it contains no modules that could work with those files? What files are you going to consolidate if you don't have any modules to load those files into? What are the files that you are referring to?

Or maybe span SHOULD know that there could be media files and modules. That these things be built into its protocol, without the obligation to use them. If these tags exist, they wouldn't have to be "re-invented" and "re-named" by each person building an app with span...

you say: "We could not set a settings path in span for tapemovie/otherApp. It needs to be relative to tapemovie. Maybe we don't need any settings file, they could be load in the patch itself."

Again, for me span would be "included" in the tapemovie-lib, so relative to span IS relative to tapemovie. Also I think we DO need settings, as we discussed yesterday, if span is going to have the minimal functions of event managing and mapping.

I think this work that we are doing is VERY important, and we just need to get the basic philosophy alligned. I think we're close, but I often feel like we take steps backwards... :)

-t

Since it is NOT an application, it should not write its own preferences file to ~/Library/Application Support/span/, but it SHOULD be able to write a preferences file in the name of the application/patch that is build with it.

With your exemple, if you use span with a patch or as an app you loose your preferences. I don't think this is the solution. Span is span, it has its own preferences, and tapemovie is tapemovie and has its own preferences too. As all libraries or dependancies. We don't have to make span become anything. span is span, and I really want to be able to make simple projects with a projectfile and a simple patch with a span inside and nothing more than this. Without running an app, simply running the patch in max. I don't think that span is modules-related or patches-related. It could be use to run osc events for osc apps, make some osc mapping from input to output.

When I'm talking about files that needs to be consolidate, I speak about media files, or event files, or any file we want to use in our project. We can consider that a project will use some of the shared cues, that needs to be copy into a folder for a consolidation.

I don't see span only as a max patch, but maybe as a daemon?

About the settings file, I agree with you, we need to be able to ask for a specific settings file, but if yes it's related to a project, so we would have a "settings-file" key store in the project?

Have you read the setup I describe (with settings in a file and not in the patch :-/).

Si nous reculons c'est pour mieux sauter !!

So please no "redirection". I don't like this way to make a file and other reference file etc… You could not ask span to know tapemovie identity. tapemovie must declare its settings. This is how to use another app. And i don't want to put my span folder in tapemovie folder as you want to do. for other apps it could be really different (OSC apps)

span loads "span.load.json" - This file must not be changed
tapemovie declares its settings. Just a simple "settings-file" key in span.dict and this file (tapemovie.settings) is load by the same simple mechanism that for span.load, simply merge the key of this file to the existing keys of span main dict (add before by span.load) and it's ok.

A simple path message to a this patcher object with a [sprintf %stapemovie.settings.json] send to a span.requests will do the job !!!! It could be the right way to declare custom settings for app.

I think I'm ready to talk with you about that, we're close to the goal!! It's really clear for me.

For preferences files, it will be easier to keep it in the project and be able to copy preferences from a project to another. It could be the most confortable.

I don't know if we actually disagree on certain points, or if we just don't understand what the other is saying... :)

Basically, the ideas I'm trying to defend will not in any way keep you from using span in the way that you want to, but they will allow me to use it the way I want to.

I'll try and go point by point.

"With your exemple, if you use span with a patch or as an app you loose your preferences. I don't think this is the solution. Span is span, it has its own preferences, and tapemovie is tapemovie and has its own preferences too. As all libraries or dependancies."

Why would you lose your preferences? I'm just saying that if you use span to make an app, you can simply add to the normal span preferences with additional keys and save them only once. I say the normal place to save the preferences would be in the span folder, but if somebody wants, they can change the preferences location to use ~/Library/Application Support/span/ if they want for their application. They could also choose to change its name and include custom keys. One advantage of having the span "brain" and the app use the same database is that you can have a common preference file. It would really be unfortunate to have to have separate preferences.

I see span as a set of functions that COULD be self-sufficient, but COULD ALSO be the basis for an application. It is fine if span can be an application, but I do not want that behavior to be REQUIRED. I want to use the span database, project and namespace functions to build an app. I want ONE preferences file and a simple way of establishing the settings. I'll get back to the settings later...

"We don't have to make span become anything. span is span,"

Exactly, "we don't have to make span become anything", but we can make span become something if we want. I want to merge the span functions with the other functions of my app, while respecting the span protocol.

"and I really want to be able to make simple projects with a projectfile and a simple patch with a span inside and nothing more than this. Without running an app, simply running the patch in max."

Absolutely nothing that I have suggested would keep you from doing this. I'm talking about MORE flexibility, and not less. We should be able to "stick span in a patch" and ALSO build a complex app around span. One does not have to impede the other.

"I don't think that span is modules-related or patches-related. It could be use to run osc events for osc apps, make some osc mapping from input to output."

Again, nothing I have suggested would keep that from happening. I still think, however, that we could define a module tag the could be used by someone who wanted to load a patch as a node. I don't see why this is a problem. Span is a namespace manager, and a namespace node is EITHER a network defined "virtual" node or it is a patch "module". There aren't 3000 solutions. I really don't think that it's anymore than defining the node tags "osc" or "module". Really no big deal.

"When I'm talking about files that needs to be consolidate, I speak about media files, or event files, or any file we want to use in our project. We can consider that a project will use some of the shared cues, that needs to be copy into a folder for a consolidation."

I still don't see why you need a consolidate function if all you have is events files. span, as you define it, can never contain media files because it does not build patches or modules. I think project consolidation would be the job of another app (tapemovie). It is very confusing that you don't want modules, but you want media file consolidation... We haven't talked recently about "events" but the logical json solution would be to do something like what Théo did with a single file. The events could even be in the project file! This means that span could use ONLY a load file and a project file. If we save the project file location, an app built with span can easily use that location to define folders found next to the project file - in the case where the app needs project sub-folders, as does tapemovie. So, I'm saying that consolidation should be an APP-based function and NOT a basic span function.

"I don't see span only as a max patch, but maybe as a daemon?" I want to use span as a protocol and a database building block, and NOT as a daemon. However, if you want to find a programmer to write span as a daemon, I am not against that, but I will NOT try and write tapemovie to use with a span daemon. I will use the patch version, because that is the programming language that I want to use.

There is NO reason why span can't be a sort of daemon AND a building block for an app. It's ONLY a question of configurability, and clarifying where span leaves off and the app takes over.

"About the settings file, I agree with you, we need to be able to ask for a specific settings file, but if yes it's related to a project, so we would have a "settings-file" key store in the project?"

I don't think a project should change the basic settings info, but if it includes those keys, it CAN. I think that basic idea is that if we open a json that contains span keys, we merge with those span keys. This seems like a generalized concept that should allow lots of different ways of working with span.

"So please no "redirection". I don't like this way to make a file and other reference file etc…"

This kind of logic of configuration files referenced by other files is very common, and I don't understand what is not to "like". I think "redirection" is an excellent super-user type of solution, that would simply not have to be diffused to the general public. It doesn't hurt anybody or hinder ANY of the things that you want to do. Being able to "redirect" to an alternate span-load makes it very easy, on the other hand, to integrate span into a higher-level app. This is VERY powerful. It means that you can make an app that adheres to and benefits from ALL of the functions of span, but you don't have to program like you're a client to a daemon. span and tapemovie would be one. the "official" release of stable versions of span would not show the "redirect" function in any way. span.load would be untouched and pristine as you want it to be. tapemovie, however, would use an alternate span-load that would take care of its needs in one shot, without having to load settings twice (once by span and a second time by tapemovie - elegance and efficiency.

In conclusion, I would like to keep the "redirect" as a "hidden" function, at least through this early development period.

I can try and implement your idea of waiting until after the span loading is done to load and dump a tapemovie-load.json too, even though is strikes me as inefficient...

"2. tapemovie declares its settings. Just a simple "settings-file" key in span.dict and this file (tapemovie.settings) is load by the same simple mechanism that for span.load, simply merge the key of this file to the existing keys of span main dict (add before by span.load) and it's ok."

That makes for one extra file, even though we are trying to reduce file numbers. As I mentioned above, I will try, though I find this "dommage"...

"A simple path message to a this patcher object with a [sprintf %stapemovie.settings.json] send to a span.requests will do the job !!!! It could be the right way to declare custom settings for app."

The point is a basic vision about span. for you it is like an app or a daemon that must be left alone, and for me it it is the database "core" of an application, whos protocol is respected, but that can be "personalized" as one would a wp theme. I think that BOTH visions should be respected, and possible. there is no reason why they can't be. Don't make me modify the span.load file in secret! ;)

"For preferences files, it will be easier to keep it in the project and be able to copy preferences from a project to another. It could be the most confortable."

As I explained a couple of days ago, I think there should be a basic set of preferences keys, that "could" be saved to a project if one desired. Or that you could choose to NOT read from a project.

I think we really need to talk, because I don't want redirection, i found this idea really cheap. So I will continue patching after today (I'm on shooting today) and I will implement what I'm talking too. So if you want to continue , we wil do two span branches (or folder ;-)). That's more than one month I'm working hard on it and I really don't like to have more than one file in span. The span.load file is a really nice and big improvement. All we need now is just to declare a settings file for an app and a project file for a project. We did this concept, and it's massive !!! I don't want a redirection and another load file than the span.load file. We can talk tonight, or tomorrow or later.

My vision is not as basic as you said, and I used to have to convince you since the beginning of the span-project

My vision is not as basic as you said, and I used to have to convince you since the beginning of the span-project

I never said your vision was basic! I said "The point is a basic vision about span." which means "the point (that we have to resolve) is (what our) basic vision (is) about span, not that "you have a vision of span that is basic". And I don't know what you mean by convincing. We have both been convinced for three years since the discussions about the "noyau". :) And I too have spent a HUGE number of hours on this project. That has nothing to do with coming to an agreement.

I do not want to work on a separate branch. I find that solution very unfortunate for a project with only two people.

As for redirection, it is in no way cheap, but I'm tired of trying to convince you. I will personally remove the redirection from span, and switch to the method of tm-load when span-load has finished. Ok.

Since you didn't have time to respond to the other points I made, I will go over the most important ones here.

1) span preferences I do not think that span should write preferences to any place other than the span folder by default. span as it stands today is not an application and therefore should not write its preferences to the system. You can make any patch or application you want and change the "settings" for the preferences path to write in app support if you want. Since the default preferences key is defined in span.load, there is no need to release a preferences file with span, and we can .gitignore our copies.

The problem is that the preferences file would have to be created on load, which is what happens with any normal application. Since we are not allowed to customize span-load, this means that the preferences file would already be created in app support before getting a chance to modify the settings with tm.load - changing its name and location. Not very elegant, as it clutters the system. Creating a preferences file in the span folder is less of a problem - and more platform independent. I really want tapemovie to run in windows, for example.

On the other hand, if we had the possibility to customize span.load, this wouldn't be a problem... ;) You could make it save to app support, and I could make it save to somewhere else...

2) projects I still think that a project should merge its contents with the span keys, but also be saved in the "project" key "as is". This is what structures the project, and it vastly simplifies the question of what keys to include in a project. You simply load the template for a project that you want, and that is the basis for what will be saved when you save the project - updating itself with the span keys. If somebody wants to, in their app, let the user choose what keys they save to a project, nothing would stop them from doing that, but I don't think we need to have this function directly in span.

The paths that a project defines will create the folders it needs within the folder that it is in. In this way, it is up to the user to organize his projects, deciding whether to create a folder to put a new project in, or just save a project.json in a folder with other projects, thus sharing files. We could then have two options for saving projects - "save project" and "save project with files" (consolidate). That function would very simply take any paths that are NOT relative to the project, create a project folder, and save them to it.

So, this is an evolution of what I was saying before. Consolidate, or "save project with files" could, in this general way that I describe, be implemented in span, without needing to know what kind of files they are.

That said, I don't know off hand what object could do that. shell commands?

So, to summarize, the idea is that we can make templates of project files with whatever span keys and sub keys we want. When a project is loaded, it merges or creates the keys in span. When we save a project, it gets the same keys and subkeys that it copied earlier, thus respecting the structure of the template.

When we want to "save project with files" a) it looks at its paths to see if there are any folders, if so, it creates these folders within the same folder as the project. b) it copies the contents of these folders, with their subfolders, into the new folders c) it looks at whatever paths are files d) it creates a "files" folder in the project folder e) it copies all of the files into the new "files" folder

So, a project template could contain any settings keys or preferences keys we want. That would also be very cool where tapemovie is concerned.

3) events We need to talk about the event structure and the event sequencer. We could have a basic event structure that goes into a span key "events" and is saved into project::events. This would be a obviously a json format. An event would have tags that could specify if it is a "key"event or an "intermediary" event. There could be a sequence key that lists the order of events in a sequence. Since events is a root part of span, this same system would be used by all apps that use span, although nothing would stop someone from inventing their own event format and saving it under another key...

We are close! :)

I've started new issues with points 1, 2 and 3...

I've started new issues with points 1, 2 and 3...

So i think I can close this issue

didascalie-net / span

templates - and span_settings location #14