[PD] raw data in sys_gui (was: GUI and DSP)

[Mathieu Bouchard]

Le 2012-02-10 à 21:16:00, Hans-Christoph Steiner a écrit :
> On Feb 8, 2012, at 3:22 PM, Mathieu Bouchard wrote:
>> If Tcl had fast base64 support (like Perl/Ruby), the difference would 
>> be even bigger. And it would bigger with the ability to send binary 
>> data (which can't happen now because "}" counts as end-of-block).
> That's an interesting idea, have you tried it?  Are you proposing to 
> make all messages between 'pd' and 'pd-gui' binary?  Or this would be 
> only for sending chunks of data, like arrays?

That's not what I'm saying, but I could be proposing it, or something 
similar. Surely it would fix some problems. Much of the thinking came from 
coding [#see] (which is used all over my patch_dans_patch picture series, 
and also some other screenshots).

For [#see] I tried base 16 (hex), base 64 (uu or mime), and base 256 
(straight «binary»). Apart from braces, a major problem with sending 
straight binary is byte '\0', which means end-of-string. There's no 
sys_gui function that accepts sending '\0', which requires passing (size_t 
n, const char *) instead of just (const char *).

I tried using a 2nd socket just for GF's binary data. To deal with 
deadlocks due to blocking socket, would have to do a long workaround 
involving nonblocking sockets.

Then I thought about shared memory (shm, mmap) which is also the fastest 
possible... in several ways (share with tcl string, or share directly with 
tk image data).

Finally, the only expedient and most portable way to do things quite fast, 
was to write a temporary ppm file on the file system and get Tk to read it 
that way.

IIRC, it's still not GF's default. [#see 1] enables the fast mode. The 
slow mode grows really slow, and even though there's no [info complete] in 
the versions of pd that I run, there's something that greatly slows down 
[#see] as images grow bigger, in a way similar to [info complete], 
somewhere in t_tkcmd.c or other place.

It doesn't look very possible to send raw binary through pd's tcl socket, 
the way it's implemented now. It would have to be done the other way that 
I proposed, in which sys_gui enforces an end-of-packet when returning from 
certain functions, so that it becomes easy to switch between tcl command 
mode to binary mode and back, on the same socket. You can't have both on 
the same socket if you try running [eval], [uplevel] or [info complete] on 
data that is not even meant to go in such functions.

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC