[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] HID update (and forward to 3.7)



Hiho,

On Sat, 23 Nov 2013 17:47:06 +0100
Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:
> On 13.11.2013, at 10:48, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
> 
> > 
> > On 13 Nov 2013, at 08:30, Marije Baalman <nescivi@xxxxxxxxx> wrote:
> > 
> >> - HIDFunc, the scheme is clear now, happy to share the design
> >> concept, that we worked out in Bergen; there are anyways some
> >> things which are not entirely clear to me yet about the *Matcher
> >> and argTemplate concepts (Scott, maybe you want to help out here?)
> > 
> > Yes, happy to talk about this! We can do it offlist if you like.
> 
> Hi Marije and Scott,
> 
> as you posted the link to the repository, I had a quick look, so just
> a general architectural comment. I think that the current
> implementation has a potential duplication - you have HIDDevice and
> HIDFunc. I am not sure if they are needed.

HIDDevice was renamed to HID, and that class is needed, as it provides
all the lowlevel functionality, and all the elements and such link in
to that.

You do want explicit control over HID devices, as you might want to
open and close them.
I do prefer to keep information about the devices in separate classes,
to avoid the over-use of dictionaries.
 
> In the case of OSC messages, for instance, there is just one single
> extendible function (or list of functions) that responds and all the
> rest is done by the OSCFunc, which responds to the appropriate
> parameter combinations.

It's a different thing, to my feeling, given that there is an explicit
link to a physical device and its controls.

Perhaps, once I've created a suitable implementation of HIDFunc (it's
not there yet; what you see is a dummy where only the .trace method
works), I might feel different, but currently I feel that the
old-fashioned implementation is still needed.


sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/