[PD] new disis_wiimote : undefined symbol: sys_flushtogui

[Hans-Christoph Steiner]

On May 10, 2012, at 1:45 PM, Ivica Ico Bukvic wrote:

>> Why do you think that this can only be done by exposing sys_flushtogui()?
>> My guess is that this can be done using the current public API, but I'd to
> know
>> more about the issue to make a concrete suggestion.
> 
> Indeed... To make any suggestions, like the one below, you would need to
> look at the external's behavior. In this case, connection is handled in the
> same thread as pd which means the thread freezes until wiimote connects.
> Because connection happens immediately after requesting the posting of a
> message "please press 1+2 buttons on a wiimote to connect" (which I would
> argue is rather important bit of information for a user), the message never
> reaches the gui because the thread freezes waiting on the Bluetooth stack to
> report that the connection has succeeded/failed. Flushtogui placed in
> between the post() call and the connect() call allows for the said message
> to be indeed displayed before the pairing takes place. If you can think of a
> better way to do this I'd certainly appreciate suggestions.

It sounds to me like the issue in the thread programming.  Using threads in Pd externals is tricky since the thread has to sync up with Pd, which uses an entirely different kind of scheduling than threads.

Why not handle the connect in the other thread?  Or even better, maybe there is a non-blocking way to do it where [wiimote] registers a callback, then sends the connect message, and carries on normally..  Then once the wiimote finished connecting, cwiid calls the callback in Pd, and Pd registers the wiimote as connected.

.hc

> As for bidirectionality of communication, this has nothing to do with
> examples listed below. Rather, on lower-powered cpus (e.g. Atom netbooks)
> request to enable rumble on a wiimote most of the times results in an xrun.
> disis_wiimote handles this and other thread-unsafe actions in a separate
> thread so that one can send as many rumble/led/etc. requests back to wiimote
> without that having to result in an xrun.
> 
>> 
>> There are a number of objects that handle bidirectional communication with
>> hardware and they don't need sys_flushtogui(). [comport] and [hidio] come
>> to mind.  Then there are the network objects, which also handle
> bidirectional
>> communication.
> 
>