Sorry, I mean't an increase in performance with the mega-patch (lower CPU load) and a decrease with subpatches and abstractions (higher CPU load).Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ On Tuesday, 13 January 2015, 16:26, Ed Kelly <[email protected]> wrote: Yes, that's what I mean. Maybe I'm suggesting a new mode, where the mouse move only makes the proc routine run after it's stopped for perhaps 100ms.The reason is: abstracting the mega patch leads to a decrease in performance on iOs devices, and in 2012 I discovered that it abstractions that use audio ups the CPU load on any Pd patch. I think it's because the abstraction is taken to be a separate audio graph to calculate that is worked out before the CPU folds this into the master patch's audio input/output graph.Thus, I have to unwrap the patch (put all the audio processes into the master patch, without subpatches or abstractions) before it will run on the iPhone. Jonathan - will the -d command sent to Pd enable a lower rate of tk mouse motion events? Cheers,Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ On Wednesday, 7 January 2015, 20:18, Jonathan Wilkes <[email protected]> wrote: Hi Ed,When you move the mouse on a canvas...1) A tk mouse motion event calls a proc (I can't remember the rate at which they are sent, but run Pd with -d 3 and watch how many motion messages are sent over the socket as you mouse around) 2) The proc sends a message "[canvas you're mousing around in] motion blah blah blah" to the Pd process 3) Pd forwards the message to the canvas you're mousing around on, by calling the "motion" method 4) canvas_motion leads to canvas_doclick, which leads to this:for (y = x->gl_list; y; y = y->g_next) So for each motion message, Pd searches through a linked list of objects on the canvas either until it finds one under the mouse or it runs out of objects. If you only have a [bng] and a subpatch on the canvas, it probably is insignificant-- it's just comparing two saved bbox coordinates to the mouse position. If you have your entire monster patch on a single canvas, just following all those pointers in the linked list is probably taking its toll on Pd's ability to compute a block of audio on schedule. -Jonathan On Wednesday, January 7, 2015 12:21 PM, Ed Kelly <[email protected]> wrote: On Wednesday, 7 January 2015, 11:55, Ed Kelly <[email protected]> wrote: What about this... When I am editing a huge patch like the Ninja Jamm patch, where everything is on the same level (i.e. as few sub-patches as possible) moving the mouse over the patch causes a CPU spike, regardless of whether I change, move or connect anything or not. Could this be changed? I don't know all the guts of Pd, but if you could just move around the mouse pointer withouthaving to wait for 20 seconds or so before you can do anything, it would save a lot of time. I think I heard once that any change to the patch means that Pd has to re-draw the entire graph. IMHO surely moving the mouse should not require this? I wait to be corrected! xEd Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
