didascalie-net / span

Spaces And Nodes - Environnement for real time media controls and organisation
didascalie-net.github.com/span
3 stars 0 forks source link

span own namespace #33

Closed reno- closed 11 years ago

reno- commented 12 years ago

We have to think about span own namespace. I mean how to describe it thru a namespace (or node) declaration. But I think this could be wait a bit that we're finishing span 0.0.1

Aside, I want to talk about /span/load message and /span/load/done. What I did in the patch of span was a unique /span/load parameter. It's really easier to make OSC User-Interface with a unique parameter, that could be assign for exemple to a toggle on TouchOSC. The darkside of that behavior is that a parameter is a controller too (if we want to make a mapping to/from span parameters/controllers). But I think this is not a problem, because we will be able to filter what we want to see in mapping menus… and it's more a UI problem…

So I really prefer to have a unique /span/load parameter, with of course a simple mechanism that prevents problems…

tmays commented 12 years ago

Sorry, I asked you about this in another issue (issue #37).

I'm not sure I understand, but there's a problem that /span/load works as a parameter to trigger the load, and also as an indicator that it is done - especially when the "done" automatically triggers the project merge in the case that autoload is 1. Also, since the "0" triggers the project merge, /span/load is not actually done, so that could be the cause for synchronisation errors with an osc client...

I understand that you prefer the "ease of use" with a unique paramter, but it is really weird and confusing to have a "parameter" that you send a "1" and you expect a "0" in return. We solved this problem in tapemovie with the "loading" controller that indicated what the load state was. I would much rather have a /span/load 1 (or bang) that triggers the load, and as soon as the load starts it sends /span/load/working 1, puis /span/load/working 0 when it's done. That gives you a unique parameter for your osc interface display, to know when the load is done, and also avoids confusion with parameters that double as indicators - and then having to make little bits of patch like "p onebang" that are a little bit "unfortunate".

Could you agree to this? It's a good compromise, I think. You still get a unique parameter for display, and I get a programming style that I like...

reno- commented 12 years ago

of course I agree…