Re: [Jack-Devel] major change in jack1 MIDI handling

Hi Stéphane,

On Wed, Oct 16, 2013 at 2:58 AM, Stéphane Letz <[hidden]> wrote:

> I agree that the Driver class architecture is far from simple…
> "historical" reasons for the main part...

JACK 2 driver development, in general, is far from simple.  One way to
simplify driver development would be to have a well-defined driver
development API.  There are a lot of classes in the common directory
that have absolutely nothing to do with driver development; yet, when
I was hacking on JACK 2 MIDI drivers, I had to search through the
common directory every single time I wanted to use functionality
provided by the JACK 2 core.  The common directory is pretty
intimidating.

>> 4.) Speaking of returning -1 for non-realtime errors, I'm of the
>> opinion that throwing exceptions is a fantastic way to handle errors.
>
> Here this is a kind of legacy of the pure C approach, C++
> exception came after that, thus this "ugly" mix of the two
> approaches.

But now that you have the C++ approach, why not use it?  I know there
are places in the JACK 2 code that use exceptions, but they're fairly
limited.

(Obviously, I'm not advocating that exceptions be used in the realtime
parts of the code.)

>> 5.) I said before that there isn't one driver I've seen that
>> implements all three of the Open() functions.  Looking through the
>> Linux-specific drivers, I see that JACKAlsaDriver and
>> JackALSARawMidiDriver (I wrote that one) implement only one Open()
>> function each.  Here's a bit of a curve ball - JackFreebobDriver and
>> JackFFADODriver each define an Open function with a completely
>> different signature!
>
> Not my fault actually, I did not wrote this code….

I'm not blaming you.  I'm not blaming the FFADO/Freebob driver
developers.  What I am saying is that providing specific case Open()
methods for subclasses to call is likely not the best approach to this
problem because you don't always know the parameters that a subclass
needs for the Open() method.

I think the best way to solve this problem is to define an Open()
method with no parameters, and define pure virtual methods the Open()
method calls to do the things that Open() needs to do.  If any
information is required from outside the implementing subclass, then
that information can be passed to the subclass' constructor.

On a code style note (since I'm talking about Open() vs. open()), the
camel case function names are a total turn-off.  Every time I look at
a camel-case function name, there's something in the back of my head
that wonders if it's a class constructor call.

Thanks,

-- 
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/

1382121986.10831_0.ltw:2, <CAG7zqTr1oFHg5iGo0rKwg61pf4NWG_y+L2MN9nWC=3G-Bz89aA at mail dot gmail dot com>