search

Vidvox / OSCQueryProposal

Draft of a proposal for an OSC Query Protocol
121 stars 12 forks source link

General Comments #17

Open bltzr opened 10 years ago

bltzr commented 10 years ago

Thanks Ray for revamping the proposal, my impression is that this new brew is much more adapted to the purpose, and I also think it's good to split the query part from the plain OSC communication. Besides, I thought it would be good to have a section for "general comments"... :-)

lov commented 10 years ago

Yes, I also find the switching from OSC to a HTTP service is a very good idea, so, thanks Ray!

But I think, since the new proposal intend to create a service over the web architecture, why not use a web service for that? There are a couple of already implemented web services, we may find something which is already ready to use? I must admit I don't have too much experience with web services, but I know that exists :)

http://en.wikipedia.org/wiki/Web_service

JSON-RPC seems very close to what we need for example: http://en.wikipedia.org/wiki/JSON-RPC

theod commented 10 years ago

Congratulation for this new proposition @mrRay ! Even if I'm not really aware about the web service @lov mentions, I'm wondering to know if WebSocket is one of them ? because someone who work with us have done a WebSocket protocol plugin to describe the architecture of a Jamoma application (and also control it over a none local network). The format used to exchange the architecture is also JSON (but not JSON-RPC). I've sent him the link to this discussion in case he have any input.

lov commented 10 years ago

@theod WebSocket seems a bit different: http://en.wikipedia.org/wiki/WebSocket

theod commented 10 years ago

thanks for the input @lov. so I guess what we can share with @laugre (the guy who worked on the WebSocket stuff) is more about the JSON format.

laugre commented 10 years ago

Hi there thx @theod for linking me to this thread ! I think the final goal is quite similar to your @mrRay.

To explain a bit more I developed WebSocket Jamoma plugin to explore, get, set and control parameters of an application (based on Jamoma framework) from a remote web browser interface, a kind of web télécommande (which could be run on any web browser on any platform). @lov WebSocket is not very different from HTTP, it is pretty adapted to this kind of communications, it let bidirectional exchange on the same connection, multi-clients management ; to implement my WebSocket plugin I used civetweb (https://github.com/sunsetbrew/civetweb).

Concerning JSON, I chose to exchange datas using this format because Jamoma Modular tends to use it internally in the future and maybe that will be able to facilitate and optimize communications. Let me show you the specs : syntaxe_json

That syntax proposition differ a bit with your @mrRay, and I need to build my json request, convert it to a string and send it to the server using a WebSocket client. There are some tips not described in these specs for example you can

bltzr commented 10 years ago

just a small comment in order to ease comprehension : "télécommande" is the French for remote-controller

mrRay commented 10 years ago

hey everybody, thanks a bunch for your suggestions (and @laugre, thanks for sharing your experience)- i think WebSockets would probably be a great way for the server to notify clients that its address space has updated, an area of my proposal that was definitely vague and in needing of improvement. i don't think we need to use them for vending the data blobs describing the address space (i don't see anything that would be gained by doing this), but they look like a really good, easy-to-access and generic way to implement the connection for push notifications of server address space changes.

likewise we could certainly use JSON-RPC to format the notifications being sent over WebSockets- i'll get these suggestions added to the proposal in the next day or two!

bltzr commented 10 years ago

@tuscland what do you think about this all ?

bltzr commented 9 years ago

hey everybody - discussions haven't been very active here , these times... are there any pending issues that keep us from actually trying to develop implementations of the system ? If not, what about starting some time soon ?

mrRay commented 9 years ago

i can't speak for anyone else, but right now i'm too busy with other projects to write code for this one- and as much as i'd like it to, i don't see that changing in the immediate future. none of the other projects i'm working on right now have reached their natural terminus yet; i'm still working on them every day, and i don't want to start a new project until i've got enough time in my schedule to reasonably expect to finish it.

@bltzr, if you want to get started, don't let me stop you. discussing a spec, doing reading/research, and basic administrative tasks for the repos i can squeeze into nights and weekends, but that's not the same as writing and testing software. i'm not absent, and i still look forward to building an implementation of this protocol, as well as software that uses that implementation to communicate with other devices. i just....don't have time to responsibly start building that software today :(

jdkoftinoff commented 9 years ago

Hi! I just stumbled on this repository and want to chime in. I use OSC with high channel count devices. An example of an OSC address on one device could be: 

/input/50/eq/10/frequency ,f 1000.0

i.e. there are 72 inputs, each with 10 eq's, and each eq has frequency, gain, and Q parameters. So there is a lot of duplication here of the meta data.

As far as I can tell with your current proposal, representing this schema would require 2160 JSON objects, when really there are only 4 different variants being used.

Perhaps there could be a mechanism split the definition of an OSC address from the meta data for that kind of OSC address, and allow numeric ranges in the OSC address?

mrRay commented 9 years ago

yes, sometimes the JSON blobs generated by this protocol are going to be large; i've been assuming from the beginning that tens of thousands of addresses wouldn't be terribly unusual for medium-to-large applications. did you have a specific concern about this?

Perhaps there could be a mechanism split the definition of an OSC address from the meta data for that kind of OSC address, and allow numeric ranges in the OSC address?

did you have a specific implementation or any ideas in mind that you could share with us? some concrete examples demonstrating the approach you're envisioning would be very helpful to this discussion!

jdkoftinoff commented 9 years ago

Yes, I have a specific concern about this; At Meyer Sound we use OSC for exposing control points on some products; some products of which have more than 600 filters, some with more than twice that. All of these are in orthogonal arrays. None of these devices have a service/address discovery mechanism.

Work was done by Andrew Eales from the Wellington Institute of Technology - He presented it at AES 2012 conference: http://www.aes.org/events/133/presenters/?ID=218 and see http://www.aes.org/events/133/papers/?ID=3175 and http://www.aes.org/e-lib/browse.cfm?elib=16432

He defines a complete system using OSC for the querying of the entire address space and meta data for an OSC device.

I also had published a document in 2010 shows a mechanism for introspection of the OSC schema, available at http://grouper.ieee.org/groups/1722/1/contributions/2010/1722.1-koftinoff-AVBC-2010-04-16-v3.pdf - See Clause 5.1.

The problem with the mechanism defined in the AVBC proposal was that I did not define that the response to a query for meta information of an address could contain an address with wildcards in it. For instance, it would have been nicer to allow a request for 

    "/osc/limits/input/1/filter/1/gain"

to return: 

    "/osc/limits/input/*/filter/*/gain" ",sssfsfsfss", "type", "f", "min", -30.0, "max", 30.0, "inc", 0.1, "units", "dB"

Which would means that the gains for all the filters for all the inputs in the addresses:

   "/input/*/filter/*/gain"

Takes a float value with a min of -30 dB, max of 30 dB and a recommended increment of 0.1 dB

bltzr commented 9 years ago

Hi !

We have been addressing this problem in the jamoma project by extending the OSC syntax with the concept of instance - the separator for it being the dot (which is OSC-compliant)

the example you mention,

/osc/limits/input/1/filter/1/gain

would be then expressed

/osc/limits/input.1/filter.1/gain

the benefits of such a thing are several :

I don’t know if this might be useful to the protocol, but I thought it worth mentioning…

mrRay commented 9 years ago

“Yes, I have a specific concern about this; At Meyer Sound we use OSC for exposing control points on some products; some products of which have more than 600 filters, some with more than twice that. All of these are in orthogonal arrays. None of these devices have a service/address discovery mechanism.”

pardon me if i’m being dense, but what is that specific concern, exactly? if none of the devices you just mentioned have a service/address discovery mechanism then what role do they play in your concern? can i ask for another hint?

if i seem unconcerned by the prospect of a JSON blob describing an address space with several thousand methods it’s because the main use i see for this system would involve using it with an address space with somewhere between “thousands” and “tens of thousands” of methods (depending on the user-specified setup), and most of those methods aren’t identical and aren’t split up into nice, neat numerically-indexed arrays (the address space roughly reflects the organization of the app, so there are a lot of user-named directories and the whole address space runs pretty deep).

“Work was done by Andrew Eales from the Wellington Institute of Technology - He presented it at AES 2012 conference:”

did he post it anywhere else, or is it only behind a paywall?

I also had published a document in 2010 shows a mechanism for introspection of the OSC schema, available at http://grouper.ieee.org/groups/1722/1/contributions/2010/1722.1-koftinoff-AVBC-2010-04-16-v3.pdf

reading it now, thanks!

“The problem with the mechanism defined in the AVBC proposal was that I did not define that the response to a query for meta information of an address could contain an address with wildcards in it.” (emphasis mine)

this is very clever, and it does a great job of reducing the amount of data you have to send for the example you provided. as for applying this approach to the current proposal…right now, the JSON blob describing the properties of the address space also serves to enumerate the address space, and we can’t use wildcards to accomplish this. the proposal could certainly be altered to perform enumeration of the address space as a discrete step, and then send metadata more fully describing the address space using wildcards. that said, i have concerns about how well this approach would work in large address spaces that don’t have neatly-organized and uniform namespaces- all the test cases i have in mind would wind up using huge, enormously-complicated wildcard strings to describe methods spread all over the address space that might share the same basic attributes (and even so, several wildcard strings may be required in some circumstances).

hmm….another way of associating the same data structure with multiple OSC methods would be to explicitly define a schema- a partial OSC address path, and potentially a group of sub-paths- and then reference that schema at multiple paths in the JSON blob while enumerating the address space. i haven’t put a ton of thought into this, but a quick example using jeff’s device could look a bit like this, with schemas that define a single EQ and a single input, and then a root node that describes 72 inputs (the schema for an input references the schema for a single EQ).

{
    "DESCRIPTION": "root node",
    "ACCESS": 0,
    "SCHEMAS": {
        "EQSchema": {
            "DESCRIPTION": "sample EQ schema",
            "ACCESS": 0,
            "CONTENTS": {
                "freq": {
                    "DESCRIPTION": "frequency method",
                    "ACCESS": 2,
                    "TYPE": "f",
                    "RANGE": [
                        [0.0, 1.0, null]
                    ]
                },
                "gain": {
                    "DESCRIPTION": "gain method",
                    "ACCESS": 2,
                    "TYPE": "f",
                    "RANGE": [
                        [0.0, 1.0, null]
                    ]
                },
                "Q": {
                    "DESCRIPTION": "Q method",
                    "ACCESS": 2,
                    "TYPE": "f",
                    "RANGE": [
                        [0.0, 1.0, null]
                    ]
                }
            }
        },
        "InputSchema": {
            "DESCRIPTION": "sample input schema- note that it uses the EQSchema!",
            "ACCESS": 0,
            "CONTENTS": {
                "1": {
                    "SCHEMA": "EQSchema"
                },
                "2": {
                    "SCHEMA": "EQSchema"
                },
                "3": {
                    "SCHEMA": "EQSchema"
                },
                "4": {
                    "SCHEMA": "EQSchema"
                },
                "5": {
                    "SCHEMA": "EQSchema"
                },
                "6": {
                    "SCHEMA": "EQSchema"
                },
                "7": {
                    "SCHEMA": "EQSchema"
                },
                "8": {
                    "SCHEMA": "EQSchema"
                },
                "9": {
                    "SCHEMA": "EQSchema"
                },
                "10": {
                    "SCHEMA": "EQSchema"
                }
            }
        }
    }
    "CONTENTS": {
        "1": {
            "SCHEMA": "InputSchema"
        },
        "2": {
            "SCHEMA": "InputSchema"
        },
        "3": {
            "SCHEMA": "InputSchema"
        },
        "4": {
            "SCHEMA": "InputSchema"
        },

        ... etc etc etc, didn't feel like going out to "72" :-P
    }
}

what does everybody else think? are there any specific concerns about the length of the initial JSON blobs? if so, what are the feelings on these workarounds, and does anyone have any other ideas?

theod commented 9 years ago

an idea could be : if the name of a node is {a, b, c} it creates 3 nodes called "a", "b" and "c". if the name of a node is [1::512] it creates 512 nodes called "1", "2", "3", ..., "512".

however I guess the use of { } and [ ] are not very welcome in JSON format ... anyway mixing this kind of syntax with the schema feature could be very powerful !

jdkoftinoff commented 9 years ago

but what is that specific concern, exactly? if none of the devices you just mentioned have a service/address discovery mechanism then what role do they play in your concern? can i ask for another hint?

Well, seeing that there was no standard or suitable query mechanism for OSC at the time we did not add one. We would like to though! And it would be really nice if there were one way that was suitable for all these uses. After a number of OSC based query mechanisms were proposed, it was made clear that this complicates the simple nature of stateless OSC; your proposal using JSON over HTTP is a great start. I would like to be able to use it.

did he post it anywhere else, or is it only behind a paywall?

Not that I am aware of. But I just purchased it for $5 as an AES member.

you reference a 1.1 version of the OSC spec a number of times- if you could please link me to the official OSC 1.1 spec,

There is no official 1.1 OSC specification. It was expected to exist when I wrote the AVBC document but that proposal in the NIME conference paper ( http://cnmat.berkeley.edu/node/7002 ) was not carried forward.

I really like your SCHEMAS JSON entry suggestion!

bltzr commented 9 years ago

I really like your SCHEMAS JSON entry suggestion!

:+1