Review of archived developments

[pljones]

In a similar vein to looking to the future, I've taken the opportunity to look at some of the "nearly but not quite" pieces of work that have been shelved over the years - these are held in archived branches. (Note that these have mostly be renamed from the originals.)

There are several of these that aren't that far off complete and some that quite closely align with some of the items that came up when the proposals for Jamulus 4 were raised.

So it seems like a good idea to go through each of them. I'll post a separate reply thread for discussing each of them, starting with my views to kick things off.

I'll just end by reminding everyone. Anyone can contribute to Jamulus. One of the most productive things you can do is read and understand the code and give feedback on it. Suggest -- even provide -- improvements. Not all of them will be accepted. Not necessarily because they're not wanted. Sometimes they're just "not quite ready" and need a bit more work. That's what's happened to a lot of this code. But this is code you are free to look at and say "I love that idea! I want to make it happen." and get it ready for a future Jamulus version.

[pljones]

There are two related branches:

• archive/cwerling/conductor-choir-mix-mode
• archive/corrados/conductor-choir-mix-mode
  I'm guessing @cwerling rebased @corrados original work at some point. Unfortunately it's pretty out of date now (indeed, when Volker last merged master into his branch he stopped work on it as far as I can tell).

So, what's it good for? The aim is to have one participant in the jam in control over the mixer - every other participant other than the controller (or "conductor" as I've styled it) would have only a single fader to control the overall output level.

Apart from bringing the code up to date, before it could be accepted into the build there are a number of things I'd like discussed:

• It would, of course, have to be optional: either at build time or, preferably, using a command line and GUI option for the server.
• A server in this mode should reject any attempt to connect from a client not explicitly enabled to connect to such a server. (This is to avoid confusion for all server users.) So there would need eto be a command line and GUI option for the client.
• Should servers running in this mode be visible on the Public Directories at all? Would it cause confusion?

[pljones]

Another two related branches which are interesting but probably currently conflicting badly with each other:

• archive/corrados/multi-channel-in-to-stereo-mixer
  @corrados added this to allow a client to have multiple input audio channels and supplies an embedded mixer to mix down to stereo before sending the audio stream over the existing client<->server channel.
• archive/dcorson-ticino-com/multi-channel-to-server
  @dcorson-ticino-com added this to allow a client to have multiple input audio channels and sends them over separate client<->server channels.

Getting a common solution out of them that worked with all platform audio sources would really increase what Jamulus could offer. I can also see that these and conductor/choir mode being a big step forwards for some situations.

Some bits I think need working on, in addition to bring the code up to date and making the two approaches work together:

• The "multi-channel-to-server" feature should allow the name, instrument and expertise to be set, as for any other channel (if it doesn't in the patch already)
• Any client should be able to see from the mixer whether a set of clients is using the "multi-channel-to-server" feature. We'd need something to indicate the related channels, which could mean a lack of backwards compatibility with other clients and servers. (The profile information probably would be flexible enough but this could be checked. Ideally it would want to be a client unique ID that each related channel shared that was refreshed for each server connection...)

[pljones]

The other main one was this from @ann0see:

• archive/ann0see/server-moderation
  This provides a server operator with the ability to moderate their server, adding moderation commands to allow chat and audio control

I've the same comments to "conductor/choir mode", as both add a degree of "access control" to the server:

• It would, of course, have to be optional: either at build time or, preferably, using a command line and GUI option for the server.
• A server in this mode should reject any attempt to connect from a client not explicitly enabled to connect to such a server. (This is to avoid confusion for all server users.) So there would need eto be a command line and GUI option for the client.
• Should servers running in this mode be visible on the Public Directories at all? Would it cause confusion?

[ann0see]

I think this should be a JSON-RPC controlled option.

• Start with being able to disable the chat during runtime.

The full feature set like waiting rooms should not be registered on public directories. However, some may be ok.

[pljones]

Of the remainder:

• archive/danryu/CIPlaystore (@danryu)
  I've rebased this and raised a draft pull request but it needs discussion and probably a lot of work.
• archive/npostavs/portaudio (@npostavs)
  Personally, I think this is redundant as we have the JACK build on Windows, which uses PortAudio anyway.
• archive/dingodoppelt/ffmpeg-streamer2 (@dingodoppelt)
  I have ideas here... The idea of plugins is raised in the Jamulus 4 thread. I'd like to move both the Jam Recorder and the Jam Streamer behind some kind of generic plug-in API at the server.
• archive/corrados/replace-qInfo-with-iostream (@corrados)
  If I remember correctly, there was concern that Qt was becoming an uncomfortably closed development framework and moving off it might be feasible. The starting point was to remove obvious code, like qInfo etc, replacing with standard C++ console logging. Given we're likely locked into Qt "forever", I don't think this is likely to progress.
• archive/corrados/vst (@corrados)
  There was a working VST version of Jamulus. Briefly. I don't remember it being stable but I do remember it opening the UI. There are reasons for having the ability to plug a DAW into Jamulus, of course - but mostly they can be solved in other ways. The VST2 API is also no longer supported, so I guess we'd need to go for CLAP here, too, if a new plug-in version of Jamulus was ever wanted strongly enough for someone to write the code for it.

[ann0see]

archive/npostavs/portaudio (@npostavs)
Personally, I think this is redundant as we have the JACK build on Windows, which uses PortAudio anyway.

Not necessarily. The idea was to make setup easier on windows. Since ASIO4ALL is hard to setup in some cases, PortAudio was tested to be more user friendly.

[pljones]

I'm not sure the default build of PortAudio would be suitable, so we'd be supporting the configuration ourselves. I'd also not like to add more overhead.

[npostavs]

PortAudio was tested to be more user friendly.

In theory yes, but in practice I don't think I managed to get it working very smoothly with actual hardware.