[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:
> 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
> 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
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.
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