[WIP] OSC support via liblo #2064

iffyloop · 2019-03-24T16:33:45Z

This pull request adds OSC support (provided by the oscpkt library) to Mixxx. This has been discussed under the "OSC Support" topic of the development stream on Mixxx's Zulip instance. Please feel free to provide any further feedback and ideas of changes that should be incorporated here.
Thanks!

iffyloop · 2019-03-24T16:42:31Z

@harryhaaren I'm still fairly new to threading and networking in C++, so thanks for bringing up the blocking issues. If you or anyone else could give me some guidance as to what would be involved in creating a dedicated OSC thread, that would be appreciated. Would that interfere with the other Mixxx controller threads? In that case, I'm wondering if it would be better to switch libraries to liblo and use it to create a non-blocking server:
http://liblo.sourceforge.net/examples/nonblocking_server_example.c.html

In response to your question about making the socket "block forever" - that's what happens if you set the timeout to -1. I tried this yesterday and everything seemed to work fine (but I didn't test with any hardware controllers plugged in - I'm guessing it might have blocked those) until I closed the application, at which point Mixxx just froze and stopped responding.

iffyloop · 2019-03-24T16:46:15Z

I think mapping each group/key to a ControlProxy makes sense, but I'm wondering if there would be the same performance overhead if the map grew large from many different controls being addressed. Could you explain why ControlProxy is such a heavyweight class?

harryhaaren · 2019-03-24T19:55:31Z

Re threads; example is Ctlra controller, creates one thread for any amount of Ctlra controllers: https://github.com/openAVproductions/mixxx/blob/ctlra/src/controllers/ctlra/ctlraenumerator.cpp#L16

I expect the design to map best to using on thread per OSC socket, because that allows blocking the thread on the socket read - causing it to go to sleep until the kernel wakes it up because it has work to do.

I see no advantage to switching to LibLO per-se, using -1 to achieve non-blocking is just a good as using a library that supports it using API calls.

Re; threads and interfering with other Mixxx threads;
A ControlProxy uses "atomic" writes to achieve a single consistent state - this means that writing a value from one thread will just over-write the previous value - but you'll never get "half" of the previous value, and half of the new value (due to threading issues). This makes it easy to use ControlProxy's in lots of threads, and nobody needs to manage things bar using a ControlProxy->set() function to update the value itself.

Re: ControlProxy creation; Creating any class is usually expensive - in this case the ControlProxy is "linked" to a ControlObject, which has to be found. I believe the current implementation is using a HashTable, so the the "Group/Key" pair get hashed and then looked up (this isn't too expensive usually). What can be particularly expensive is calling malloc() or new in the C++ case. Although the code here doesn't directly do that, we can't be sure that the ControlProxy() constructor function doesn't allocate memory internally. For this reason, if you know you'll need something in "normal" usage of a program, its usually better to identify it, and cache it for use, instead of allocating and de-allocating it every time it is required.
Most importantly: measure if there is a real world impact on performance due to this!

harryhaaren · 2019-03-24T20:03:31Z

Left a comment in the Zulip on caching ControlProxy* instances in a hash table after they're used once - this will make the commonly used controls more performant to access, and the not-used controls will not consume any memory: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/OSC.20Support

daschuer · 2019-03-25T07:26:58Z

Did you considered to use liblo instead of oscpkt? The other draft implementations is using this, and IMHO we should use only one if there is no technical limitation.

daschuer · 2019-03-25T08:22:04Z

Could you explain why ControlProxy is such a heavyweight class?

The required Hash table lookup is the heavy part. The object itself avoids to doing it over and over again because it just wraps a shared pointer to the control and adds the capability of receive the valueChange signal. I have created a PR introducing a light version of ControlProxy without the valueChange hook #1717 but this does not relrase you from the hash table lookup and the required string math.

daschuer · 2019-03-25T09:33:42Z

This PR:
#1675
Introduced the Mpris D-Bus interface to Mixxx and uses a thread to write a file https://github.com/davidhm/mixxx/blob/39dc90135a2f3d373c05ab944198536fc8fbfbac/src/broadcast/filelistener/filelistener.cpp
Maybe this helps.

iffyloop · 2019-03-25T17:29:56Z

@daschuer I'm a little confused about the end of your message "we should use only one if there is no technical limitation." Are you talking about using only one thread? Or are you saying we should switch to liblo?
The reason I mentioned liblo earlier is that I think it can handle threading for us (something like http://liblo.sourceforge.net/examples/example_server.c.html). I think maybe we would just have to call lo_server_thread_start in OscController::open and lo_server_thread_free in OscController::close. Then we could get rid of OscController::poll and let liblo call our OSC methods, right? I'm happy to try that approach, but it would be helpful if you could give me some guidance on how to correctly include liblo via Mixxx's build system.
Also, if the hash table lookup is the heavy part of using the ControlProxy class, then wouldn't the caching proposal by @harryhaaren be just as slow?

daschuer · 2019-03-26T00:01:45Z

Or are you saying we should switch to liblo?

Yes, #2062 uses liblo, so maybe it suits for all OSC topics. But I am unsure because I have never worked with it. At least it is under active development http://liblo.sourceforge.net/NEWS.html

The reason I mentioned liblo earlier is that I think it can handle threading for us ...

That looks easy, hopfuly.

liblo is setup in #2062 for Ubuntu. We need to add it to the Windows and Mac CI to be able to successful build it.

I think your approach an #2062 can live side by side. Do we need here a preferences page as well? Maybe we can use one common page for client ant server.

Also, if the hash table lookup is the heavy part of using the ControlProxy class, then wouldn't the caching proposal by @harryhaaren be just as slow?

Since the Hash Table scales well for many entries, I expect only a minor benefit if you set up your own hash table. With the single parameter solution, we have the chance to get entirely rid of the hash table and save the ControlProxy inside the callback.

daschuer · 2019-03-26T00:19:25Z

Should this relay become a controller? We have a model for each hardware controller in Mixxx to allow a mapping via GUI or Java.

In the OSC receive case we offer a fixed API anyone can use. Is there a need for a OSC controllrt model?

iffyloop · 2019-03-26T03:21:33Z

I just rewrote the majority of OscController.cpp to use liblo rather than oscpkt. There's no more polling now and liblo takes care of creating its own non-blocking thread. All controls are now addressable via their own path, so you can send messages like "/[Master]/crossfader 0.3" (path, double). If possible, types of value (e.g. int, float, bool, etc.) are automatically converted to double (so you can send "/[Channel1]/play true" and Deck 1 will start playing). If you want to query a parameter, you send "/[Master]/crossfader '?'" (path, string) - just like the Resolume docs @daschuer linked me to on Zulip.

iffyloop · 2019-03-26T04:05:06Z

The switch to liblo is done. I'm confused by the idea of saving the ControlProxy inside the callback? To clarify, there is only one generic callback that is invoked for all possible OSC paths (which map to key/value pairs). -------- Original Message --------

…

On Mar 25, 2019, 7:01 PM, Daniel Schürmann wrote: > Or are you saying we should switch to liblo? Yes, [#2062](#2062) uses liblo, so maybe it suits for all OSC topics. But I am unsure because I have never worked with it. At least it is under active development http://liblo.sourceforge.net/NEWS.html > The reason I mentioned liblo earlier is that I think it can handle threading for us ... That looks easy, hopfuly. liblo is setup in [#2062](#2062) for Ubuntu. We need to add it to the Windows and Mac CI to be able to successful build it. I think your approach an [#2062](#2062) can live side by side. Do we need here a preferences page as well? Maybe we can use one common page for client ant server. > Also, if the hash table lookup is the heavy part of using the ControlProxy class, then wouldn't the caching proposal by ***@***.***(https://github.com/harryhaaren) be just as slow? Since the Hash Table scales well for many entries, I expect only a minor benefit if you set up your own hash table. With the single parameter solution, we have the chance to get entirely rid of the hash table and save the ControlProxy inside the callback. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2064 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AhnMpNHP6Z6kB6yjMuLksuvcUy7L-6PBks5vaWNtgaJpZM4cFmaZ).

iffyloop · 2019-03-26T04:08:33Z

I tried creating a controller because that's what @be suggested in Zulip and also because I was already familiar with Mixxx's controller system. I had the same concern, and if you think it would be better to integrate OSC separately from the controller system then that sounds good to me. I'll try to do something like the other OSC PR you mentioned earlier if it's more like what you want. -------- Original Message --------

…

On Mar 25, 2019, 7:19 PM, Daniel Schürmann wrote: Should this relay become a controller? We have a model for each hardware controller in Mixxx to allow a mapping via GUI or Java. In the OSC receive case we offer a fixed API anyone can use. Is there a need for a OSC controllrt model? — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2064 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AhnMpHrpmo_m6D82k0oHK3FQcTI35b4yks5vaWeQgaJpZM4cFmaZ).

daschuer · 2019-03-26T22:00:27Z

I think the controller model, does actually not fit well here.
The OSC Server is represented as a controller here. Normally the clients are represented as a controller.
In this case it would be TouchOSC, but we cannot do it because Mixxx is not aware any OSC controller.

iffyloop · 2019-03-26T22:19:45Z

Makes sense. So then where in your opinion would be the best place to set up an OSC server? Would I just create an OscServer class and then initialize it at some point (maybe after regular controllers) in the mixxx.cpp file? Or should it be more abstracted than that? -------- Original Message --------

…

On Mar 26, 2019, 5:00 PM, Daniel Schürmann wrote: I think the controller model, does actually not fit well here. The OSC Server is represented as a controller here. Normally the clients are represented as a controller. In this case it would be TouchOSC, but we cannot do it because Mixxx is not aware any OSC controller. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2064 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AhnMpMancnxuYKm8JqXwPDmVAOwhy_dPks5vaph_gaJpZM4cFmaZ).

daschuer · 2019-03-27T15:23:53Z

I am sorry I have not yet found the time to test you branch. Here only some thoughts that might be wrong:

If we look at TouchOSC it is a OSC Server and Client at the same time. A control has a unique single Unique address, that can be auto generated from the structure in TouchOSC or adopt the namespace of the controlled Application.

In this case of a fully customizable Controller, it is reasonable to use the Mixxx Namespace for it. It is somehow like
#2062 with its own preferences page. Here we need to enter the server port and the Clint's IP address and portnumbet. The current implementation of the client side is currently not flexible enough, since we cannot simply send every single CO update from Mixxx.

Here I have an idea from your implementation: How about using the temporary ControlProxy to register a OSC callback for all following OSC commands and register a value change callback at the control proxy to send OSC commands back.
This would be a nice plug and play solution :-)

If we think of more complicated control task where for example one control on the controller will control two controls of Mixxx, the a OSC Controller would be handy.

This can be implemented by copying the HID controller implementation where every hid command is parsed by a script.

We may also consider to use a Xml mapping file that would allow to map the controller namespace to the Mixxx Namespace.

daschuer · 2019-03-27T15:28:29Z

IMHO Mixxx can make use of both interfaces one for easy interfacing other customizable applications and one for map other static applications, that requires a mapping just like midi controllers.

I am fine with merging a solution that is somewhere on the way to it.

daschuer · 2019-03-27T15:29:57Z

Is it Ok to have the co namespace in the OSC address root? I am unsure.

iffyloop · 2019-03-27T18:01:44Z

@daschuer Sorry - I'm still a bit confused your previous comments. Is my implementation redundant now that #2062 is about to be merged? I don't want to clutter the Mixxx codebase if someone else has already implemented the same functionality.

daschuer · 2019-03-27T20:30:41Z

Both PR target different issue. This here is a OSC Server, the other one is a OSC Client.
For TouchOSC for instane we need both.

Can you have a look to the other PR and descide how a integrated solution will look like. If we have an idea about it we can tweak both towards it and merge them finally.

Pegasus-RPG

Question about how OSCEnumerator is structured. Comments inline. #2062 looks like it integrates OSC endpoints more deeply with Mixxx, rather than the "arm's length" approach the Controller subsystem offers. I've never used OSC so can't speak to which is more appropriate for the DJ use case, though my gut feeling is the deeper integration would be more flexible.

Pegasus-RPG · 2019-03-27T23:42:20Z

build/depends.py

@@ -58,6 +58,13 @@ def configure(self, build, conf):
    def sources(self, build):
        return ['controllers/midi/portmidienumerator.cpp', 'controllers/midi/portmidicontroller.cpp']

+# TODO: how to make this optional? (see OSC in features.py)


Answer: Check to see how HSS1394 does it. I believe you would move this liblo stuff to features.py, so it's only acted on if the feature is turned on.

Pegasus-RPG · 2019-03-27T23:43:11Z

build/depends.py

@@ -1529,7 +1536,7 @@ def depends(self, build):
        return [SoundTouch, ReplayGain, Ebur128Mit, PortAudio, PortMIDI, Qt, TestHeaders,
                FidLib, SndFile, FLAC, OggVorbis, OpenGL, TagLib, ProtoBuf,
                Chromaprint, RubberBand, SecurityFramework, CoreServices, IOKit,
-                QtScriptByteArray, Reverb, FpClassify, PortAudioRingBuffer]
+                QtScriptByteArray, Reverb, FpClassify, PortAudioRingBuffer, LibLO]


Pegasus-RPG · 2019-03-27T23:44:25Z

src/controllers/dlgcontrollerlearning.cpp

@@ -401,6 +401,11 @@ void DlgControllerLearning::visit(BulkController* pBulkController) {
    Q_UNUSED(pBulkController);
 }

+void DlgControllerLearning::visit(OscController* pOscController) {
+    qWarning() << "ERROR: DlgControllerLearning does not OSC devices.";


"does not yet support OSC devices"

Pegasus-RPG · 2019-03-27T23:49:36Z

src/controllers/osc/oscenumerator.cpp

+#include "controllers/osc/oscenumerator.h"
+
+OscEnumerator::OscEnumerator() {
+    m_devices.push_back(new OscController());


This seems strange to me. I understand this to mean that when an OSCEnumerator is instantiated, it creates a single OSCController. The intent of the controller subsystem is to query available controllers in queryDevices() using whatever API is required to see what OSC endpoints are on the network and return that list there. That allows users to hit a 're-scan' button in the GUI which would call queryDevices() again to get an updated list. As well, there is supposed to be one OSCController instance per endpoint. Does OSC not fit this paradigm?

iffyloop · 2019-03-28T01:21:14Z

Thanks for explaining. Hopefully in the next two or three days I'll have some time to come up with an integrated solution. -------- Original Message --------

…

On Mar 27, 2019, 3:30 PM, Daniel Schürmann wrote: Both PR target different issue. This here is a OSC Server, the other one is a OSC Client. For TouchOSC for instane we need both. Can you have a look to the other PR and descide how a integrated solution will look like. If we have an idea about it we can tweak both towards it and merge them finally. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2064 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AhnMpL38-mBa3G4kwmElz1DAkrKipJ2qks5va9T1gaJpZM4cFmaZ).

iffyloop · 2019-03-28T01:29:25Z

1. Ok, I'll examine HSS1394 again. I was actually talking about making liblo optional, not the sources, but you're right - I should have listed those sources in features.py not depends.py. Sorry for the misleading comment I left in that script. 2. Good question. The reason only 1 OscController exists is that this controller really represents a server (UDP socket) that Mixxx OSC cilents connect to. I believe even if you have many OSC clients connected to an application, they all talk to the same single server. I'm hopefully going to look into integrating my server code here with Jakob Braun's OSC client implementation (so Mixxx can act as both). When that's done, these files will probably disappear and the structure of this feature will change significantly. -------- Original Message --------

…

On Mar 27, 2019, 6:51 PM, Sean M. Pappalardo wrote: @Pegasus-RPG requested changes on this pull request. Question about how OSCEnumerator is structured. Comments inline. --------------------------------------------------------------- In [build/depends.py](#2064 (comment)): > @@ -58,6 +58,13 @@ def configure(self, build, conf): def sources(self, build): return ['controllers/midi/portmidienumerator.cpp', 'controllers/midi/portmidicontroller.cpp'] +# TODO: how to make this optional? (see OSC in features.py) Answer: Check to see how HSS1394 does it. I believe you would move this liblo stuff to features.py, so it's only acted on if the feature is turned on. --------------------------------------------------------------- In [build/depends.py](#2064 (comment)): > @@ -1529,7 +1536,7 @@ def depends(self, build): return [SoundTouch, ReplayGain, Ebur128Mit, PortAudio, PortMIDI, Qt, TestHeaders, FidLib, SndFile, FLAC, OggVorbis, OpenGL, TagLib, ProtoBuf, Chromaprint, RubberBand, SecurityFramework, CoreServices, IOKit, - QtScriptByteArray, Reverb, FpClassify, PortAudioRingBuffer] + QtScriptByteArray, Reverb, FpClassify, PortAudioRingBuffer, LibLO] Ditto. --------------------------------------------------------------- In [src/controllers/dlgcontrollerlearning.cpp](#2064 (comment)): > @@ -401,6 +401,11 @@ void DlgControllerLearning::visit(BulkController* pBulkController) { Q_UNUSED(pBulkController); } +void DlgControllerLearning::visit(OscController* pOscController) { + qWarning() << "ERROR: DlgControllerLearning does not OSC devices."; "does not yet support OSC devices" --------------------------------------------------------------- In [src/controllers/osc/oscenumerator.cpp](#2064 (comment)): > @@ -0,0 +1,16 @@ +#include "controllers/osc/oscenumerator.h" + +OscEnumerator::OscEnumerator() { + m_devices.push_back(new OscController()); This seems strange to me. I understand this to mean that when an OSCEnumerator is instantiated, it creates a single OSCController. The intent of the controller subsystem is to query available controllers in queryDevices() using whatever API is required to see what OSC endpoints are on the network and return that list there. That allows users to hit a 're-scan' button in the GUI which would call queryDevices() again to get an updated list. As well, there is supposed to be one OSCController instance per endpoint. Does OSC not fit this paradigm? — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2064 (review)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AhnMpK0hEs0KMYGKJcspq8JWy8FHfUhDks5vbAPpgaJpZM4cFmaZ).

daschuer · 2019-03-29T07:27:25Z

Do we agree to the following future implementation?

Mixxx should provide a mapping free OSC Server Socket for all ControlObjects with Mixxx addressing.
Mixxx should provide exactly one Client for responses on this socked, optimized for TouchOSC like servers also Mixxx addressing.
Via 2. It should be possible to subscribe to other sting or binary blob info. Using a subscription protocol (TouchOSC) and a config file.
We will provide additional Server and separated Client pairs to receive OSC command with any addressing. This can be parsed with JS only just like HID controllers?
Adopt the Midi Xml mapping file for OSC (or a future solution discussed) to allow point and click mappings

I think all this can be done one by one.
What do you think?

iffyloop · 2019-03-30T16:31:02Z

@daschuer I definitely agree on impementation ideas 1 & 2 above. I think 3-5 would be wonderful features to have but are probably too involved for me to implement given the amount of time I have right now. Am I correct in assuming that the other OSC support PR adds feature 2? If so, would it be best for me just to fork your daschuer/mixxx repository and try to build feature 1 into its osc_support branch?

daschuer · 2019-03-30T19:00:05Z

Great, it is reasonable to to it step by step so go ahead. Please just take the rout that suits best to you.

iffyloop · 2019-04-07T18:10:25Z

@daschuer I'm almost done with the new OSC server implementation that can exist alongside the existing OSC client we've been discussing. Since I built this into your fork of Mixxx that has the osc_support branch, would it be better for me to create a PR on your fork rather than this repository?

daschuer · 2019-04-07T20:06:34Z

If you are willing to take responds for all OSC branches, It is probably reasonable that you issue your own PR which includes @jakobbraun work. We can then close #2062 with a reference to your PR.

iffyloop · 2019-04-07T20:57:16Z

But for which repo should I issue the PR? mixxxdj/mixxx or daschuer/mixxx or jakobbraun/mixxx? -------- Original Message --------

…

On Apr 7, 2019, 3:06 PM, Daniel Schürmann wrote: If you are willing to take responds for all OSC branches, It is probably reasonable that you issue your own PR which includes ***@***.***(https://github.com/jakobbraun) work. We can then close [#2062](#2062) with a reference to your PR. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2064 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AhnMpAIf1njXCmlGLLu5xSbI7Rxjf4g-ks5vek_OgaJpZM4cFmaZ).

daschuer · 2019-04-07T20:57:54Z

mixxxdj/mixxx

iffyloop · 2019-04-08T03:52:13Z

Thanks @daschuer. I've created a new PR #2078. Do you want to keep this (#2064) PR or should we delete it?

github-actions · 2020-10-20T00:21:40Z

This PR is marked as stale because it has been open 90 days with no activity.

OSC support via oscpkt

f6202c9

Refactor with liblo

f06ed5f

iffyloop changed the title ~~[WIP] OSC support via oscpkt~~ [WIP] OSC support via liblo Mar 26, 2019

Pegasus-RPG requested changes Mar 27, 2019

View reviewed changes

iffyloop mentioned this pull request Apr 8, 2019

OSC Server/Client Integration #2078

Closed

github-actions bot added the stale Stale issues that haven't been updated for a long time. label Oct 20, 2020

Be-ing changed the base branch from master to main October 23, 2020 23:27

ronso0 marked this pull request as draft February 14, 2021 21:56

iffyloop closed this by deleting the head repository Sep 12, 2022

[WIP] OSC support via liblo #2064

[WIP] OSC support via liblo #2064

Conversation

iffyloop commented Mar 24, 2019

iffyloop commented Mar 24, 2019

iffyloop commented Mar 24, 2019

harryhaaren commented Mar 24, 2019

harryhaaren commented Mar 24, 2019

daschuer commented Mar 25, 2019

daschuer commented Mar 25, 2019

daschuer commented Mar 25, 2019

iffyloop commented Mar 25, 2019

daschuer commented Mar 26, 2019

daschuer commented Mar 26, 2019

iffyloop commented Mar 26, 2019

iffyloop commented Mar 26, 2019 via email

iffyloop commented Mar 26, 2019 via email

daschuer commented Mar 26, 2019

iffyloop commented Mar 26, 2019 via email

daschuer commented Mar 27, 2019

daschuer commented Mar 27, 2019

daschuer commented Mar 27, 2019

iffyloop commented Mar 27, 2019

daschuer commented Mar 27, 2019

Pegasus-RPG left a comment • edited Loading

Choose a reason for hiding this comment

Pegasus-RPG Mar 27, 2019

Choose a reason for hiding this comment

Pegasus-RPG Mar 27, 2019

Choose a reason for hiding this comment

Pegasus-RPG Mar 27, 2019

Choose a reason for hiding this comment

Pegasus-RPG Mar 27, 2019

Choose a reason for hiding this comment

iffyloop commented Mar 28, 2019 via email

iffyloop commented Mar 28, 2019 via email

daschuer commented Mar 29, 2019

iffyloop commented Mar 30, 2019

daschuer commented Mar 30, 2019

iffyloop commented Apr 7, 2019

daschuer commented Apr 7, 2019

iffyloop commented Apr 7, 2019 via email

daschuer commented Apr 7, 2019

iffyloop commented Apr 8, 2019

github-actions bot commented Oct 20, 2020

Pegasus-RPG left a comment •

edited

Loading