Re: [PD-dev] Using PD funcs from inside a threaded external
Tim Blechmann wrote: not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ... i'm pretty sure that this is _not_ true. a [delay 0] will schedule the message within the same tick. actually i haven't found a simple reliable way to schedule a message in the next tick, regardless of samplerate and blocksize. fgmasdr IOhannes 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] Using PD funcs from inside a threaded external
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ... i'm pretty sure that this is _not_ true. a [delay 0] will schedule the message within the same tick. rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;) -- t...@klingt.org http://tim.klingt.org A paranoid is a man who knows a little of what's going on. William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [declare -distro vanilla]
Hans-Christoph Steiner wrote: On Mar 18, 2009, at 8:06 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: Then there could be also something like a 'maxmsp' distro for a compatibility mode. So I was thinking there could be a #X declare -distro vanilla that each distro saves into every file. It would be safely ignored for Pd versions that didn't support the -distro flag. what would e.g. Pd-vanilla that supported a -distro flag do if it encountered a [declare -distro maxmsp]? That would be up to Miller. Ignoring it would be one possibility. ok. so what would Pd-extended do if it encountered a [declare -distro puredata] since this is up to you, what would you actually do? ignore it as well? and if so, what would be the purpose of this little exercise? furthermore: i don't think that it is good design to have [declare] accept _any_ arguments and ignore them at will (e.g. if it decides to not support -distro, then it could either explicitely ignore -distro or accept any argument and only use those that it knows about. I am not sure I follow what you are asking. The behavior of this would be dependent on the distro. So someone could quietly ignore all -distro flags, they could through warnings or errors, or do a little dance. i was not asking for something. but i thought the idea of this would be to make projects more portable, rather than generate error messages. This distro flag would then setup the canvas-local namespace with the libraries as they are loaded for that distro. in general, i think the idea tobe able to load named library-bundles is not such a bad idea. this should have read: in general, i think the idea tobe able to load named library-bundles is not a good idea. though now i am not so sure about this anymore. if the only purpose of my suggestion was to have a named shorthand for loading libraries in a specific way, then it is rather useless. it should be possible to do this with [declare] as it is now. the benefit for having a single shortcut for a collection of libs seems to be rather small. I think that there should be some distro file format that could be placed in a folder to be installed and used. That way people could freely create and distribution their own. what exactly do you mean with distro? is it the collection of objects it comes with? does it include modifications to the Pd-core as well? I am thinking this isn't like a library, I think there would only be a handful of distros defined. hmm, do i understand it correctly that by a handful distros defined you mean a fixed enumeration? i'm rather glad that Pd has an open plugin-concept, and miller did not decide a one time that [expr], [fiddle~] and [bonk~] were enough. (but then there would be no problems with nameclashes and distros and such) just kidding of course. but anyhow, how does it relate to people could freely create? I don't think this functionality would work so well with many, many distros but perhaps. if it does not work so well, then it's probably badly designed. so let's improve it's desgin. and imagine: nameclashing distros! fgamdsr IOhannes #N canvas 303 243 775 513 10; #X declare -lib zexy; #X obj 157 115 operating_system; #X obj 189 182 select linux; #X obj 125 66 loadbang; #X obj 285 5 import zexy; #X obj 147 5 declare -lib zexy; #X obj 189 353 print [linux_mode]; #X text 18 5 depends on zexy:; #X obj 125 92 t b b; #X obj 125 194 i 0; #X obj 157 134 t b a; #X msg 270 204 ERROR: linux-mode is currently unsupported on \$1; #X msg 157 153 1; #X obj 125 218 select 0; #X msg 125 292 ERROR: no zexy detected: refusing to switch to linux-mode ; #X connect 0 0 9 0; #X connect 1 1 10 0; #X connect 2 0 7 0; #X connect 7 0 8 0; #X connect 7 1 0 0; #X connect 8 0 12 0; #X connect 9 0 11 0; #X connect 9 1 1 0; #X connect 10 0 5 0; #X connect 11 0 8 1; #X connect 12 0 13 0; #X connect 13 0 5 0; #N canvas 318 266 586 383 10; #X declare -lib zexy; #X obj 163 278 linux_mode; #X text 37 69 [linux_mode] will execute the current patch on a virtual machine running linux.; #X text 40 141 this allows you to use the powers of Linux on any platform. ; #X text 40 165 this object is still under develepment and should be considered experimental. not all features are implemented yet.; #X text 50 240 useage:; #X text 122 238 put the object in your patch and re-load the patch. the patch will now run within a linux-environment.; #X text 34 101 for performance reasons \, the patch will not be run within a VM \, if you are already running linux.; 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] Using PD funcs from inside a threaded external
Tim Blechmann wrote: not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ... i'm pretty sure that this is _not_ true. a [delay 0] will schedule the message within the same tick. rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;) ah yes, i forgot that there are only next ticks :-) fgmasdr IOhannes 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] Using PD funcs from inside a threaded external
On Thu, 19 Mar 2009, Tim Blechmann wrote: rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;) Are you assuming that pd is running with any realtime priority like -rt ? What about -nrt ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
Thanks for the comments Tim Mathieu, It seems I have two options: * Not send output to PD (very limited functionality) * Use Tim's suggestion. Mathieu Bouchard wrote: Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.) Does this mean that rendering/audio in PD will be interrupted during this time of global locking? Ah! I would only need to lock while before I do the PD calls right? Something like: sys_lock(); outlet_symbol(); sys_unlock(); ? Thanks! .b. On Wed, 18 Mar 2009, Tim Blechmann wrote: The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol(). when calling pd's api functions from a separate thread, make sure to hold the global pd lock ... Yes, sorry, I should have known. This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-2613011 ] popup crashes with pd-0.42 and GOP
Bugs item #2613011, was opened at 2009-02-18 16:34 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2613011group_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: IOhannes m zmlnig (zmoelnig) Assigned to: Guenter Geiger (ggeiger) Summary: popup crashes with pd-0.42 and GOP Initial Comment: using [popup] with a brand-new Pd (0.42-4) just crashes when used in a graph-on-parent. to reproduce, put the [popup-gop-test] (taht comes with popup) abstraction into a new patch. this happened on linux and osx. -- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-03-19 17:52 Message: i have submitted (without asking :-() a patch to popup that seems to fix the problem. the segfault happened, because in popup_vis() you were creating an rtext_new() which in turn needed to have a glist _with_ an gl_editor; if the gl_editor was NULL (which happens with 0.42 and gop), rtext_new() segfaults; my fix is to make sure that there is a gl_editor -- Comment By: B. Bogart (bbogart) Date: 2009-02-21 19:15 Message: I can confirm this bug. Looks like [button] from GGEE has the same problem. Guenter, care to take a look? I wonder if g_canvas will ever be public... I guess that they have worked since 2003 is pure luck. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2613011group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-2613011 ] popup crashes with pd-0.42 and GOP
Bugs item #2613011, was opened at 2009-02-18 16:34 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2613011group_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: Fixed Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Guenter Geiger (ggeiger) Summary: popup crashes with pd-0.42 and GOP Initial Comment: using [popup] with a brand-new Pd (0.42-4) just crashes when used in a graph-on-parent. to reproduce, put the [popup-gop-test] (taht comes with popup) abstraction into a new patch. this happened on linux and osx. -- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-03-19 17:53 Message: btw, i don't know whether this is the canonical fix for the problem. it just happens to work... -- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-03-19 17:52 Message: i have submitted (without asking :-() a patch to popup that seems to fix the problem. the segfault happened, because in popup_vis() you were creating an rtext_new() which in turn needed to have a glist _with_ an gl_editor; if the gl_editor was NULL (which happens with 0.42 and gop), rtext_new() segfaults; my fix is to make sure that there is a gl_editor -- Comment By: B. Bogart (bbogart) Date: 2009-02-21 19:15 Message: I can confirm this bug. Looks like [button] from GGEE has the same problem. Guenter, care to take a look? I wonder if g_canvas will ever be public... I guess that they have worked since 2003 is pure luck. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=2613011group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
Hi Ben, if it's just about sending messages to outlets, you could also use a lock-free fifo to queue up the messages (in the second thread) and a timer to send out the elements to the outlets asynchronously (pd thread). That's what flext does internally. gr~~~ Am 19.03.2009 um 17:28 schrieb B. Bogart: Thanks for the comments Tim Mathieu, It seems I have two options: * Not send output to PD (very limited functionality) * Use Tim's suggestion. Mathieu Bouchard wrote: Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.) Does this mean that rendering/audio in PD will be interrupted during this time of global locking? Ah! I would only need to lock while before I do the PD calls right? Something like: sys_lock(); outlet_symbol(); sys_unlock(); ? Thanks! .b. On Wed, 18 Mar 2009, Tim Blechmann wrote: The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol(). when calling pd's api functions from a separate thread, make sure to hold the global pd lock ... Yes, sorry, I should have known. This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ 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] Using PD funcs from inside a threaded external
Thanks for all the comments. I'm now added wrapped outlet calls with sys_lock() and sys_unlock(). The reason I was getting a constant segfault in listconfig (and not in the other functions) was that I was calling the thread function, not the wrapper! So I've checked gphoto into svn, under bbogart. Lots of extra features to add, but this is a decent base that allows a linux user to control a supported PTP camera from PD. Should I put a sys_lock() and sys_unlock() for each post() and error() call? Feel free to tinker with it, writing the TODO now. .b. Mathieu Bouchard wrote: On Thu, 19 Mar 2009, B. Bogart wrote: Mathieu Bouchard wrote: Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.) Does this mean that rendering/audio in PD will be interrupted during this time of global locking? Well, in the same way that when a [delay] or a [metro] outputs a bang it interrupts the rendering. But those events are never nested nor overlapping in real time, so a block always finishes computation before something else happens, and a message sent from [delay] always gets fully processed before something else happens, and so on. It wouldn't be much different from what you'd get if you turned the 2nd thread into a separate server that you'd communicate with using [netsend], really. The only thing is that sometimes, pd runs in the 2nd thread, but that doesn't make so much of a difference, as pd is then not running in the 1st thread at the same time. The question is not which thread is in use, but how many of them at a time. Replacing the lock by a message queue could have had some advantages, but it's more work. Ah! I would only need to lock while before I do the PD calls right? sys_lock(); outlet_symbol(); sys_unlock(); ? Exactly. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] does anyone know of a good Eq I can use?
Hi guys, I was just wondering if anyone knows where I can find a decent 8-band (or greater) Eq patch? I don't need anything too fancy-I tried to make one myself, but I'm still figuring out how the lop~ and hip~ objects work and I'm in kind of a hurry. Thanks-enjoying all your emails very much. babsyco. _ Looking for a place to manage all your online stuff? Explore the new Windows Live . http://www.microsoft.com/australia/windows/windowslive/___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
