JSON-RPC API methods to control and monitor channel parameters

[riban-bw]

The documentation for JSON-RPC API implementation in jamulus does not include the ability to set, get or be notified of changes to:

• fader
• balance
• mute
• solo

These would be very useful additions to the API allowing remote control of a headless client. It would facilitate integration of a jaumuls in other devices, e.g. zynthian.

I have considered using the MIDI CC control but this does not implement feedback so the remote client cannot know if its state agrees with the actual jamulus state.

[ann0see]

Hi. Thanks for the request. That's surely a feature which would be good. I vaguely remember there was a discussion about that saying that it was a bit tricky as the client levels are stored in the GUI and the server doesn't support sending fader levels back at the moment.
It seems possible to implement a new message (and POCs might even exist somewhere in the Single Mix PRs or feature branch.)

[pljones]

Yep.

Currently there is far too much state held in the GUI (mostly client-side, some server-side). None should be there - it should all be in the underlying CClient etc code rather than CClientDlg etc code. The fader positions and checkboxes are pure UI - adjusting triggers requests to send levels to the server and the server sends back current state (i.e. when you connect) that's displayed.

[iamthechrisb]

Looking at some other projects, ELK for example, looks like they are doing something with gRPC and OSC.

[ann0see]

I've just started working with gRPC and while it's great in theory, it's quite involved - especially the C++ library.

[riban-bw]

Hi! I would like to revive this discussion. Used Jamulus r3.9 (as provided by Debian 12 Bookworm) I have been able to integrate a lot of functionality with Zynthian (a Raspberry Pi based audio device). Using MIDI CC control of each channel provides adequate (but not perfect - no feedback) control. Using JSON-RPC provides a little extra control and some monitoring allowing display of connected users, metering, etc. This integration is almost good enough but there are some features missing to provide the full (or at least substantial) experience. Through other integrations, e.g. PianoTeq I have discovered that JSON-RPC is suboptimal for rapid access so the MIDI control is currently a good option. I would love to see OSC control and monitoring added. (I may one day be tempted to submit a PR for this!)

The most notable is access to server lists / directories. Lists of public servers are availble in the GUI during the connect stage but these are not exposed via JSON-RPC or any remote access method. It would be advantageous to be able to query the directories of public servers. I have looked at the source code but have not yet worked out how to do this directly and think it may be better to expose the functionallity via the API, e.g. JSON-RPC call. My current integration only supports access to servers that the user knows the IP address / hostname and port number. This works well for private servers that are shared between members but one of the fun parts of Jamulus is joining public sessions, meeting and playing with stangers / new friends.

I would like JSON-RPC functions added to provide:

• Get list of public server directories (catagories)
• Get list of servers in each directory with some info about each server, e.g. name, ping time, etc.
• Get list of users connected to a server (before connecting, as displayed in the GUI server list)
• Ability to change settings including:
  • Profile (only name and skill level are currently exposed)
  • Audio config (channels, quality, input balance)
  • Network config (jitter buffer, small packets)

Access to more core parameters improves the ability to integrate Jamulus within devices which brings benefits such as the ability to provide higher level of accessibility, more widespread adoption, etc.

[ann0see]

Fine with that. @dtinth @mcfnord

[dtinth]

@riban-bw For directory, I maintain an infrastructure that keeps track of current and historical Jamulus server list here:

https://github.com/dtinth/jamulus-php/blob/master/ARCHIVE.md

Feel free to use it if it suits your use-case!

[mcfnord]

I log a very minimal set of data with minute-by-minute granularity (but only updated daily):

https://jamulus.live/census_uniq.csv
(watch out, it's gigantic!)
https://jamulus.live/census_metadata.csv
https://jamulus.live/servers_metdata.csv

Soon it will cover a full year.

[riban-bw]

I have implemented a JSON-RPC method and notification for this:

• rpc_method jamulus/pollServerList Request a server listing from a directory (single parameter is the directory URL)
• rpc_notification jamulusclient/serverListReceived Receives a list of servers on the directory with fields: url, name, country, city.

I am not aware of a mechanism to get a list of public servers. It may be advantageous to publish the list of jamulus hosted servers. (I couldn't find them anywhere outside the source code.)

Having looked at how the data is organised I see that ping time, quantity of connected clients and list of connected clients are properties of each server so should be implemented with their own methods / notifications. I have not yet done this.

I have not yet looked at changing settings via JSON-RPC.

I will submit a PR.

[riban-bw]

The list of engines - is that documented anywhere or do you just need to know?

[dcorson-ticino-com]

If I remember correctly that list is hard coded in the code.

[mcfnord]

I believe that's right. Anyone can run a directory, and seven directories are built in to the source code.

Many projects and users rely on https://github.com/softins/jamulus-php for real-time details about servers on each directory. (Its output looks like this.) The main reason I've considered re-implementing that PHP by extending https://github.com/dtinth/gojam is so I could gather solo/mute states. It sounds like in your approach, my site could ask the directory via JSON-RPC, and so we might not rely on a faux client connecting for a split second everywhere.

At this time there is no public RPC interface to an arbitrary running server (JSON-RPC is password-protected). But I think you're talking about JSON-RPC interface on the directory server.

Side note: I wonder if someone wants to pick up on this interesting code: https://github.com/passing/jamulus-python/tree/master

[ann0see]

To increase your chances of "quick" merging provide those changes only in a PR.
We're unfortunately very slow at the moment.

[riban-bw]

I am confused. I am convinced I submitted a PR but it doesn't seem to be active. I have just resubmitted it and see now that I had not completed the process before.