JNAJack: adding JACK Transport support

[Matthew MacLeod]

Hi Neil,

First, thanks so much for creating JNAJack and making it available!  It works very well and provides almost everything I need.

For my purposes, the only thing missing was JACK Transport support, so I forked the repo and added the necessary code.  The work is pretty much done and seems pretty solid, although it still needs a little more testing.  If you're interested in rolling it into the official repo, I'll submit a pull request when I'm done. 

Cheers,
Matthew

[Neil C Smith]

Hi Matthew,

On Mon, Aug 7, 2017 at 11:20 AM Matthew MacLeod <mgmac...@gmail.com> wrote:

First, thanks so much for creating JNAJack and making it available!  It works very well and provides almost everything I need.

Thanks for the kind words - glad it's working well for you.  Out of interest, what are you using it for?

 

For my purposes, the only thing missing was JACK Transport support, so I forked the repo and added the necessary code.  The work is pretty much done and seems pretty solid, although it still needs a little more testing.  If you're interested in rolling it into the official repo, I'll submit a pull request when I'm done. 

Definitely!  Please do.   JNAJack hasn't seen much work until recently, when I pushed a release to Maven Central [*].  It would be great to get a pull request to get this into the next release there - I've been meaning to look at transport for a long time and not got around to it.

[*] it was a good project to get my head around Maven Central prior to pushing the GStreamer 1.x bindings - as GStreamer can output via JACK ironically that means I'm now maintaining two different ways you can interact with JACK from Java! ;-)

Best wishes,

Neil

--

Neil C Smith

Artist & Technologist

www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[Matt MacLeod]

Hi Neil,

Thanks for your quick reply.

On Mon, Aug 7, 2017 at 6:45 AM, Neil C Smith <ne...@neilcsmith.net> wrote:

Hi Matthew,

On Mon, Aug 7, 2017 at 11:20 AM Matthew MacLeod <mgmac...@gmail.com> wrote:

First, thanks so much for creating JNAJack and making it available!  It works very well and provides almost everything I need.

Thanks for the kind words - glad it's working well for you.  Out of interest, what are you using it for?

 

I'm working on a performance front-end for SuperCollider focusing on control via MIDI devices and I want to have the ability to sync with other JACK apps (hence transport).  My motivation is partly to see if I can get *exactly* the features I want (demanding bastard that I am) and partly as a personal coding challenge to stretch my (and if I can contribute back to other free software projects in the process, so much the better). 
 

For my purposes, the only thing missing was JACK Transport support, so I forked the repo and added the necessary code.  The work is pretty much done and seems pretty solid, although it still needs a little more testing.  If you're interested in rolling it into the official repo, I'll submit a pull request when I'm done. 

Definitely!  Please do.   JNAJack hasn't seen much work until recently, when I pushed a release to Maven Central [*].  It would be great to get a pull request to get this into the next release there - I've been meaning to look at transport for a long time and not got around to it.

Excellent.  Will do.  I just realized that I missed a few things, so I'll fix that up today (hopefully).  I'm also a little confused about the handling of the native jack_nframes_t type; sometimes it's just mapped to a Java int, and other times it's converted to a Java long.  My understanding is that it should always be converted to a long, although the int mapping seems to work.  Thoughts?

Thanks,

Matthew

[Neil C Smith]

Hi,

On Mon, Aug 7, 2017 at 9:40 PM Matt MacLeod <mgmac...@gmail.com> wrote:

I'm working on a performance front-end for SuperCollider focusing on control via MIDI devices and I want to have the ability to sync with other JACK apps (hence transport).  My motivation is partly to see if I can get *exactly* the features I want (demanding bastard that I am) and partly as a personal coding challenge to stretch my (and if I can contribute back to other free software projects in the process, so much the better). 

Sounds interesting! Not really played around with SuperCollider (I'm more of a Java audio coder) but I look forward to hopefully seeing this.

Excellent.  Will do.  I just realized that I missed a few things, so I'll fix that up today (hopefully).  I'm also a little confused about the handling of the native jack_nframes_t type; sometimes it's just mapped to a Java int, and other times it's converted to a Java long.  My understanding is that it should always be converted to a long, although the int mapping seems to work.  Thoughts?

Welcome to the joy of JNA coding! ;-)  You need to consider the difference between size (32-bit vs 64-bit) and range.  On the JACK side it's an unsigned 32-bit int, therefore in low-level JNA mappings it should always be mapped as a 32-bit Java int - the bit size is important.   Of course, because Java's int is signed, in certain cases larger values (above Integer.MAX_VALUE) will go out of range and become negative. In those cases the public-facing API should convert the signed 32bit value to an unsigned one, which can only be stored in a 64-bit Java long - this is what the NativeToJavaTypeConverter code does.  It only makes sense to do that where the values might actually go out of range.  Buffer sizes, sample rates, etc. should never be anywhere near Integer.MAX_VALUE!  If you see a case where a value that could conceivably wrap isn't converted, file an issue.

Hope that helps.

Best wishes,

Neil

[Matt MacLeod]

Hi Neil,

On Tue, Aug 8, 2017 at 6:55 AM, Neil C Smith <ne...@neilcsmith.net> wrote:

Sounds interesting! Not really played around with SuperCollider (I'm more of a Java audio coder) but I look forward to hopefully seeing this.

I hope so too! I've been starting and stopping a lot over the past few months, trying to decide if I want to spend the time trying to develop something new, or just pick a set of tools and figure out a 'good enough' workflow.  In a way, it would be better if I didn't know how to code, as then there'd be no other choice ;)

Welcome to the joy of JNA coding! ;-)  You need to consider the difference between size (32-bit vs 64-bit) and range.  On the JACK side it's an unsigned 32-bit int, therefore in low-level JNA mappings it should always be mapped as a 32-bit Java int - the bit size is important.   Of course, because Java's int is signed, in certain cases larger values (above Integer.MAX_VALUE) will go out of range and become negative. In those cases the public-facing API should convert the signed 32bit value to an unsigned one, which can only be stored in a 64-bit Java long - this is what the NativeToJavaTypeConverter code does.  It only makes sense to do that where the values might actually go out of range.  Buffer sizes, sample rates, etc. should never be anywhere near Integer.MAX_VALUE!  If you see a case where a value that could conceivably wrap isn't converted, file an issue.

Indeed! This is my first foray into this stuff.  It's been fun for the most part.  But yes, that does clarify things.  So with that, I think the transport stuff is good to go.  There are a few stylistic / organizational questions, but I'll leave those for GitHub.  

Thanks again for all your help. 

I'm off to submit my first ever pull request!  I'll try not to screw it up ;)

Cheers,

Matthew