Re: [FFADO-devel] MIDI Controller and Qt C++ Mixer Progress

[Patrick N. <pat...@gm...>]

On Fri, Mar 9, 2012 at 10:12 PM, Jonathan Woithe <jw...@ju...> wrote:

> Hi Patrick
>
>
>  > 2. In porting the mixer functionality, I think I found some nifty ways
> to
> > minimize the code for each type of mixer.  I created a base class,
> > MixerWidget, that does the bulk of the work for connecting controls to
> the
> > D-BUS device. ...
>
> As far as I understand it this seems perfectly reasonable (it's worth
> noting
> at this point that I have only a superficial knowledge of Qt at this stage:
> enough to get the basics done, but not much beyond that).  It sound
> conceptually similar to what I've done in the RME mixer to minimise the
> work
> required for each control.
>
> > Aside from setup to potentially hide some controls for certain devices,
> > that's about it for each mixer subclass.
>
> This deals with the dbus side of things I assume.  There's still a need to
> set up the actual display widgets for each control.  When it comes to
> device
> control, "discrete" dbus controls can map to any number of widget types
> depending on the nature of the parameter being controlled.
>
>
It connects the widgets to the d-bus control.  Whether the control is a
matrix or discrete type, I check what the UI control type is, both when
connecting the widget to d-bus and when the widget changes.  In the slot
connected to QSignalMapper's "mapped" signal, I just get a QObject pointer
(the mapped object).  The MatrixControlElement and DiscreteControlElement
both subclass QObject (I've since reduced these to one class,
ControlElement) -- these are the mapped objects.  I cast the QObject
pointer to a ControlElement, and figure out what ControlType is represented
(Slider, Button, SpinBox, or ComboBox).  Then in the slot, I get the widget
pointer through QSignalMapper::mapping, and cast the widget pointer to the
appropriate widget type, and set the value on the device (via d-bus)
accordingly.

All this happens in the MixerWidget base class, so in the subclass, all you
have to do is call connectMatrixControl or connectDiscreteControl.  Of
course, the UI also has to be designed, but I just used the motu.ui as-is.
 But there is no further setup for the display widgets (aside from changing
some of the controls for device-specific needs, like hiding unused
controls, or adding the "Main Out" and "AES/EBU" selections to the
mix/phones destinations for the 896HD).

I'm not sure if you're saying that I'm missing something else, or if the
above (kind of) covers what you're referring to.


> > 3. I had some problems using the XML file that defines the D-BUS
> > interfaces.  I got qdbusxml2cpp to work, but it created the same class
> name
> > for each interface in the XML file.  I had to manually change these in
> > FfadoDbusInterface.h/cpp (the files generated from qdbusxml2cpp).  I'm
> not
> > sure if this is a limitation of qdbusxml2cpp, or if the D-BUS spec
> requires
> > each interface to be in a separate file.  I can look into this further if
> > it matters to anyone.
>
> If our xml file is in error for some reason it would be good to fix this.
> So
> in that respect it matters to me. :-)  If the difficulties with
> qdbusxml2cpp
> are caused by issues in our xml file, fixing the xml file is obviously far
> better from a maintenance point of view compared to having to manually hack
> the result of qdbusxml2cpp every time it's run.  This of course all takes
> time though, so I can understand if this is of peripheral interest to you
> right now.
>
>
Okay, I'll dig a little further, but not right away.  Now that I have the
d-bus adapter class, I don't need to run qdbusxml2cpp any more.  If you
were starting a new Qt project to use the d-bus interface, that is when it
would become an issue.


>    > I obviously have a long way to go in terms of porting the mixer
> stuff.  I
> > didn't do the registration screen yet, reading the config files, or
> > automatically updating the controls based on the device type (e.g. there
> > are variants within MOTU where some of the available controls aren't
> used).
> > And I only have the MOTU mixer ported over.
>
> There's a *lot* of code to port, that's for sure.  It's a pity in a way
> that
> you have to re-implement all this stuff rather than just build on what we
> already have.  To that end it would be good to determine whether your
> ffado-mixer problems are inherent in ffado-mixer or caused by some local
> issue.  Having said that, having a second independent mixer implementation
> can't be a bad thing either.
>
>
I am hoping I can have an attempt at porting some of the other devices, but
I don't have any of them, so I couldn't test them.  But I would think
others out there may want to use a MIDI controller for their device.

I'll look further into the problems with the python mixer.  It's on my
laptop, which uses the default video driver that comes with Fedora (can't
recall the vendor now).  It did work in the past (2-3 years ago), but now,
just starting ffado-mixer causes xruns (if I start jackd before
ffado-mixer), as well as moving any controls (if I start ffado-mixer before
jackd).  If I'm just working in ardour (no ffado-mixer running), then I get
no xruns.  I'm using the real-time kernel of Planet CCRMA.

But really, I'm not sure what to look for.  My version of the mixer in C++
does essentially the same thing the python mixer does.  All I can think is
that it's something in the bowels of python.  Perhaps it's a CPU loading
issue, with python being interpreted?  But I'm not sure why it would have
worked in the past.


> > If this approach isn't too objectionable, then I'd like permission to add
> > it to the subversion repository, and I can continue updating within the
> > repo.  Of course, others can help then, too, if there is interest.
>
> I don't have a fundamental problem with this going in the repo.  Do you
> have
> commit rights (I can't recall)?  If not, please contact me off-list about
> setting this up.
>
> Before committing though we need to agree on a sensible name for this
> development.  I would be interested in hearing your thoughts.  Regardless
> of
> what it would be called, its toplevel directory would live under support/.
>

I'm calling it ffado-midi-router now, but I'm not in love with that name.
 ffado-midi-mixer was another idea.  I'd like to hear any suggestions
others have.


>
> I can't speak for any of the other developers at the moment, but I
> personally do not currently have time to keep two mixer implementations up
> to date.  Since ffado-mixer is feature-complete in so far as it goes at
> present, in my mind this will have to continue to be the "reference" mixer
> for ffado.  We can re-evaluate this when this new implementation catches up
> with the old.  When time allows I may contribute to the new, but at the
> moment I'm pretty well occupied doing lower-level driver work.
>

Understood.  I'm hoping I can do the bulk of the porting, but other stuff
often takes precedence (like having our first baby on the way).

Regards,
Patrick