Hi, Thank you all for the suggestions. ♥ ♥ ♥ I did the later, all xyz spacial and rgb color data is now stored in tables and it works much better all-though the sound is still a little glitchy. All the lists are retrieved one time when the plot button is banged. I'll investigate the glitch tomorrow. if anyone wants to give it a try, it's in the 08-timbre-space folder and needs pd~ for the Gem subprocess, so no MS-win. https://github.com/mxa/timbreID-examples You'll need a Kinect and Synapse for the whole fun. Samples up to 4,5 Minutes long and 7000 tID units are loaded.
m. Am 03.09.2012 um 17:41 schrieb William Brent: > Hi, > > Yep, list parsing is probably the issue. Without the snapshot trick, > every render frame sends data requests to the [timbreID] object, and > lists are output in response. Those lists have to be parsed to get > the coordinates for points. That's the price for storing/manipulating > all the analysis data in [timbreID], but you could definitely do > everything it does internally via patches, and then have more > flexibility. Or you could still use [timbreID], but do all the data > requests in advance and store the results in tables. > > > > On Sun, Sep 2, 2012 at 12:23 PM, Cyrille Henry <c...@chnry.net> wrote: >> hello, >> >> the repeat/gemlist trick is very fast. it can be used to render lot's more >> point in real time. >> (try pmpd example 57 : 2000 points are rendered at 50 fps on my computer >> with no problem) >> >> i suspect that the bottleneck is the list parsing. >> one trick to speed this is to put the list in a table, and use tabread to >> access the data. >> (i did not have a look a the patch, so i may be wrong). >> >> cheers >> c >> >> >> Le 02/09/2012 18:01, Max a écrit : >> >>> hi list, william, >>> >>> this is a Gem recursion and glsl question. >>> in the example patches for timbreID there is an interesting patch where >>> the grains of a sample can be seen as a point cloud according to their >>> parameters. this is done by parsing a long list for each point throuch a >>> recursive gem chain using [zexy/repeat] it works very well up to 40 points >>> (or a sample of up to 10 seconds). However, when you try to do this with a >>> sample of 4.5 minutes it doesn't work any more because the list parsing and >>> gemlist repeating for each and every point (then about 900) at framerates of >>> 10 fps is to heavy on the CPU. >>> William resolves this by rendering it once and taking a snapshot of the >>> scene. that works nicely, but is not an option for my work, as i want to see >>> the 3d space and navigate in it real-time. I was wondering if this could be >>> done more efficiently and where to start. I think the points should be >>> rendered in a glsl environment and the list of every points position should >>> be static (in a matrice?) and not called and parsed by [list] objects at a >>> rate of >9000 times per second. Unfortunately the geometry shader example >>> doesn't work here, i was hoping to get some clues from there. >>> >>> william has a tiny image of a point cloud on his page: >>> http://williambrent.conflations.com/pages/research.html#timbreID >>> >>> max >>> _______________________________________________ >>> 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 > > > > -- > William Brent > www.williambrent.com > > “Great minds flock together” > Conflations: conversational idiom for the 21st century > > www.conflations.com _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list