Re: [PD-dev] [ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest. .hc On 02/28/2012 04:45 AM, IOhannes m zmoelnig wrote: trying to take the heat out of this: my patch suggested to change the loglevel offset from +4 to +3. is there anything speaking against this specific change? (it seems that all discussion is centered around the question whether there should be an offset at all, rather than how big it should be) fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-28 16:03, Hans-Christoph Steiner wrote: Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest. may i ask why? what makes 4 better than 3? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9M7VoACgkQkX2Xpv6ydvTRdwCgsxoUMeCeLH8NTcHacKFgx3mS iwcAnjnGX4VfaQYiJBOSFvv4ScTi5VPc =am3c -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack driver issues with 0.43
Hi again Is anyone else experiencing freezes due to this? Often with jack, when turning DSP off, Pd hangs and I get the watchdog messages, but no crash, Pd is just frozen. Is there any chance of getting back the old behaviour, that didn't spawn a new thread whenever DSP is turned on? Roman On Tue, 2012-02-07 at 10:49 +0100, Roman Haefeli wrote: Hi all When employing dynamic patching, in particular when doing dynamic patching with ~-objects, I found that drop-out time can be greatly reduced by turning dsp off during dynamic creation time. I used to turn dsp off and on in 0 logical time a lot in my patches and it never seemed an issue. Recently, I found that when doing so it causes a drop-out, no matter if there is dynamic patching going on or not. I figured out, that this happens only when Pd is using jack as the audio back-end. In gdb, I noticed that when ever I turn dsp off, I get those messages: [Thread 0xb3065b70 (LWP 11244) exited] [Thread 0xb7f60b70 (LWP 11243) exited] [Thread 0xb7fe1b70 (LWP 11242) exited] When turning dsp on again, I get: [New Thread 0xb7fe1b70 (LWP 11250)] [New Thread 0xb7f60b70 (LWP 11251)] [New Thread 0xb3065b70 (LWP 11252)] It seems, that since 0.43 - when using jack - turning dsp off and on cannot be done silently anymore. For me, this has a few implications: * I certainly get a drop-out in the audio stream. Starting and stopping dsp costs a lot of time now. * The jack-client 'pure_data_X' disappears when turning dsp off and thus it looses all hand-made connections to other applications. * Often, Pd hangs after a few cycles of turning dsp off/on. Pd-gui doesn't respond on any input and I see the 'watchdog signaling Pd' message appearing. Personally, I find the old no-thread-spawning-on-dsp-on implementation much friendlier in many ways, but to me most importantly, it was able to avoid drop-outs when turning dsp off and on in 0 logical time. What do others thing, what is their experience? Is there any chance of going back to the old way of using Pd with jack? BTW: Everything works still nice with ALSA. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
On 02/28/2012 10:06 AM, IOhannes m zmoelnig wrote: On 2012-02-28 16:03, Hans-Christoph Steiner wrote: Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest. may i ask why? what makes 4 better than 3? +4 already there. +3 an incompatible change that does not fix things. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] GEM passing output image later.
For the pdp to GEM port of my freeframeGL host, I bump into a GEM shortcoming... When processing a pix image in a GEM external, the image is passed to the processRGBAImage method. You can access it during the length of the function, after which I suppose, the imagestruct is automatically passed to GEM for outputting. What I want to do though, is outputting the image only when the next image is being started to process. I'll explain why: I do a call to glReadPixels, which needs quite some time to finish, but by ussing Pixel Buffer Objects, I can do this transmitting from GPU to CPU asynchronously, so I can do stuff during the wait for glReadPixels to finish, then I can copy the buffer into the output image. Best is to wait for the next image, which comes mostly more then 20ms later, so meanwhile the call can complete. GEMs design doesnt facilitate outputting an image after the end of the processing method though... Is there some method internal to GEM that I can use to directly send some data to the image outlet? Or does anyone have an idea how to wait for glReadPixels without at the same time blocking the CPU? I can be found scrutinizing some more GEM source code... ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-3495486 ] sfwrite13~ won't create
Bugs item #3495486, was opened at 2012-02-28 19:41 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3495486group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: sfwrite13~ won't create Initial Comment: ext13/sfwrite13~ won't create in sfwrite13~-help.pd -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3495486group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
