hi,
here's my template for a threaded external. i had to use pthread,
because polling an usb device was causing glitches in pd. since i didn't
want to have 2 instance of pd (1 for polling usb + netsend, 1 for audio
+ netreceive) i came up with this solution. i am sure it's dirty and
On Sun, 18 Oct 2009, Claude Heiland-Allen wrote:
Ivica Ico Bukvic wrote:
iret1 = pthread_create( thread, NULL, cwiid_pthread2_setRumble,
(void*) rPars);
This creates a new thread.
pthread_join(thread, NULL);
This waits (blocking Pd's main thread) until the new thread
Take a look at the code in my gphoto external (in svn)
uses sys_lock() and non-joined pthreads.
.b.
Claude Heiland-Allen wrote:
Ivica Ico Bukvic wrote:
iret1 = pthread_create( thread, NULL, cwiid_pthread2_setRumble,
(void*) rPars);
This creates a new thread.
I think a thread is likely just going to add complication here. The
HID stuff is all without threads and works well. If cwiid is already
threaded, then chances are you should be able to get data from its
threads using non-blocking calls. If it already buffers the data,
then you don't
The problem is however that this is not the case. Whenever issuing
rumble/led commands and/or toggling various features (enable ir, acc,
nunchuk, etc.), cwiid call causes a dropout in audio thread. It's
obvious that the initial threaded implementation done by one of my
students should've been
One small fix to the callback seem to have improved stability (now at
least the thing loads and runs). The trick is when object is closed
without explicitly disconnecting and loaded again and closed the same
way (in both cases destructor ought to take care of things), the second
time pd freezes.
OK,
So here's an implementation that apparently is as stable as it gets.
Basically, disconnect/connect had to remain where they are in order to
spawn callbacks within the main Pd thread. The three remaining
problematic messaging systems have been encapsulated into a single
thread (LED, Rumble,
Hi all,
I am currently working on a threaded implementation of a wiimote
external. The reason I was hoping threaded design would help is to avoid
dropped samples when issuing commands to wiimote (e.g. rumble/led status
change). So far, it seems that reading from wiimote, no matter how fast,
has
Ivica Ico Bukvic wrote:
iret1 = pthread_create( thread, NULL, cwiid_pthread2_setRumble,
(void*) rPars);
This creates a new thread.
pthread_join(thread, NULL);
This waits (blocking Pd's main thread) until the new thread terminates.
So, why create a new thread only to
