[PD] Slow cpu/RJDJ patching approach ...

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> 
> On May 26, 2009, at 1:52 PM, IOhannes m zmoelnig wrote:
> 
>> Hans-Christoph Steiner wrote:
>>> Yeah, I agree that the communications are a big part of it.  Part of 
>>> writing a custom GUI would be to write a simple communications to 
>>> suit the needs at hand.
>>> But I think that the slowness in Pd's GUI is not even that much due 
>>> to communications, but rather how the code is structured.  For 
>>> example, if you move on element in an array, instead of issuing a 
>>> single Tk 'move' command, Pd deletes the whole array, then recreates it.
>>
>> this is (among other things) what i mean by "busted communication".
>>
>>> And Dan, I also share your frustration with the common attitude on 
>>> this list of "it is what it is".  That's why I am working on 
>>> re-writing the Pd GUI from scratch in pure Tcl with the aim of making 
>>> it use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4).
>>
>> oh, i thought you wanted miller to include the code of 
>> Pd-devel...seems like you got off the track :-(
> 
> Um, how is this mutually exclusive?  My motivation in working on 
> pd-devel is unchanged.

it is mutually exclusive by what miller has said on this topic.
i wish it wasn't

> 
>  From what I gather, Miller is more or less game for including that 
> work.  

[...]
> 
> In particular, I want to structure the code around the idea of a 
> communications API that uses Pd messages for both directions.  For now, 
> it will use the existing pd<-->pd-gui API, then the next step would be 
> working on the C side of things once Miller has included it.

as far as i understand it, miller has stated several times explicitely 
that he is fine with re-structuring the tcl/tk code.
however (and this is the crucial part), he is not going to accept any 
substantial changes to the C-part of it.
hopefully this will change.


if i had more time, i would have started this myself several times...

fmasdr
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090527/037d2c21/attachment.bin>