[Ardour-Dev] Introducing support for ShuttlePRO v2

Johannes Mueller github at johannes-mueller.org
Mon May 29 05:40:42 PDT 2017


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


Paul Davis wrote:
> ::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 <
> 
> github at johannes-mueller.org> wrote:
> > 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
> > ardour-dev at lists.ardour.org
> > http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org


-- 
https://github.com/johannes-mueller/


More information about the Ardour-Dev mailing list