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

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

On 24 Nov 2013, at 00:17, Marije Baalman <nescivi@xxxxxxxxx> wrote:

> Hiho,
> On Sat, 23 Nov 2013 22:37:42 +0100
> Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:
>>>> It's a different thing, to my feeling, given that there is an
>>>> explicit link to a physical device and its controls.
>>> Well this can also be true of OSC and MIDI devices.
>>> For OSC devices, I thought it made sense to build classes on top of
>>> lower level send (NetAddr) and receive (OSCFunc) stuff. Not sure if
>>> that makes as much sense with HID. Hmm…
>> Hm, yes, this was just a guess, I just ask because it is very
>> seductive in OOP to represent things as objects, but not always the
>> bets model. I agree that in OSC communication you have similar
>> structures and there are also HID devices that send OSC.
> ok - I limit the notion of HID device now by devices that use the HID
> standard, typically USB devices that adhere to the USB HID
> specification.
> And in that sense there is a clear difference - in the primitives I
> have to explicitly open a device node which represents the computer's
> connection to the device (user kernel space), whereas with OSC and MIDI
> I have a general port the language opens up on which messages come in,
> regardless of where they came from (they can be from multiple devices
> or other programs; in case of MIDI not so obvious on OSX, but on Linux
> multiple MIDI sources can be connected to SuperCollider's MIDI port).
>> The question is whether any state of the device needs to be
>> represented as object state (like sc server), or whether it is enough
>> to receive status change messages and do any bookkeeping yourself if
>> needed. If it is more like the server, then indeed the HIDDevice may
>> be the best way to go.
> well, the bookkeeping is done in the library in any case, it is just a
> matter of querying it to make it available to the language.
> I guess the question then would be, whether it is more efficient to do
> the filtering in sclang, or look for specific things through primitives.
> Given that I already have the implementation for just filling up the
> elements that are there in sclang, it seems to me that is more
> efficient, and will also allow more developers to work on the code
> (given the limited amount of people that we have that actually dive
> into the C++ code).

Overall I think it's not really a huge deal. Thinking about it, with MIDI/OSC, we end up with something that looks like this:

low level hook
User-friendly hooks
Higher level wrapper classes for specific devices

With HID, IIUC, we have HIDDevice in there at the low end. 
>> For now the main thing is that under the hood everything works, so
>> the responder issue is not such an important thing yet.
> yep.
Yes, the low level device objects are fine if they make sense, and especially okay if they're part of the 'private' implementation. MIDI/OSC have lots of things that are not part of the public interface (e.g. the matcher classes), which are there for efficiency, but could easily be replaced with a different implementation. With the right interface the back end can be adjusted later for greater efficiency. MIDI/OSCFunc went through a few iterations.

IAC, thanks for finally sorting out this longstanding issue!

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/