[PD-dev] outlet_anything() & threads

[Hans-Christoph Steiner]

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