LMMS / LMMS/lmms

Add DnD of OSC paths from plugins?

Open
#5,710 4 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
C++
Stars
10.4k
Forks
1.3k
Avg merge
2d 13h
Merged PRs (30d)
7

Description

### Enhancement Summary

Refactor functionality from the SPA plugin PR (#4662) into a separate PR. It's about drag-dropping OSC paths from (external) plugins onto LMMS controllers/automation. I can add it almost immediately, and it will be non-reachable code on master for now.

#### Justification

It's an independent split-feature from the SPA PR that could, in theory, be used generically. It could be used by any plugin that support DnD of osc paths. Though, there's no evidence it will ever be used, and it will not be useful for Lv2 (DnD mimetypes/data are not a part of the Lv2 specs and probably won't be too soon).

Also #5592 .

#### Mockup

It would work like this:

1. All (external) plugins can register with a port. The mapping port->plugin is stored in the Engine.
2. When a drag from an (external) plugin drops on an LMMS automation pattern, the clipboard for this drag-drop-action will contain something like:
1. mime type: application/x-osc-stringpair
2. data: osc.udp://127.0.0.1:udpport/path/to/oscport
3. LMMS looks up the plugin by passing the udpport in the Engine.
4. The plugin class gets a new "model at path" virtual function. LMMS passes "/path/to/oscport" there to get a pointer to the corresponding model from the plugin.
5. If the model does not yet exist, the plugin creates it now.
6. LMMS now has both a model from the plugin and the controller/automation, so it can connect the two.

#### Question

There are disadvantages:

1. It will be non-reachable code on master branch (tested by me on the SPA branch, but not tested and not reachable on master)
2. The code might never be used on master and confuse other devs ("what is this used for?")

Should we add this feature as non-reachable code?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing the SPA plugin PR referenced as #4662 and the related issue #5592 to understand the proposed split. Resolve whether non-reachable OSC drag-and-drop support should be added to master; the issue does not name implementation files or tests, so a maintainer decision is needed before coding can begin.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.