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]
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).
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)
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] !!
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)
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?
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...
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) 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)
never mind. fmga.dsr. IOhannes