On May 16, 2006, at 12:17 PM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am about to start working on the [hid] v2 stuff, and I just had
a thought. Is there any way to find out which instance of an
object executes first?My idea is to have the first instance of the [hid] object do the
reading of event data from the OS and write it to memory. Then
every other instance will just output the data from memory. But
in order for this to work properly, the first instance to execute
needs to do the data-getting.There was a thread about singletons a while ago, which resulted in
the singleton.pd that is used in [sssad].but isn't this something different? i think, hans's problem is with
execution-order at run-time and not with creation order at load-time.
yes indeed. Also, I was thinking in C space, but maybe I should be
thinking in Pd space.
hans: what is wrong with threads here? i do think that threads is the way
to go when interfacing objects that might block the main thread
(and i am pretty sure that using libusb is prone to blocking)
In the case where the OS is already buffering, like HID, and perhaps
USB, then you can just read from that buffer as long as there is data
and the time slice isn't over. That's how [hid] currently works.
a thread-less solution would be to get the difference of _logical_
time since the last "bang" of the object and do the data-retrieval
only if this time is >0 (or better: !=0)
Hmm, that's easy. Perhaps I should do this in Pd space. But that
leads me to a question: if I change the block size of a patch with
[switch~], does that change how often the messages are processed? So
if I want to have really low latency message processing, could I do
[switch~ 16]? Linux can get mouse events every 1 ms when tuned
properly.
Is this going to take a lot more CPU time that C? I'd like to do it
in Pd, but [hid] can already use quite a bit of CPU at low latency
(1-5 ms).
.hc
http://at.or.at/hans/