On May 17, 2006, at 3:22 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
(i mean: use [hid]->[t a a] and not [t b b]=>[hid]->[hid])
Actually, this is how [hid] currently works and it causes problems. The
could you please elaborate on the problems it causes? i still think that using [hid]->[t a a] is way cleaner than [t b b] =>[hid]->[hid]
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.
why? the problem i see is not whether the 2 [hid] objects output the same data or not. it is rather, whether i want to use the same data twice or whether i want to acquire the same data twice. these are different concepts! if i want to use the same data twice then the 2 datasets must be identical. if i want to acquire the same data twice, than i have to do the data acquisition 2 times (it doesn't say anything about the identity of the datasets).
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.
now whether the data fetching takes some time or not is an implementation detail of the object (and it is nice if one object is especially efficient). but imho, we should always have in mind that objects do need some time to react on input.
furthermore i think that (c-)objects should implement atomic functionality. acquiring data is (kind of :-)) atomic. distributing data is atomic. i see no reason for an object for acquiring AND distributing data. (i am oh-so-glad that [netreceive] doesn't distribute the data anymore)
Sounds good to me.
aim in Pd is to have everything appear as if it was running at the same logical time. Therefore every instance of [hid 0] should output the exact same data. Otherwise it breaks this paradigm and strange behavior will ensue.
i think this is your personal interpretation of the data-flow in pd. another interpretation could be that [object]s do "their work" (but i am repeating myself). pd's expressivity (what a word...) is strong enough to allow both views to be valid.
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.
HID on Win32 is bad news and will never be really usable for good instrument design IMHO. So I don't seriously consider it. Instead, the
cannot add anything.
are currently evaluating linux without hid-support since it is known to block the kernel for up to 0.5ms every now and then)
Do you have any documentation of this? You have to admit, you guys have
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.
very specific needs. I don't know much about that stuff.
i think this is really one of the main problems: we guys don't have any specific needs! if it were so, then we would still be the only ones with a hammerfall card; or using pd (apart from miller of course); or...
why do i always think that you regard "academic uses" of pd (like boring maths) to be 2nd class to expressice music making? why can't they be equals?
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).
For instrument design 0.5ms is not significant, as long as there is no
you misunderstood me. 0.5ms latency is not a real issue (that is pretty damn low!); however, blocking the system for 0.5ms IS an issue.
click. To put things into perspective, given a speed of sound of 350 m/s (at roughly 20 C), it takes the sound from an acoustic guitar you are playing 1.5ms to get to your ear (0.5 m). If you are playing with an amp that's 3m away, there is a ~9ms delay before you hear the sound.
i hear you; i am not talking about acoustic guitars here (which actively produce sound and thus provide feedback to the player); i am not talking about scientific uses too; i am talking about such simple things as using windcontrollers controlling a hardware- synthesizer being send through 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 was that running [hid] polling at 1.5ms makes for lots of opportunities for the OS to block [hid]. And yet it doesn't, in my tests.
Try it out. Seriously, show me a patch where [hid] causes clicks, and we can take it from there.
should i send my machine too :-)
i remember the days when the only answer to an un-usable [hid] was: "works with the brandnew 2.4.X kernel" (while we were at least at 2.6.8)
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.
what i am trying to say here is, that you might well have found your perfect combination of hw and sw, but mine might be different (well, i am specific...) and others might be too)
Are you saying that [hid] causes clicks on your machine? I use a 800 Mhz laptop, so a patch that clicks on your machine will be very likely to click on mine. I am serious, please send me an example patch where [hid] causes clicks. Please submit a bug report. I've gotten lots of bug reports, but clickiness is not one of them. That doesn't mean I won't believe when I hear it, but rather I haven't heard it yet.
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste