[PD-dev] outlet_anything() & threads

IOhannes m zmoelnig zmoelnig at iem.at
Wed May 17 15:22:39 CEST 2006


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





More information about the Pd-dev mailing list