[PD] max for live

[harris_pilton at gmx.de]

hi list,

is somebody still aware of this. i mean like having it on the agenda/ 
taking care of it. i'm sorry for not doing it. as i so far dont have  
experience in programming it might wouldn't be a good idea to let me  
do that ;) i wasnt even able to follow the whole discussion. but there  
seemed everybody seemed to match there has to been something on that  
field.
i just wondered if anybody is doing anything on this. (maybe 2 people  
are doing same things on different channels - i dont hope thats the  
case...).

thanks for not getting me wrong in advance.

regards


Am 22.01.2009 um 02:21 schrieb Hans-Christoph Steiner:

>
> On Jan 19, 2009, at 6:23 PM, Luke Iannini wrote:
>
>> On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner
>> <hans at eds.org> wrote:
>>>
>>> On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
>>>
>>>> Daniel Almeida wrote:
>>>>> I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
>>>>>
>>>>> Daniel
>>>>
>>>> yeah that's what i said about two years ago...
>>>>
>>>> the problem is, at the moment tcl/tk is embedded quite deeply into
>>>> Pd
>>>> itself. this is a focus of the current pd-dev effort: trying to
>>>> clear this
>>>> up. tcl/tk in itself isn't _necessarily_ slow, it's just that the
>>>> way Pd is
>>>> using it is not at all optimised (for example, as Hans-Christoph
>>>> and i
>>>> discovered once, when you click-drag to move an element in a
>>>> graphical
>>>> table, not just the element you moved but _the entire table_ is
>>>> redrawn,
>>>> each time).
>>>>
>>>> --
>>>> damian stewart | skype: damiansnz | damian at frey.co.nz
>>>> frey | live art with machines | http://www.frey.co.nz
>>>
>>>
>>> It's slight worse, even.  The entire table is deleted and re-created
>>> on each change, not even just redrawn.  That said, I am guessing
>>> the C+
>>> + code on the GPU (Live) will always be quite a bit faster than Tcl/
>>> Tk
>>> on the CPU.  One of the ways that Live is able to make things fast  
>>> is
>>> by ignoring the native widgets on each platform and coding their  
>>> own.
>>> Tcl/Tk is the best GUI toolkit I've seen for making native-feeling
>>> apps while writing cross-platform code.
>>>
>>> If Live is really just blasting bitmaps to the screen, that is
>>> something that Tcl/Tk can easily do.  But I am not sure that it  
>>> would
>>> be the fastest way to implement GUI widgets.
>>>
>>> If someone wants to help this situation, I think the best thing to  
>>> do
>>> would be to create some GUI objects using TkZinc.  Then we'll have
>>> Tcl/
>>> Tk on the GPU and that should make things quite a bit faster.
>> Wow, hadn't heard of TkZinc.  That looks incredible.  Another cloud
>> for my Pd heaven : ).  As I've been writing, I'd really love to  
>> create
>> GUIs entirely with Data Structures - I'm not sure how much of a
>> performance hit that causes but the opportunities for customization
>> are much richer when it's turtles all the way down (where turtles =
>> Pd).  Is TkZinc feasible for replacing the whole GUI?  It seems to
>> support all the platforms Pd does.
>
> That is something to find out.  It sounds promising.  At least it
> would be possible to write a TkZinc canvas which works like data
> structures, but uses OpenGL.
>
> .hc
>
>>
>>
>> Best
>> Luke
>>
>>>
>>> .hc
>>>
>>>
>>> ----------------------------------------------------------------------------
>>>
>>> There is no way to peace, peace is the way.       -A.J. Muste
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>
>
>
>
> ----------------------------------------------------------------------------
>
> Mistrust authority - promote decentralization.  - the hacker ethic
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list