Suggested feature: Allow more than one instrument icon per user

[juanriccio]

A feature request: Allow more than one instrument icon per user

There are many poly-instrumentalists using jamulus, but only one instrument icon is possible. The description field length is short enough that there is no room for a name and more than one instrument. Making our instrument list immediately visible has the obvious advantage of making the people in a jam room able to allocate themselves optimally.

Thanks for considering!

[pljones]

You can start Jamulus with different profiles. If you're switching instrument, run a new instance with a different profile.

[juanriccio]

I often have them all available ready to use, so it would be nice to be able to communicate that whenever I join a server.

[dingodoppelt]

I have the same "problem" 😆
(I just an icon of an instrument I never play, which doesn't solve this obviously ;)
I don't see an easy way of displaying more than one icon in the client but we might just introduce a new "multi-instrumentalist" icon instead.
If you feel artistically inclined you can always contribute one.

You can set your user information using the JSONRPC interface which can be used in scripts which can be bound to hotkeys in case you're looking for an alternative to setting the instrument in the UI.
EDIT: I just noticed you can't set your instrument via JSONRPC, only name and skill level. I feel a pull request coming...

[pljones]

I think the JSONRPC option is probably the best approach. You can probably get GitHub CoPilot to write you an app to do this within your free allowance, just by asking for it. (Set up a new repo, tell it about the Jamulus JSONRPC Client API and what you want the app to look like.)

[dingodoppelt]

Sorry, I only remembered you can set certain parts of your channel info via JSONRPC. Setting the instrument wasn't actually possible but I opened #3772 to hopefully fix that.

[pljones]

(As soon as someone else approves it and it's merged :) )

[ann0see]

I think that's quite hard to implement and definitely not backwards compatible.

[juanriccio]

I see. Then maybe a longer description field could help. I hope older clients do truncate the description when displaying it, or have similar safeguards in place to avoid buffer overflows and similar problems.

[pljones]

The fields are part of the protocol. Changing the length breaks compatibility with older servers by requiring a new message type.