Hans-Christoph Steiner wrote:
Those trigger examples don't really make sense because you wouldn't do that in the real world. If [hid] allows multiple instances to access the same device, then the data needs to be the same. Here's an example of where it matters: what if you were doing a comparison of the data streams from two [hid 0] to test to see when a certain transform is active or not. If the data that comes out of each [hid 0] is different, the comparison totally break down.
do i misunderstand you in that the use-case is as follows:
[hid 0] | [scale on/off] <-- this is a modified which can be turned on/off | | [hid 0] | | [-] | [select 0] | [scale is turned off(
If you want to acquire the data twice, you send two bangs. But when two [hid 0] instances are banged at the same logical time, they should output the exact same data.
hmm, but what if the data has changed in the meantime? let's assume quantum-physics: querying data modifies the data.
imagine your joystick being twisted via the feedback-engine based on the current position of the stick and immediately queried again.
does the hid-api explicitely state that querying the data must not modify it? i know a lot of devices (non of them are hid, though) which reset their values each time they are queried.
couldn't this be an application of this very object too?
again: [hid]->[t a a] is not the same as [t b b]=>[hid]->[hid] !!
The fact that everything in Pd runs at the same logical time is a core concept of Pd and should not be dismissed. Your example of finding which instance executes first demonstrates that: the logical time in between the execution of each instance will be 0.
yes i am totally with you here. otoh, "same logical time" does not prohibit the internal state of an object to be changed.
no i don't...wini just mentioned it today (totally unrelated though); i will hask him when he reappears. (probably just a rumour: http://www.linux-club.de/ftopic31817.html)
Well, if the kernel HID stuff is causing you problems, the [hid] object is least of your worries.
true. but it seemed so fit...
You misunderstand me, I don't discount what IEM does at all. I generally think of the IEM sound cube when I am talking like this. As much we would like to have one, very few people in the world have a 24-speaker ambisonic setup to play with. You guys do stuff on a much grander scale than the vast majority of Pd users, who are stuck with 4 year old laptops (like me).
but a lot of "ordinary" Pd users have startet to use professional multichannel soundcards. (with 24 channels, even if they don't have the IEM CUBE at hand). what i am trying to express is, that gÃŒnther and wini had a hard time getting the modifications to the OSS driver model to support multi(!)channel into the kernel, because people (like you) insisted that "nobody but you special guys need a soundcard with 24 channels; we don't bother; go away" (note that i was not part of this story, so i might be completely wrong)
i am glad that the (OSS) hammerfall drivers made it into the kernel, they are still the drivers which allowed for the lowest latency i(!) achieved with vanilla pd.
I've run [hid] with a poll time of 1.5ms and got no clicks. In the realm of instrument design, that is very low latency. The HID API has its own
by the way, the polling interval is not the latency. my crappy shitty laptop-soundcard polls at 44.1kHz but still my latency is about 80ms...
While its true that polling != latency, that was not my point. My point
well, my problem is that often i cannot resist...
I am sorry I can't keep up with all three platforms. I do what I can. The code is there, anyone could have fixed it, esp. those of use using a 2.6 kernel on a daily basis.
well, i committed some changes...
Are you saying that [hid] causes clicks on your machine? I use a 800
no i don't.
mfg.adsr. IOhannes