[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] HID update (and forward to 3.7)
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).
> For now the main thing is that under the hood everything works, so
> the responder issue is not such an important thing yet.
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml