search

drobilla / ingen

A realtime modular synthesizer and/or effects processor
GNU Affero General Public License v3.0
30 stars 7 forks source link

JSON / JSON-LD serialisation #19

Closed loki42 closed 3 years ago

loki42 commented 4 years ago

Would you be open to a pull request that add an additional serialisation format for network communication? Maybe the client can negotiate one? RDF / turtle is slow and difficult to process in many languages for getting out simple info. Encoding it in JSON or JSON-LD seems to make it much easier for basically all languages to parse very quickly as JSON is a very well supported format.

drobilla commented 4 years ago

Or: rdflib sucks :)

In theory, sure, but much easier said than done. I don't think a bespoke serialization (that isn't a general RDF one) really makes much sense for Ingen, but JSON-LD would certainly be a nice best-of-both-worlds. There is a serd branch for that I was working on, but it's quite complex and I haven't gotten it into a usable state yet.

loki42 commented 4 years ago

The main use case for me is for output CV port value updates. I'm making a few generative lv2 modules and being able to see signal follow would be handy but the current system has a ton of over head with slow parsing and a lot of extra info for one float. Also the other bug with enabling broadcast is related to that. If there's a better approach to getting values at a sensible rate for animation (maybe a few a second) I'd love to know.

On Sat, 18 Apr. 2020, 1:24 am David Robillard, notifications@github.com wrote:

Or: rdflib sucks :)

In theory, sure, but much easier said than done. I don't think a bespoke serialization (that isn't a general RDF one) really makes much sense for Ingen, but JSON-LD would certainly be a nice best-of-both-worlds. There is a serd branch for that I was working on, but it's quite complex and I haven't gotten it into a usable state yet.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/drobilla/ingen/issues/19#issuecomment-615306772, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAISQBDH6HNOT42524BXS33RNBYBDANCNFSM4MJBS24A .

drobilla commented 4 years ago

I see. I idly considered adding other facilities if just doing everything in the same uniform way ever proved too slow, but at least with the main implementation that hasn't proved the case. I can see how rdflib would dramatically change that equation though.

There could be some mechanism to request particular updates on a different "channel" (socket) which would be handled differently. If you really want speed, it could even use the binary protocol (with all the platform caveats thereof). I'm not really sure how this would look though.

loki42 commented 4 years ago

That does sound good. If you see the other bug I can't get publish to work for a single port which might help.

On Sun, 26 Apr. 2020, 10:28 pm David Robillard, notifications@github.com wrote:

I see. I idly considered adding other facilities if just doing everything in the same uniform way ever proved too slow, but at least with the main implementation that hasn't proved the case. I can see how rdflib would dramatically change that equation though.

There could be some mechanism to request particular updates on a different "channel" (socket) which would be handled differently. If you really want speed, it could even use the binary protocol (with all the platform caveats thereof). I'm not really sure how this would look though.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/drobilla/ingen/issues/19#issuecomment-619541944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAISQBHIVD6J7CWH25KCEBLROQSG5ANCNFSM4MJBS24A .

drobilla commented 4 years ago

I don't get how you can have both this problem and one that means you can't make this situation happen in the first place?

drobilla commented 4 years ago

So after some (sidetracked, sorry) tinkering wondering about the long run here: https://github.com/drobilla/serd/commit/9c284e1970d4953f1f1fa415809b389ea5b96251

Which makes me wonder if providing a proper interface and getting rid of this string mess would really be so much work. Not pure Python, of course, but, meh.

loki42 commented 4 years ago

Oh I can turn on broadcast for all ports just not a specific one. :-)

On Tue, 28 Apr. 2020, 4:53 am David Robillard, notifications@github.com wrote:

I don't get how you can have both this problem and one that means you can't make this situation happen in the first place?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/drobilla/ingen/issues/19#issuecomment-620168608, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAISQBGBNXLC5LMEWKYJZVDROXIELANCNFSM4MJBS24A .

drobilla commented 4 years ago

Huh. I'll look into it this weekend.

I guess some deeper fix for garbage syntax on the server side will be needed. Maybe skip until a "." is read or something...

loki42 commented 4 years ago

It's very easy to crash the server side with invalid commands.

On Thu, 30 Apr. 2020, 10:31 pm David Robillard, notifications@github.com wrote:

Huh. I'll look into it this weekend.

I guess some deeper fix for garbage syntax on the server side will be needed. Maybe skip until a "." is read or something...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/drobilla/ingen/issues/19#issuecomment-621803928, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAISQBEQVNE64ECFED3DQODRPFVTTANCNFSM4MJBS24A .

drobilla commented 4 years ago

Yeah, it's pretty resilient at the semantic level so to speak (all the events handle all the edge cases and fail gracefully and such), but actually invalid syntax isn't handled so well. It's a bit tricky because the parser is pulling directly from the socket, but I'll figure something out.

loki42 commented 4 years ago

18 has examples but basically:

ingen.set("/main/ratio/numerator", "http://drobilla.net/ns/ingen#broadcast", True) ingen.put("/main/ratio/numerator", "http://drobilla.net/ns/ingen#broadcast true")

are the problem cases for me.

drobilla commented 4 years ago

I suppose I should mention, in case its not obvious, that the Python bindings are just a one-off hack to make ingenish kinda work. They're pretty sketchy, as you've seen, and the server is not really hardened for clients that talk syntactic nonsense (though it should be, as any server should in general).

Turtle fragments in the API as above especially need to go. You might want to consider improving them a bit, this can be done just in Python land and is about a billion times easier than implementing JSON or something like that (and works towards it anyway, since the API would also have to change to be Pythonic and not have Turtle strings and stuff in it for that to work).