qnebra
commented
3 years ago Ok, my thoughts and opinions about some points:
- This doesn't need to be realtime. It isn't competetive shooter in which ping is really important. Changes could be synchronised for example 'on save', and nothing like playing in realtime on instruments. wouldn't be really usable. Cases where realtime feedback is really important.
- I think quite nice way to distinguish what each user in session do would be by using "track colors", each user have their own color of clip, set on start of shared session.
Do you sync windows between clients?
I think it doesn't need to sync windows positions at all.
What if my friend has different samples than me?
There is currently PR with fix for this issue, and in long term to improve projects sharing.
What about opening VST plugins?
Proper VST scanning, then it doesn't matter where users have them.
What do you actually sync between users?
Basically, what is inside "shared project" location, which consists project savefile, presets, samples. And was completly sanboxed to avoid as much possible security risks as possible, as this could be absolute pain.
ANVF-Postal
DomClark
musikBear
Calendis
rdrpenguin04
mikobuntu
SUMMARY Networked multiplayer would allow LMMS users to collaborate with each other in remote sessions. By synchronizing the actions of each user in real time, the project would be an exact copy on each user's screen. If one user turns a knob on his end, the knob will turn for everyone else.
Justification Musical collaboration today is slow and tedious. If you want to collaborate on a track with your friend, you need to join a video call with them and either share your screen or stream audio. Your friend can only give you bits of advice on how the track should sound and for some, these can get very vague as in "make it punchier" or "give it more flow". In these situations, it would be much easier to have the two people just work on the same project in real time. This way your friend who's all about FM synths can directly and easily add and shape parts of the song, without having to upload the project to Dropbox or use laggy remote desktop software. This workflow would greatly speed up collaborative production, and LMMS would be the only good DAW capable of it.
Mockup The premise behind networked multiplayer is very basic: as long as all changes are synced between users in real time, each user is working on the exact same project. Because of this, no audio data actually needs to be transferred between users, with the exception of audio samples. This of course greatly lowers the bandwidth needed, and each user can play back a completely uncompressed version of the song from their end.
For the host, it will look no different from hosting a game server. Just a simple server executable and configuration files, with the potential ability to launch the server straight from within LMMS itself. The configuration file would have parameters for session name, port, sync windows (true/false), perhaps an update tick rate and other options.
To connect to a server, the user would press the "multiplayer button" in the top pane.
Once the button is clicked, the user will be shown a window similar to the image below:
The user will input the host IP and port (possibly a password in the future) and the multiplayer window will change to this:
This is a list of all users connected to the session, and P O S T A L is the host, so he can't kick himself. From here, each user can choose to toggle the cursors of other users, and has an options panel per user for other settings. The host will also have kick buttons for people who misbehave.
Once that's done, LMMS will perform an initial sync of the project to get all clients up to speed. From there the UI and workflow is exactly like regular LMMS, only now you're with friends.
There are some initial problems that I would like to mention, and possible solutions for them.
Do you sync windows between clients? This may get muddy, but it would probably be best to leave it as a server setting for the host. The nature of LMMS's expandable windows, and the 2D scrolling ability could give users the ability to lay out all their plugins at the same time. On the other hand, people might not like being randomly interrupted, or having a cluttered screen full of plugins. This should be optional.
What if my friend has different samples than me? In short: they would be able to load them, but you won't. There are solutions of course, a brute force solution is just to have your directories laid out the same as everyone else. As long as the folder structure and file paths are the same from user to user (perhaps you could sync them with a personal network drive) they should load fine. However another option could be to add a "multiplayer" folder, which the user points to in the LMMS directory page. As long as you could call that directory and recursively search through it, everyone would be fine as long as they have the same samples and sample names. LMMS should not add an option to send the files from one user to another, because this could involve legal issues for copyrighted samples.
What about opening VST plugins? As long as the directory and plugin DLL name are the same, it should open just fine. Users will need to make sure their plugins are the same version (and the same plugin) before connecting to the session. The host should be given the ability to only allow certain plugins, and perhaps display a warning when a user connects to make sure they have the same plugins. There can't be any option to just pass VSTs from one user to the other, because of legalities. You could also checksum each VST before loading it, and notify the user if their checksum isn't the same as the server's, but I have little insight on how that works. VSTs exponentially multiply the usability of any DAW and it's vital that they are synced.
What do you actually sync between users? Project-specific changes only. Synth patches, mixer channels, controllers, song notes and others. Certain parameters like playback or pause should not be synced, as well as individual client settings. Users are only meant to change the project.
I'm very open to feedback on this, and I believe it would be an amazingly useful and unique feature to add to LMMS.