hi all,
can anyone confirm that using outlet_anything() inside a thread is safe? just wrote a little object that reads a usb device in a thread, and send to the outlets from there directly via outlet_anything() .... so far it doesnt crash or anything, it just works (of course there are some objects connected to them), altough its only a few route's and slider/bangs/toggles connected.
since the thing does peak detection, there is a hell lot of toggles comming in, plus some faders ... so its really quite some traffic ....
but i want to make sure that i can do it that way, and not that there are any surprises later when doing that ...
thanks,
chris
Christian Klippel wrote:
hi all,
can anyone confirm that using outlet_anything() inside a thread is safe?
i am pretty sure this assumption is illegal. the problem will arise as soon as a "normal" object will receive messages from both threads. if you "guarantee" (e.g. leave it at the users discretion :-)) that no unprepared object will be involved in several threads, the i guess you are on the safe side (but maybe you are not) (see tim's [detach]/[join] objects)
generally however, i think you should do the synchronisation between several threads before using outlet_*()
mfg.ad.r IOhannes
hi iohannes,
Am Dienstag, 2. Mai 2006 12:47 schrieb IOhannes m zmoelnig:
Christian Klippel wrote:
hi all,
can anyone confirm that using outlet_anything() inside a thread is safe?
i am pretty sure this assumption is illegal. the problem will arise as soon as a "normal" object will receive messages from both threads. if you "guarantee" (e.g. leave it at the users discretion :-)) that no unprepared object will be involved in several threads, the i guess you are on the safe side (but maybe you are not) (see tim's [detach]/[join] objects)
what do you mean by "unprepared objects" ? other objects that use threads too? as for the actual code in question, it creates only one single thread to read from the usb bus, and send data to the outlets if anything arrives. there are no other threads created.... an there are no variables/memory that the thread shares with the rest of the external's code, except for sending to usb, which is synchronized ....
what im wondering is, how can one stress-test such a situation to see if it works just by accident now, or if it is reliable ....
so far i am feeding the received data through a [select 0 1 2] and another one through [select 0 1 2 3] (two outlets that send data from within the thread). the splitted streams (7) are then fed into [i] objects, faders and toggles. additionally i created some [metro 1] that bang the [i] and fader objects, to which normal numberboxes are connected ..... due to the many, fast running metro's i have a pretty high sysload, and surely there are messages sent almost always. but no crash, wrong data, or something.....
so im really wondering how that could work, if it isnt supposed to be safe to call outlet_anything from a (single) thread ....
and as tim said:
solution 3: use flext, since it's taking care of that ...
tim, since i know nothing about flext (yet), just a few quick question (maybe i asked that loong ago alread....): does it work on linux/os-x/win? i need all three ....
but i will look into it a bit deeper anyway, thanks for the hints ..
chris
generally however, i think you should do the synchronisation between several threads before using outlet_*()
mfg.ad.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo!
as for the actual code in question, it creates only one single thread to read from the usb bus, and send data to the outlets if anything arrives. there are no other threads created.... an there are no variables/memory that the thread
but the outlet_anything() method is called in your helper thread? Then all the following objects, also connected to that one, will be in that helper thread ... so you have to synchronize it with the pd main thread first ...
tim, since i know nothing about flext (yet), just a few quick question (maybe i asked that loong ago alread....): does it work on linux/os-x/win? i need all three ....
yes. But you can do it of course also without flext - look e.g. at the [sndfiler] external ...
LG Georg
Christian Klippel wrote:
if you "guarantee" (e.g. leave it at the users discretion :-)) that no unprepared object will be involved in several threads, the i guess you
what do you mean by "unprepared objects" ? other objects that use threads too?
by "unprepared object" i mean objects that are not aware that they might receive messages in 2 different threads. the only object i *think* that is "prepared" in this sense is tim's [join] object.
as for the actual code in question, it creates only one single thread to read
which makes 2 threads in total (your helper-thread and pd's main thread)
from the usb bus, and send data to the outlets if anything arrives. there are no other threads created.... an there are no variables/memory that the thread shares with the rest of the external's code, except for sending to usb, which is synchronized ....
that shouldn't be a problem. however, as soon as you are talking with the rest of pd (e.g. via outlet_anything()) you cannot ensure anymore that the 2 threads have separate variables,...
what im wondering is, how can one stress-test such a situation to see if it works just by accident now, or if it is reliable ....
that's the nature of race-conditions: somebody wins the race and you cannot tell in advance who does (the whole bet-and-win commerce depends on that).
and even if the chance of loosing the race is 1:1e38 you are likely to have it exactly when you are to do the show....(however, you might get good conditions for this case at your local insurance agency, so it will do no harm to you - and the rest is covered by the license of the involved software)
so im really wondering how that could work, if it isnt supposed to be safe to call outlet_anything from a (single) thread ....
again, it is not a _single_ thread, but two (that's why there will be problems)
problems will appear if one objects gets messages from 2 separate threads (and is not aware of this).
sthg like:
[metro 1] [threadObject] | | [anotherObject]
additionally it might well be that one object will more easily a problem with multiple threads: e.g: if you are sending messages to [==] from a single object, you might only get corrupted values. (e.g. sending [1 1( in one thread might give you "0" (which means that 1!=1), since the concurrent thread has reset the 2nd value between receiving the value list and outputting the result; this is most likely a non-fatal behaviour (but mathematicians might disagree)
you will get more problems with objects that allocate and free memory on demand (without being thread save; and most pd objects are not!): e.g. accessing an array in one thread and resizing it in another thread is more likely to crash.
and as tim said:
solution 3: use flext, since it's taking care of that ...
tim, since i know nothing about flext (yet), just a few quick question (maybe i asked that loong ago alread....): does it work on linux/os-x/win? i need all three ....
yes it does work on all three of them. and it also works for max/msp. and it also has drawbacks :-)
mfg.asdr IOhannes
can anyone confirm that using outlet_anything() inside a thread is safe? just wrote a little object that reads a usb device in a thread, and send to the outlets from there directly via outlet_anything() .... so far it doesnt crash or anything, it just works (of course there are some objects connected to them), altough its only a few route's and slider/bangs/toggles connected.
solution 1: use the sys_lock() ... (not to mention "locking is bad") solution 2: use devel and the lockfree idle callback
solution 3: use flext, since it's taking care of that ...
of course it might work in every test you run, but it will certainly crash, when you're playing a concert :)
hth, tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
I had nothing to offer anybody except my own confusion Jack Kerouac
can anyone confirm that using outlet_anything() inside a thread is safe? just wrote a little object that reads a usb device in a thread, and send to the outlets from there directly via outlet_anything() .... so far it doesnt crash or anything, it just works (of course there are some objects connected to them), altough its only a few route's and slider/bangs/toggles connected.
solution 1: use the sys_lock() ... (not to mention "locking is bad") solution 2: use devel and the lockfree idle callback
solution 3: use flext, since it's taking care of that ...
of course it might work in every test you run, but it will certainly crash, when you're playing a concert :)
hth, tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
I had nothing to offer anybody except my own confusion Jack Kerouac
This sounds like you are wrtiing a [libusb] object, which would be very nice.
I have a different suggestion, related to the question I just posted. What about not using a thread at all, and instead having the first instance executed get the data from the USB bus, and stick it in an array. Then every other instance set to read the same device will just output the data from that array. This relies on the OS doing some buffering, which in the case of HID, GNU/Linux, Mac OS X, and Windows already do.
.hc
On Tue, 2 May 2006, Christian Klippel wrote:
hi all,
can anyone confirm that using outlet_anything() inside a thread is safe? just wrote a little object that reads a usb device in a thread, and send to the outlets from there directly via outlet_anything() .... so far it doesnt crash or anything, it just works (of course there are some objects connected to them), altough its only a few route's and slider/bangs/toggles connected.
since the thing does peak detection, there is a hell lot of toggles comming in, plus some faders ... so its really quite some traffic ....
but i want to make sure that i can do it that way, and not that there are any surprises later when doing that ...
thanks,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
hi,
Am Montag, 15. Mai 2006 13:42 schrieb Hans-Christoph Steiner:
This sounds like you are wrtiing a [libusb] object, which would be very nice.
not directly a general libusb object, altough some of the stuff may be reused for that...
I have a different suggestion, related to the question I just posted. What about not using a thread at all, and instead having the first instance executed get the data from the USB bus, and stick it in an array. Then every other instance set to read the same device will just output the data from that array. This relies on the OS doing some buffering, which in the case of HID, GNU/Linux, Mac OS X, and Windows already do.
well, first, there is more on usb than just hid. second, what about latency? if you dont use a thread, you can only poll the device at a defined intervall. if the "master" object is the last in the chain to be scheduled, the "slaves" can update on the next slice only, adding a lag of one "tick". next, how to syncronize? i see the same problems as with using a single thread an a single/multiple listener(s). what about the following:
the object has a "static char slave" which is 0 on the first instance, and 1 for each other. the object itself has a thread that constantly polls the usb bus. the master calls a "processsPacket(char *data)" function when data arrives, issuing a lock before the call and unlock after it. (note that the lock only happens when new data arrives....) or a similar thing, of course. if an instance detects that it is a slave, it just doesnt start the thread, but instead registers itself to a small "list of listeners" within the master. the master then calls the processPacket() function for each registered listener. of course, slaves have to unregister upon deletion. also, if the master gets deleted, it should set the first slave in that list as the new master.
what do you think about that?
on a related matter: somehow libusb seems to be unstable/buggy on windows. i have some code here, using bulk read's and write's, that works just fine on linux, but is almost non-working on windows. the data drips in maybe one packet each second or two, with only -116 error inbetween. also, the formerly working stuff for the multio starts to make these problems on windows now. and that even without any changes to the firmware or the pd-object...
so we should definitely investigate that issue first.... do you have a pic programmer and a usb pic at hand? if so, contact me off-list so we can setup a little test-bench for that purpose ....
oh, and a last thing: how do you intend to handle hid devices when they are claimed by some other driver already? there are syscalls at least in linux to detach devices from a driver by an external task. but imagine if, by accident, someone does that with the systems mouse & keyboard?
.hc
greets,
chris
On Tue, 2 May 2006, Christian Klippel wrote:
hi all,
can anyone confirm that using outlet_anything() inside a thread is safe? just wrote a little object that reads a usb device in a thread, and send to the outlets from there directly via outlet_anything() .... so far it doesnt crash or anything, it just works (of course there are some objects connected to them), altough its only a few route's and slider/bangs/toggles connected.
since the thing does peak detection, there is a hell lot of toggles comming in, plus some faders ... so its really quite some traffic ....
but i want to make sure that i can do it that way, and not that there are any surprises later when doing that ...
thanks,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
On May 16, 2006, at 5:52 PM, Christian Klippel wrote:
hi,
Am Montag, 15. Mai 2006 13:42 schrieb Hans-Christoph Steiner:
This sounds like you are wrtiing a [libusb] object, which would be very nice.
not directly a general libusb object, altough some of the stuff may be reused for that...
I have a different suggestion, related to the question I just posted. What about not using a thread at all, and instead having the first instance executed get the data from the USB bus, and stick it in an array. Then every other instance set to read the same device will just output the data from that array. This relies on the OS doing some buffering, which in the case of HID, GNU/Linux, Mac OS X, and Windows already do.
well, first, there is more on usb than just hid.
Indeed, but I only really know about HID. I can only guess about the rest. But I would like to know if the OS generally buffers USB data. If the OS doesn't, I'll bet the hardware does somewhere.
second, what about latency? if you dont use a thread, you can only poll the device at a defined intervall. if the "master" object is the last in the chain to be scheduled, the "slaves" can update on the next slice only, adding a lag of one "tick". next, how to syncronize? i see the same problems as with using a single thread
I posted a question about finding the first instance to execute, (it seems pretty easy to do it Pd space), with the idea that the first one always does the data getting. That solves that problem. As for latency, there would be no difference in latency if a Pd object was polling a thread or polling a file in /dev/; that object would still be polling at the same rate. Adding a thread would just put extra code between the Pd object and the /dev/ file.
an a single/multiple listener(s). what about the following:
the object has a "static char slave" which is 0 on the first instance, and 1 for each other. the object itself has a thread that constantly polls the usb bus. the master calls a "processsPacket(char *data)" function when data arrives, issuing a lock before the call and unlock after it. (note that the lock only happens when new data arrives....) or a similar thing, of course. if an instance detects that it is a slave, it just doesnt start the thread, but instead registers itself to a small "list of listeners" within the master. the master then calls the processPacket() function for each registered listener. of course, slaves have to unregister upon deletion. also, if the master gets deleted, it should set the first slave in that list as the new master.
what do you think about that?
You add a lot of complexity and more running code for no real gain. If you change the data in the middle of a poll interval, I think you'll be asking for trouble. The problem here is that I want multiple instances of an object to be able to output data from the same device. The data coming out of each instance should be exactly the same, or the chance of strange, hard to find bugs will be high. If a thread updates the data in between the poll intervals, then different instances will output different data in each cycle.
Polling latency is not an issue except in rare, customized situations. The fastest that Windows and Mac OS X can output HID data is once every 10 ms. The linux kernel can do once per 1ms if you customize things, but its generally 10ms also. These times probably all apply to generic USB event data too.
Plus Pd has a built-in scheduler, and we are writing Pd objects, so we should use the Pd scheduler, instead of an external one (i.e. threads). The more threads we add to Pd, the more we take CPU time completely away from the Pd scheduler. A couple of threads probably won't matter, but if we start using a lot of threads, it will matter.
on a related matter: somehow libusb seems to be unstable/buggy on windows. i have some code here, using bulk read's and write's, that works just fine on linux, but is almost non-working on windows. the data drips in maybe one packet each second or two, with only -116 error inbetween. also, the formerly working stuff for the multio starts to make these problems on windows now. and that even without any changes to the firmware or the pd-object...
so we should definitely investigate that issue first.... do you have a pic programmer and a usb pic at hand? if so, contact me off-list so we can setup a little test-bench for that purpose ....
Yeah, I expect libusb to be troublesome on Windows. I don't really have time to troubleshoot Windows now though. I only work on Windows as a matter of necessity. Plus the HID/input device stuff on Windows is such a pain in the ass, I don't think that instrument building will ever work very well on Windows.
oh, and a last thing: how do you intend to handle hid devices when they are claimed by some other driver already? there are syscalls at least in linux to detach devices from a driver by an external task. but imagine if, by accident, someone does that with the systems mouse & keyboard?
I think this is outside the scope of this Pd object, at least for now. The object should open the devices O_NONBLOCK whenever possible and rely on other software also opening using O_NONBLOCK too. So far so good...
.hc
.hc
greets,
chris
On Tue, 2 May 2006, Christian Klippel wrote:
hi all,
can anyone confirm that using outlet_anything() inside a thread is safe? just wrote a little object that reads a usb device in a thread, and send to the outlets from there directly via outlet_anything() .... so far it doesnt crash or anything, it just works (of course there are some objects connected to them), altough its only a few route's and slider/bangs/toggles connected.
since the thing does peak detection, there is a hell lot of toggles comming in, plus some faders ... so its really quite some traffic ....
but i want to make sure that i can do it that way, and not that there are any surprises later when doing that ...
thanks,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
On Wed, 2006-05-17 at 10:38 +0200, Hans-Christoph Steiner wrote:
latency, there would be no difference in latency if a Pd object was polling a thread or polling a file in /dev/; that object would still be polling at the same rate. Adding a thread would just put extra code between the Pd object and the /dev/ file.
yes ... but using pd's timer callbacks to poll the devices introduces two problems: - pd's timer callbacks are implemented as a linked lists ... adding to a linked list is highly inefficient ... O(n) ... one of the biggest problems of pd's scheduler ... - polling the device from the pd thread would add overhead code which is possibly blocking ... so your code can't be used in low-latency systems ...
cheers ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
A paranoid is a man who knows a little of what's going on. William S. Burroughs
On May 17, 2006, at 11:00 AM, Tim Blechmann wrote:
On Wed, 2006-05-17 at 10:38 +0200, Hans-Christoph Steiner wrote:
latency, there would be no difference in latency if a Pd object was polling a thread or polling a file in /dev/; that object would still be polling at the same rate. Adding a thread would just put extra code between the Pd object and the /dev/ file.
yes ... but using pd's timer callbacks to poll the devices introduces two problems:
- pd's timer callbacks are implemented as a linked lists ... adding
to a linked list is highly inefficient ... O(n) ... one of the biggest problems of pd's scheduler ...
Perhaps in theory, but Pd's scheduler is working quite well for me and a few thousand other people. But I don't pay attention to the implementation details.
- polling the device from the pd thread would add overhead code
which is possibly blocking ... so your code can't be used in low-latency systems ...
[hid] currently uses no threads, yet I have not heard any complaints about blocking/clicks. Also, I have yet to hear any clicks caused by [hid].
Please send an example patch if you can make [hid] cause clicks.
.hc ________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
linked list is highly inefficient ... O(n) ... one of the biggest problems of pd's scheduler ...
Perhaps in theory, but Pd's scheduler is working quite well for me and a few thousand other people. But I don't pay attention to the implementation details.
using several thousand metro/delay/pipe objects in my performance patch, adding clock callbacks to the list takes a considerable amount of my cpu...
- polling the device from the pd thread would add overhead code
which is possibly blocking ... so your code can't be used in low-latency systems ...
[hid] currently uses no threads, yet I have not heard any complaints about blocking/clicks. Also, I have yet to hear any clicks caused by [hid].
Please send an example patch if you can make [hid] cause clicks.
well, this is one of the most common mistakes when designing low latency systems ... there are problems, that occur only in very few cases ... so you don't experience the dropout during 10 days of rehearsal, but during the performance you have a click ... in these cases analyzing the code is a better approach than testing ...
tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
The aim of education is the knowledge, not of facts, but of values William S. Burroughs
On May 17, 2006, at 1:48 PM, Tim Blechmann wrote:
linked list is highly inefficient ... O(n) ... one of the biggest problems of pd's scheduler ...
Perhaps in theory, but Pd's scheduler is working quite well for me and a few thousand other people. But I don't pay attention to the implementation details.
using several thousand metro/delay/pipe objects in my performance patch, adding clock callbacks to the list takes a considerable amount of my cpu...
- polling the device from the pd thread would add overhead code
which is possibly blocking ... so your code can't be used in low-latency systems ...
[hid] currently uses no threads, yet I have not heard any complaints about blocking/clicks. Also, I have yet to hear any clicks caused by [hid].
Please send an example patch if you can make [hid] cause clicks.
well, this is one of the most common mistakes when designing low latency systems ... there are problems, that occur only in very few cases ... so you don't experience the dropout during 10 days of rehearsal, but during the performance you have a click ... in these cases analyzing the code is a better approach than testing ...
I disagree. For me practice is much more important than theory. There are endless theoretical issues with software, yet it generally works. For example, the old theories of software development say that the linux kernel development model does not work.
Theories should be based on observation. A good scientist observes the phenomenon with as open a mind as possible, then derives the hypothesis from the observation. [hid] object has been used a lot more than 10 days of rehearsal, there are numerous people performing with it, me included.
Performance tuning is the perfect example. A good programmer tries to write code that will perform well, but you never really know until you actually test it. (Or profile it, depending on your choice of words). That's where things like SHARC and oprofile come in.
Software is far too complex for one person to understand, from the transistors, to the final interface to the human, to all the layers in between. Therefore, testing is essential. So far, [hid] has received a pretty good amount of testing, it would be good to do some profiling too, but clicks have not yet been a problem.
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
hi all
Hans-Christoph Steiner wrote:
On May 17, 2006, at 1:48 PM, Tim Blechmann wrote:
Please send an example patch if you can make [hid] cause clicks.
well, this is one of the most common mistakes when designing low latency systems ... there are problems, that occur only in very few cases ... so you don't experience the dropout during 10 days of rehearsal, but during the performance you have a click ... in these cases analyzing the code is a better approach than testing ...
I disagree. For me practice is much more important than theory. There
both of you, please do calm down, this is getting really emotional for no reason (probably i don't see the brick in my eye and i might have put some oil into the fire too)
hans is perfectly right, when he considers practice very important, and often more important than theory: things tend to work in theory but not in practice, because sometimes you just cannot foresee everything.
tim is perfectly right when he says that often problems occur very seldom (which might make them invisible during long periods) but nevertheless they might occur (which - according to murphy (haven't heard of him for a long time, btw) - will happen when you are not really prepared for them): things tend to work in practice but only _most of the time_, because practice can never consider all cases.
so both theory and practice are good ways to keep problems low, but none of them can make all problems go away (that's the bad news) the good news is, that applying both approaches can lower the amount of problems even more.
so none of your approaches is better, but both are. so why don't you just join forces?
mfga·sdr IOhannes
On May 17, 2006, at 2:31 PM, IOhannes m zmoelnig wrote:
hi all
Hans-Christoph Steiner wrote:
On May 17, 2006, at 1:48 PM, Tim Blechmann wrote:
Please send an example patch if you can make [hid] cause clicks.
well, this is one of the most common mistakes when designing low latency systems ... there are problems, that occur only in very few cases ... so you don't experience the dropout during 10 days of rehearsal, but during the performance you have a click ... in these cases analyzing the code is a better approach than testing ...
I disagree. For me practice is much more important than theory. There
both of you, please do calm down, this is getting really emotional for no reason (probably i don't see the brick in my eye and i might have put some oil into the fire too)
hans is perfectly right, when he considers practice very important, and often more important than theory: things tend to work in theory but not in practice, because sometimes you just cannot foresee everything.
tim is perfectly right when he says that often problems occur very seldom (which might make them invisible during long periods) but nevertheless they might occur (which - according to murphy (haven't heard of him for a long time, btw) - will happen when you are not really prepared for them): things tend to work in practice but only _most of the time_, because practice can never consider all cases.
so both theory and practice are good ways to keep problems low, but none of them can make all problems go away (that's the bad news) the good news is, that applying both approaches can lower the amount of problems even more.
so none of your approaches is better, but both are. so why don't you just join forces?
Somebody slipped IOhannes something! Where's the sarcasm? Or maybe its an impostor!
(a very big ;)
I am not trying to make this a personal argument, but I think its an interesting issue. And debate can be a very useful way to bring the issues to the forefront, as long as everyone plays nice. For me, Pd is the test bed to test new ideas. Max/MSP is a very high quality production tool without strict adherence to the Max paradigm. For example, JavaScript for GUIs instead of graphical programming, and the use of threads rather than trying to stick with the real-time scheduling.
As for this question, threads will work, that I know. But I am interested in trying to find more Pd-ish ways of doing things. So this might fail entirely.
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
Somebody slipped IOhannes something! Where's the sarcasm? Or maybe its an impostor!
yes, must have been....i didn't realize that was me (so i had to immediately write the other mail which is a bit...sharper)
(a very big ;)
yo, and hugs to everybody :-)
I am not trying to make this a personal argument, but I think its an interesting issue. And debate can be a very useful way to bring the issues to the forefront, as long as everyone plays nice. For me, Pd is
right, and that's why i am taking part in this debate even if is often get rude....
mfgadsr. IOhannes
On Wed, 17 May 2006, Hans-Christoph Steiner wrote:
Max/MSP is a very high quality production tool without strict adherence to the Max paradigm. For example, JavaScript for GUIs instead of graphical programming,
The old MAX doesn't strictly adhere to the Max paradigm either. Externals are coded in C and C is not dataflow. Just because C is C doesn't mean you have to ignore that a lot of things get written in C just because there is no alternative (perceived or real). There's this double-standard by which C doesn't count as violating the paradigm while anything else may.
and the use of threads rather than trying to stick with the real-time scheduling.
how do you find the difference between a principle of the paradigm, and a limitation of an implementation? Why do threads necessarily fall outside of the Max paradigm? Would the "Max paradigm" be any different in your eyes if Miller didn't hate threads? How are threads necessarily non-realtime scheduling? How is realtime scheduling necessarily non-threaded? Have you ever looked at a realtime operating system like QNX which handles threads/processes in a thoroughly realtime way? What is the status of that kind of feature in Linux, OSX and Win32? What can Pd's scheduler do about priorities, time limits and preemption without getting itself to use the OS's threads?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 17 May 2006, Hans-Christoph Steiner wrote:
I disagree. For me practice is much more important than theory. There are endless theoretical issues with software, yet it generally works. For example, the old theories of software development say that the linux kernel development model does not work. Theories should be based on observation.
Theories that aren't based on observation (and/or logical proofs from axioms) aren't theories by any scientific standard. They're called speculations. Algorithmic theory is not based on speculation. It doesn't even make judgements of value like "O(1) is always better than O(n)". It doesn't say that. It says that when the problem size grows, you always hit a threshold at which point O(1) becomes better than O(n). If you never hit that threshold then you can't accelerate anything by going O(1), and if you never hit the threshold where you need to accelerate something, you can discard the whole question altogether.
I would prefer that the aforementioned "old theories of software development" be not compared with algorithmics because they're at completely different levels of rigor and scientificness.
That said, I don't have a need for 1000's of t_clocks, ... at least not today...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, May 18, 2006 at 11:53:40PM -0400, Mathieu Bouchard wrote:
On Wed, 17 May 2006, Hans-Christoph Steiner wrote:
I disagree. For me practice is much more important than theory. There are endless theoretical issues with software, yet it generally works. For example, the old theories of software development say that the linux kernel development model does not work. Theories should be based on observation.
Theories that aren't based on observation (and/or logical proofs from axioms) aren't theories by any scientific standard. They're called speculations.
This is true. To me what Hans is talking about is one of the distinctions between engineering and science. A scientist must make sure that his theory holds together in all ways possible, and must test it in reality. An engineer just needs to know what works for a particular and specific application. Hans seems more interested in an engineering solution than a scientific one.i
Theory can be extremely useful; two times already I have had an engineer try to convince me that they can come up with a generic algorithm to solve in polynomial time what I classified as an NP-hard problem. Next time I am betting beer on it.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
As a scientist I love the company of my scientist friends. We can chat to the early morning sun about electrical fields and the properties of quarks. When with the mathematicians we never lose a moment to stroke our beards over Euler and Riemann. Oh and the practical japes I enjoy with my engineer chums in the HE physics lab.
But my engineer buddies for all the great things they've built never got anything reliable enough to work for long. Fortunately the scientists know how to fix it, they're still waiting for some results to come in but they reckon they've achieved perfection, at least on paper. My mathematical mates have an elegant proof of this discrepancy, something to do with the set of all sets that don't include themselves as subsets.
Anyway it's not as if we can't all work together. Between us we've discovered that if offered the choice of a one or five year warranty on a device built to last exactly 13 months, 90% of the time I will opt for the service contract thus achieving the optimal transfer of money from my pocket to elsewhere.
On Fri, 19 May 2006 13:02:46 +0800 Chris McCormick chris@mccormick.cx wrote:
On Thu, May 18, 2006 at 11:53:40PM -0400, Mathieu Bouchard wrote:
On Wed, 17 May 2006, Hans-Christoph Steiner wrote:
I disagree. For me practice is much more important than theory. There are endless theoretical issues with software, yet it generally works. For example, the old theories of software development say that the linux kernel development model does not work. Theories should be based on observation.
Theories that aren't based on observation (and/or logical proofs from axioms) aren't theories by any scientific standard. They're called speculations.
This is true. To me what Hans is talking about is one of the distinctions between engineering and science. A scientist must make sure that his theory holds together in all ways possible, and must test it in reality. An engineer just needs to know what works for a particular and specific application. Hans seems more interested in an engineering solution than a scientific one.i
Theory can be extremely useful; two times already I have had an engineer try to convince me that they can come up with a generic algorithm to solve in polynomial time what I classified as an NP-hard problem. Next time I am betting beer on it.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, May 19, 2006 at 10:10:18PM +0100, padawan12 wrote:
As a scientist I love the company of my scientist friends. We can chat to the early morning sun about electrical fields and the properties of quarks. When with the mathematicians we never lose a moment to stroke our beards over Euler and Riemann. Oh and the practical japes I enjoy with my engineer chums in the HE physics lab.
But my engineer buddies for all the great things they've built never got anything reliable enough to work for long. Fortunately the scientists know how to fix it, they're still waiting for some results to come in but they reckon they've achieved perfection, at least on paper. My mathematical mates have an elegant proof of this discrepancy, something to do with the set of all sets that don't include themselves as subsets.
Anyway it's not as if we can't all work together. Between us we've discovered that if offered the choice of a one or five year warranty on a device built to last exactly 13 months, 90% of the time I will opt for the service contract thus achieving the optimal transfer of money from my pocket to elsewhere.
I probably deserved that. I'm not predjudiced - some of my best friends are engineers. ;)
Psyenz 2 th4 m4x,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
Hans-Christoph Steiner wrote:
rest. But I would like to know if the OS generally buffers USB data. If the OS doesn't, I'll bet the hardware does somewhere.
i wouldn't bet. the OS _might_ buffer, the hardware _might_ buffer, and pd _might_ block and have audio-dropouts.
second, what about latency?
always does the data getting. That solves that problem. As for latency, there would be no difference in latency if a Pd object was polling a thread or polling a file in /dev/; that object would still be polling at the same rate. Adding a thread would just put extra code between the Pd object and the /dev/ file.
obviously putting things in a thread is extra code. however, polling a thread means reading data from a shared memory segment while polling the /dev/-file means a system call which might block.
You add a lot of complexity and more running code for no real gain. If you change the data in the middle of a poll interval, I think you'll be asking for trouble. The problem here is that I want multiple instances of an object to be able to output data from the same device. The data
iThink, this was the problem ck was addressing.
coming out of each instance should be exactly the same, or the chance of strange, hard to find bugs will be high. If a thread updates the data in between the poll intervals, then different instances will output different data in each cycle.
i cannot follow you here. when querying data from an external device, then this data can change any instance of time. if i want to use the same data twice then i should use the _same data_ twice and not query an external device 2 times and hope that the data has not changed. (i mean: use [hid]->[t a a] and not [t b b]=>[hid]->[hid])
apart from that, i think ck's master/slave concept also took care of data synchronisity.
Polling latency is not an issue except in rare, customized situations. The fastest that Windows and Mac OS X can output HID data is once every 10 ms. The linux kernel can do once per 1ms if you customize things, but its generally 10ms also. These times probably all apply to generic USB event data too.
there are 2 kinds of latency we have to think of: 1. is the latency between an event appearing at the sensors of the external device and the appropriate data output within pd. 2. pd is (among other things) used for audio-processing. therefore audio-latency is a big issue. so if you rely on the OS buffering the data (which imho is a not-so-clever thing to do, especially if you support OSs which are proprietary and where you have no chance to know beforehand which way they'll go) and it does not then you might block the entire pd-thread for 10ms (on w32), just waiting on the hid-data. this basically means goodbye to all uses of pd which require low latencies. (even blocking the system for 1ms is unacceptable; btw we are currently evaluating linux without hid-support since it is known to block the kernel for up to 0.5ms every now and then)
Plus Pd has a built-in scheduler, and we are writing Pd objects, so we should use the Pd scheduler, instead of an external one (i.e. threads).
what makes you think that? your OS has a built-in scheduler why not user that? i thought we were talking about data-acquisition and not data-processing.
The more threads we add to Pd, the more we take CPU time completely away from the Pd scheduler. A couple of threads probably won't matter, but if we start using a lot of threads, it will matter.
the thing with threads is, that they don't necessarily use CPU. if a thread is blocking for 5 seconds, then any other process (including pd!) can use the CPU in this 5seconds without worrying about the thread; if pd is blocking for 5 seconds then everybody will be switching to max/msp or reaktor or even worse.
so the only solution to use low-latency pd AND "hid" would be to run 2 instances of pd communicating via netsend or similar. these 2 instances will run in separate threads (sic!). but these threads will be far heavier than the tiny read-libusb-thread in your object. the communication between the pd instances will add a processing overhead (and latency, btw) too. and of course handling several instances of pd can be painful - even though the problem would be solved in pd-space ;-)
and now i cannot remember why i have foam around my mouth...
mfg.ads.r IOhannes
On May 17, 2006, at 11:29 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
rest. But I would like to know if the OS generally buffers USB data. If the OS doesn't, I'll bet the hardware does somewhere.
i wouldn't bet. the OS _might_ buffer, the hardware _might_ buffer, and pd _might_ block and have audio-dropouts.
Actually, when talking about HID, the OS does buffer HID data on Linux and Darwin. Its part of the API IIRC.
second, what about latency?
always does the data getting. That solves that problem. As for latency, there would be no difference in latency if a Pd object was polling a thread or polling a file in /dev/; that object would still be polling at the same rate. Adding a thread would just put extra code between the Pd object and the /dev/ file.
obviously putting things in a thread is extra code. however, polling a thread means reading data from a shared memory segment while polling the /dev/-file means a system call which might block.
Well, since there has been zero problems with clicking with [hid] AFAIK, I suspect there is something different going on. With the Linux input event system, [hid] just reads up to 64 events from /dev/ input/event? per cycle.
Some profiling of this might be handy. Some docs would be too, but I've never found good docs on the Linux input stuff. I don't recall the details of Mac OS X at the moment, give me a couple days.
You add a lot of complexity and more running code for no real gain. If you change the data in the middle of a poll interval, I think you'll be asking for trouble. The problem here is that I want multiple instances of an object to be able to output data from the same device. The data
iThink, this was the problem ck was addressing.
coming out of each instance should be exactly the same, or the chance of strange, hard to find bugs will be high. If a thread updates the data in between the poll intervals, then different instances will output different data in each cycle.
i cannot follow you here. when querying data from an external device, then this data can change any instance of time. if i want to use the same data twice then i should use the _same data_ twice and not query an external device 2 times and hope that the data has not changed. (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 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.
apart from that, i think ck's master/slave concept also took care of data synchronisity.
If all instances output the exact same data from the polling thread, then things will work ok. If the thread updates the data directly in memory, and each instance just outputs the data in that memory location, for example, then whenever the thread updates the data in the middle of a time chunk, different instances will output different data. Like I said above, this breaks the Pd paradigm.
Polling latency is not an issue except in rare, customized situations. The fastest that Windows and Mac OS X can output HID data is once every 10 ms. The linux kernel can do once per 1ms if you customize things, but its generally 10ms also. These times probably all apply to generic USB event data too.
there are 2 kinds of latency we have to think of:
- is the latency between an event appearing at the sensors of the
external device and the appropriate data output within pd. 2. pd is (among other things) used for audio-processing. therefore audio-latency is a big issue. so if you rely on the OS buffering the data (which imho is a not-so-clever thing to do, especially if you support OSs which are proprietary and where you have no chance to know beforehand which way they'll go) and it does not then you might block the entire pd-thread for 10ms (on w32), just waiting on the hid-data.
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 HID stuff on Windows will be there for people to play with who don't care about high-end performance. HID works decently on Mac OS X, but GNU/Linux is far and away the best platform for this.
Plus I barely know anything about Windows programming. I'd help anyone who wants to do to a good HID implementation on Windows, because I will never do it. I'll just get the basics working.
this basically means goodbye to all uses of pd which require low latencies. (even blocking the system for 1ms is unacceptable; btw we 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 very specific needs. I don't know much about that stuff.
For instrument design 0.5ms is not significant, as long as there is no 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.
Plus Pd has a built-in scheduler, and we are writing Pd objects, so we should use the Pd scheduler, instead of an external one (i.e. threads).
what makes you think that? your OS has a built-in scheduler why not user that? i thought we were talking about data-acquisition and not data- processing.
We are talking about scheduling CPU time. If you want to follow that line of reasoning, why bother using Pd at all? Just put everything into threads.
The more threads we add to Pd, the more we take CPU time completely away from the Pd scheduler. A couple of threads probably won't matter, but if we start using a lot of threads, it will matter.
the thing with threads is, that they don't necessarily use CPU. if a thread is blocking for 5 seconds, then any other process (including pd!) can use the CPU in this 5seconds without worrying about the thread; if pd is blocking for 5 seconds then everybody will be switching to max/msp or reaktor or even worse.
so the only solution to use low-latency pd AND "hid" would be to run 2 instances of pd communicating via netsend or similar. these 2 instances will run in separate threads (sic!). but these threads will be far heavier than the tiny read-libusb-thread in your object. the communication between the pd instances will add a processing overhead (and latency, btw) too. and of course handling several instances of pd can be painful - even though the problem would be solved in pd-space ;-)
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 issues, that I can't solve. But I don't think threads will help with HID. I think that USB-serial will perform very similarly. If you are using bulk transfer mode for USB, that's a different story, for that you'd need a much more complicated implementation AFAIK.
Try it out. Seriously, show me a patch where [hid] causes clicks, and we can take it from there.
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
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
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
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
For instrument design 0.5ms is not significant, as long as there is no 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.
when running your audio device with block sizes of 64 samples, it means, that audio data have to be computed within 1.3 ms. it you block the process for 0.5 ms the rest of the computation has to be done within 0.8 ms, having a cpu utilization of more than 60 % won't be possible without a dropout ...
but i have to admit, vanilla pd has some other problems, that don't allow to run audio computation with these latency settings (wini's alsamm code won't run with latencies below 10ms on my machine)
cheers ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Linux is like a wigwam: no windows, no gates, apache inside, stable.
-
Chris McCormick -
Christian Klippel -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
padawan12 -
Tim Blechmann