[PD] libpd separating gui from core

[Billy Stiltner]

I fixed my wired mouse(was using hp wireless) , have 2 different keyboards
laptop and desktop, still with 64 bit dual core 2.2Ghz laptop with 4Gb ram
I get dropouts with xensynth even without moving the mouse. this does not
happen with miniwoog_1.0 downloaded from the forum site I think. I guess I
just have too many graphical objects.


On Fri, Feb 28, 2014 at 11:34 AM, Billy Stiltner
<billy.stiltner at gmail.com>wrote:

> re:
>
> Well, you're not using any tcl/tk if you're using libpd in ofxPd. The
> blame falls elsewhere.
> on slow machines it doesnt matter what gui you use there will be problems
> is my point
> so the best thing to do is fix tcl/tk
>
>
>
> On Fri, Feb 28, 2014 at 7:40 AM, Dan Wilcox <danomatika at gmail.com> wrote:
>
>> Well, you're not using any tcl/tk if you're using libpd in ofxPd. The
>> blame falls elsewhere.
>>
>>
>> enohp ym morf tnes
>> --------------
>> Dan Wilcox
>> danomatika.com
>> robotcowboy.com
>>
>> On Feb 28, 2014, at 3:13 AM, Billy Stiltner <billy.stiltner at gmail.com>
>> wrote:
>>
>> it's the overhead of the os that gets in the way, i started to try ofxpd
>> but found ofxui to be slow as all getout with my old machine.
>> what would be nice is someone fixing tcltk
>>
>>
>> On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic <ico at vt.edu> wrote:
>>
>>>
>>>
>>> For instance, it seems like there are two main concerns floating around:
>>>
>>>
>>>
>>> a) multiple instances of pd
>>>
>>> b) separating GUI from core
>>>
>>>
>>>
>>> I would add a c) here which is what pd-l2ork has been doing, namely
>>> getting rid of all known bugs and streamlining experience until it reaches
>>> a level of stability where issues are a rare occurrence. My take is that
>>> refactoring becomes a lot easier at that point because one will have a much
>>> better idea what components should look like. Otherwise, fixing things
>>> post-refactor will net in even more headaches where two parts may end-up
>>> being potentially out of sync with each other, resulting in a broken app.
>>>
>>>
>>>
>>> There are other suggestions like platform-specific vectorization and
>>> multi-threaded support, but if you try to do these at the same time, you
>>> reduce the chance of ever getting the code back into vanilla.  They can be
>>> taken on after.
>>>
>>>
>>>
>>> IMO, the best thing to do going forward for a) would be to sync up with
>>> Miller and what he netted out with last time this was discussed ( see
>>> thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html).
>>> It seemed like he was proposing to take a hefty chunk of the work on, or
>>> maybe if he is confident in merely the approach, someone else can have a go
>>> at it.
>>>
>>>
>>>
>>> Having been on this list for quite a few years, I know of only one
>>> person who was allowed to significantly contribute/alter the core and that
>>> was Hans. And even that amounted to mainly cleaning up tk code to make it
>>> more legible (yes, this is a gross oversimplification, there was
>>> internationalization, console verbosity, and many other little things, but
>>> in general the brunt of the work was lateral in nature).
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140318/48ff75bc/attachment-0001.htm>