19 messages in at.iem.pd-listRe: [PD] spread Gem-computation over ...| From | Sent On | Attachments |
|---|---|---|
| Roman Haefeli | Feb 27, 2007 3:19 pm | |
| cyrille henry | Feb 27, 2007 3:43 pm | |
| Roman Haefeli | Feb 28, 2007 1:08 am | |
| IOhannes m zmoelnig | Feb 28, 2007 5:45 am | |
| cyrille henry | Feb 28, 2007 5:53 am | |
| Kyle Klipowicz | Feb 28, 2007 7:05 am | |
| Frank Barknecht | Feb 28, 2007 7:25 am | |
| chris clepper | Feb 28, 2007 7:47 am | |
| cyrille henry | Feb 28, 2007 8:04 am | |
| cyrille henry | Feb 28, 2007 8:15 am | |
| Roman Haefeli | Feb 28, 2007 2:23 pm | |
| Roman Haefeli | Feb 28, 2007 2:35 pm | |
| Roman Haefeli | Feb 28, 2007 2:53 pm | |
| cyrille henry | Feb 28, 2007 3:08 pm | |
| Chris McCormick | Feb 28, 2007 6:28 pm | |
| Roman Haefeli | Feb 28, 2007 6:34 pm |  .pd |
| cyrille henry | Mar 1, 2007 2:18 am | |
| Roman Haefeli | Mar 1, 2007 3:28 am | |
| cyrille henry | Mar 1, 2007 3:39 am |
| Subject: | Re: [PD] spread Gem-computation over several dsp-cycles (?) | |
|---|---|---|
| From: | IOhannes m zmoelnig (zmoe...@iem.at) | |
| Date: | Feb 28, 2007 5:45:59 am | |
| List: | at.iem.pd-list | |
Roman Haefeli wrote:
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a] | | | | [del 10] | | / / [any ]
as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
this is not a question of the design of Gem but of openGL. for most objects (but the pix_ stuff), Gem directly communicates with the underlying openGL-infrastructure. for this to work, one must get hold of the openGL context. using delayed gem-messages, the openGL-context will most likely be grabbed by another application.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
on the long run i have plans to put the rendering into a separate thread. however, don't expect it too soon.
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
2 ways: - use longer audio buffers (e.g. 100ms) - use 2 instances of pd: one for audio and one for video; one of them (or a third one) is "master" and controls the rest.
mfg.asdr IOhannes