[Ardour-Dev] Introducing support for ShuttlePRO v2

[Johannes Mueller]

Hello,

I am working on a control surface to support the ShttlePRO v2 device [1] on
Linux. The device is working well using the input event struct of linux/
inputs.h.

By now the handling of the events is hard coded and doing things that make
sense to my work-flows. However I'd like to make it user configurable
although I am not sure how to do it exactly (how to configure things that are
not actions, for example).

But to begin with I have a question regarding the ControlProtocol API: What's
the deal with void AbstractUI<RequestObject>::do_request(RequestObject*)? I
had to implement it to make my class instantiatable, so I just copied the
code from OSC::do_request() without actually knowing what it means. Can
someone give me a hint, please?

You can take a glimpse on the code on
https://github.com/Ardour/ardour/compare/master...johannes-mueller:shuttlepro

Any other hints welcome.

Thanks

Johannes

_________
[1]: http://www.contourdesign.com/UK/product/shuttlepro-v2/

[Paul Davis]

::do_request() is a mechanism for cross-thread signalling. It should
probably not be used explicitly in any control surface code. It allows one
thread to arrange for another thread to do something (possibly to stop
running, or execute some closure, or whatever ...)

There are no abstractions except actions that can be used for
configurability at this time. What would be an example of the sort of thing
you want to make configurable?

On Mon, May 29, 2017 at 7:55 AM, Johannes Mueller <

Post by Johannes Mueller
Hello,
I am working on a control surface to support the ShttlePRO v2 device [1] on
Linux. The device is working well using the input event struct of linux/
inputs.h.
By now the handling of the events is hard coded and doing things that make
sense to my work-flows. However I'd like to make it user configurable
although I am not sure how to do it exactly (how to configure things that are
not actions, for example).
But to begin with I have a question regarding the ControlProtocol API: What's
the deal with void AbstractUI<RequestObject>::do_request(RequestObject*)? I
had to implement it to make my class instantiatable, so I just copied the
code from OSC::do_request() without actually knowing what it means. Can
someone give me a hint, please?
You can take a glimpse on the code on
https://github.com/Ardour/ardour/compare/master...
johannes-mueller:shuttlepro
Any other hints welcome.
Thanks
Johannes
_________
[1]: http://www.contourdesign.com/UK/product/shuttlepro-v2/
--
https://github.com/johannes-mueller/
_______________________________________________
ardour-dev mailing list
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Johannes Mueller]

Hello Paul,

I introduced BasicUI::jump_by_beats () in order to use the jog wheel to jump
beat wise (or maybe according to user config by 0.5 beats or even 0.25). Other
users might prefer to jump_by_seconds ().

Then I mapped one button to jump_by_bars (-4.0), because that's a very common
use case for me. Like

* recording something
* playing/singing a mistake
* hit the buttons for
transport_stop, remove_last_capture, prev_marker, jump_by_bars(-4.0)
* record next try

The part I am actually recording is at prev_marker and I need usually four
bars to listen in before starting to play/sing. That's the use case that
actually made me start coding, so that should be possible by all means.

Another thing is, that I want to use the shuttle to set_transport_speed ().
Maybe that could even remain hard coded.


Regarding the cross-thread signaling. Is it ok _not_ to supply a
request_buffer_factory in the ControlProtocolDescriptor?

During my tests I've never seen that ::do_request() got actually called. So is
it ok to just leave it blank or should it like the OSC surface does like:

'''
void
ShuttleproControlProtocol::do_request (ShuttleproControlUIRequest* req)
{
if (req->type == CallSlot) {
call_slot (MISSING_INVALIDATOR, req->the_slot);
} else if (req->type == Quit) {
stop ();
}
}
'''

The CallSlot case doesn't seem to make sense to me, because I don't have any
slot that another thread might want me to call, do I?

Is it imaginable that another thread will request me to Quit?

Thanks for your help

Johannes

Post by Paul Davis
::do_request() is a mechanism for cross-thread signalling. It should
probably not be used explicitly in any control surface code. It allows one
thread to arrange for another thread to do something (possibly to stop
running, or execute some closure, or whatever ...)
There are no abstractions except actions that can be used for
configurability at this time. What would be an example of the sort of thing
you want to make configurable?
On Mon, May 29, 2017 at 7:55 AM, Johannes Mueller <

Post by Johannes Mueller
Hello,
I am working on a control surface to support the ShttlePRO v2 device [1] on
Linux. The device is working well using the input event struct of linux/
inputs.h.
By now the handling of the events is hard coded and doing things that make
sense to my work-flows. However I'd like to make it user configurable
although I am not sure how to do it exactly (how to configure things that are
not actions, for example).
But to begin with I have a question regarding the ControlProtocol API: What's
the deal with void AbstractUI<RequestObject>::do_request(RequestObject*)? I
had to implement it to make my class instantiatable, so I just copied the
code from OSC::do_request() without actually knowing what it means. Can
someone give me a hint, please?
You can take a glimpse on the code on
https://github.com/Ardour/ardour/compare/master...
johannes-mueller:shuttlepro
Any other hints welcome.
Thanks
Johannes
_________
[1]: http://www.contourdesign.com/UK/product/shuttlepro-v2/
--
https://github.com/johannes-mueller/
_______________________________________________
ardour-dev mailing list
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Len Ovens]

Post by Johannes Mueller
Another thing is, that I want to use the shuttle to set_transport_speed ().
Maybe that could even remain hard coded.

Shuttle is easy, look at the jog code in OSC if you like.

Post by Johannes Mueller
'''
void
ShuttleproControlProtocol::do_request (ShuttleproControlUIRequest* req)
{
if (req->type == CallSlot) {
call_slot (MISSING_INVALIDATOR, req->the_slot);
} else if (req->type == Quit) {
stop ();
}
}
'''
The CallSlot case doesn't seem to make sense to me, because I don't have any
slot that another thread might want me to call, do I?
Is it imaginable that another thread will request me to Quit?

Yes. Two possibilities I can think of right now:
- application shutdown
- set your control surface to not enabled with:
preferences->control surfaces->Shuttle-Pro

--
Len Ovens
www.ovenwerks.net

[Len Ovens]

Post by Johannes Mueller
Hello,
I am working on a control surface to support the ShttlePRO v2 device [1] on
Linux. The device is working well using the input event struct of linux/
inputs.h.

The shuttle pro is a nice controller. However, using linux/inputs limits
it to linux use and would not be able to be merged with the rest of the
code. I would suggest looking at the fp8 and other controlers using USB
directly. This would allow the code to be used with windows or MacOS.

Post by Johannes Mueller
By now the handling of the events is hard coded and doing things that make
sense to my work-flows. However I'd like to make it user configurable
although I am not sure how to do it exactly (how to configure things that are
not actions, for example).

This is not hard, but not easy to give an overall answer to either. Things
are broken down into 3 kinds of things, actions which you already know
about, session controls (global things like transport) and stripable
controls which are per track/bus/vca. Look in session.h and stripable.h
for an idea.


--
Len Ovens
www.ovenwerks.net

[Johannes Mueller]

Hi Len,

Post by Len Ovens

I am working on a control surface to support the ShuttlePRO v2 device [1]
on Linux. The device is working well using the input event struct of
linux/inputs.h.

The shuttle pro is a nice controller. However, using linux/inputs limits
it to linux use and would not be able to be merged with the rest of the
code. I would suggest looking at the fp8 and other controlers using USB
directly. This would allow the code to be used with windows or MacOS.

Point taken. I changed the code now to use libusb instead of linux/inputs. It
took me some time to figure out how to do it, but hey, it was fun and I
learned something. It's working even better than before, because linux/inputs
strangely does not pass all the events from the wheel properly. I thought that
the ShuttlePRO itself was the culprit.

Post by Len Ovens

By now the handling of the events is hard coded and doing things that make
sense to my work-flows. However I'd like to make it user configurable
although I am not sure how to do it exactly (how to configure things that
are not actions, for example).

This is not hard, but not easy to give an overall answer to either. Things
are broken down into 3 kinds of things, actions which you already know
about, session controls (global things like transport) and stripable
controls which are per track/bus/vca. Look in session.h and stripable.h
for an idea.

Thanks for your advice. I will look into it and will find a way on how to
improve this. At first I need to do some testing using it for my current real
life music project.

Johannes

[Johannes Mueller]

Post by Johannes Mueller
I am working on a control surface to support the ShttlePRO v2 device

The surface with a configuration gui is now functional – functional as in
"works for me". I would like some other users to test especially
on non-Linux systems. It uses libusb (just like the Ableton Push2
surface), so it should be portable also to Windows and Mac.

So to all of you who have access to ShuttlePRO v2: tests highly appreciated.

One pitfall right to the beginning. On Linux you will probably lack the
permissions needed for Ardour to access the device. So you will first need to
apply the folliwing udev rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0030", MODE="660", GROUP="users"

assuming that your user is in the group "user".

Happy testing, I am welcoming any kind of feedback.

The sourcecode is accessible via github here:
https://github.com/johannes-mueller/ardour/tree/shuttlepro


Thanks for your support

[Brett McCoy]

I have a ShuttleXpress, do you think it will work using the same libraries?

On Thu, Jun 29, 2017 at 12:43 PM Johannes Mueller <

Post by Johannes Mueller
I am working on a control surface to support the ShttlePRO v2 device

The surface with a configuration gui is now functional – functional as in
"works for me". I would like some other users to test especially
on non-Linux systems. It uses libusb (just like the Ableton Push2
surface), so it should be portable also to Windows and Mac.
So to all of you who have access to ShuttlePRO v2: tests highly appreciated.
One pitfall right to the beginning. On Linux you will probably lack the
permissions needed for Ardour to access the device. So you will first need to
apply the folliwing udev rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0030",
MODE="660", GROUP="users"
assuming that your user is in the group "user".
Happy testing, I am welcoming any kind of feedback.
https://github.com/johannes-mueller/ardour/tree/shuttlepro
Thanks for your support
--
https://github.com/johannes-mueller/
_______________________________________________
ardour-dev mailing list
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Johannes Mueller]

Post by Brett McCoy
I have a ShuttleXpress, do you think it will work using the same libraries?

Possibly. If we are lucky The ShuttleXpress is just a ShuttlePRO with less
buttons. it won't work directly with the current code though, because the
product ID is now hard coded and matches the one of the ShuttlePRO. You could
however in libs/surfaces/shuttlepro/shuttlepro.cc change the product ID to the
one of the shuttleXpress and just try and see what happens.

Probably it would be a good idea to make the surface try to discover if it
finds a ShuttlePRO or a ShuttleXpress. I will look into that.

Johannes

[Johannes Mueller]

Post by Johannes Mueller

Post by Brett McCoy
I have a ShuttleXpress, do you think it will work using the same libraries?

[...]

Post by Johannes Mueller
Probably it would be a good idea to make the surface try to discover if it
finds a ShuttlePRO or a ShuttleXpress. I will look into that.

I just pushed a new version, that tries just that. If it does not find a
ShuttlePRO it tries to find an ShuttleXpress, assuming, that the ShuttleXpress
behaves just like a ShuttlePRO whose buttons 6-15 are never used.

So it should be also usable with the ShuttleXpress

The udev rule needs to be adjusted

SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020",
MODE="660", GROUP="users"

I appreciate any kind of feedback

Thx

Johannes

[Brett McCoy]

I will be back in my studio tomorrow (0n travel right now) and will
definitely test it out!

On Fri, Jun 30, 2017 at 5:25 PM Johannes Mueller <

Post by Johannes Mueller

Post by Johannes Mueller

Post by Brett McCoy
I have a ShuttleXpress, do you think it will work using the same libraries?

[...]

Post by Johannes Mueller
Probably it would be a good idea to make the surface try to discover if

it

Post by Johannes Mueller
finds a ShuttlePRO or a ShuttleXpress. I will look into that.

I just pushed a new version, that tries just that. If it does not find a
ShuttlePRO it tries to find an ShuttleXpress, assuming, that the ShuttleXpress
behaves just like a ShuttlePRO whose buttons 6-15 are never used.
So it should be also usable with the ShuttleXpress
The udev rule needs to be adjusted
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020",
MODE="660", GROUP="users"
I appreciate any kind of feedback
Thx
Johannes
--
https://github.com/johannes-mueller/
_______________________________________________
ardour-dev mailing list
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org