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.stilt...@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 <danomat...@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.stilt...@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 <i...@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@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list