Re: [PD] editing puredata.info
On 2010-09-24 20:05, András Murányi wrote: I think it goes by tagging pages that are made elsewhere on the wiki, and 'Software' itself is a script. right. all software projects are listed on the software page. you can add a new software project by clicking on add software project in the top-right corner of the page. dfmar IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
I think that if we could write a Pd = GIMPLE converter (hence a Pd frontend) for gcc, that gcc could do quite a lot of optimization for us. I could be wrong but I have the impression that every message between Pd objects is sent as an abstracted structure and not optimized for architecture to the extent compilers do (could be wrong, but would be positively amazed if I am). This ability would further not only the goals of optimization freaks but also those of dataflow programming in general (stepping into C or other is like admitting -whether correct or not- dataflow is insufficient, at least in practice as long as we cant compile...) Also people would be able to write general software in dataflow languages. Whether it be drivers, pd-developer code, ... We could bootstrap Pd for example, so that users who at first use Pd for audio, then start to code in GEM later could also start to adapt their interface or fix inner workings of Pd, in my view the original poster is a vote towards this end. The opensource fanatics fear could be that software written in Pd, could be shared in a non-opensource way. I have the impression this is the reason none of the devellopers work on this: http://puredata.info/docs/faq/standalone states: This is currently not possible to compile a patch into a binary program. Pd patch files are always plain text and need the Pd program to run. However, the main reason why Max/MSP and similar allow you to create a standalone application is to distribute a patch without having to pay license fees to the distributor. Since Pure Data is Free Software, you can just distribute your patch along with the needed Pd binary. On Mac OS X, Pd-extended 0.41.4 makes it easy to make such a distribution. You can make a standalone .app using the Make app from menu options in the File menu. First it is mentioned that it is currently not possible (without any concrete reference to existant intention or not) Then it inverts the reason why Pd does or does not have this to the reason why Max/MSP have mechanisms to distribute without having to pay the distributor (being Max/MSP?) as opposed to the patch creator? Without speaking for the original poster, I view his question as a desire for compiling dataflow (in his example Pd). He clearly states he searches for a way to do this without having to recode the entire patch (devaluating his original work in Pd itself). That a similar question resides in Frequently (!) Asked Questions confirms my suspicion that there is a user base which would benefit from such possibility. I think as soon as the GIMPLE Front End has materialized enough (currently a Google Summer of Code project) would be a very good time to design a Pd = Gimple converter (Front End). (GIMPLE is the intermediate language AST GCC uses, C++ and other Front Ends convert to GIMPLE so that language independent optimization can take place). I am searching for people who would be interested in helping this make happen, having a list of emails of interested people could be a good start. Every year computer science students around the world have to design a simple compiler in their education programme. Chances are a few of them are interested in Pd already. Some might be allowed to write a Pd front end by their teachers. We Pd users are also not incapable to do this. Lets get together and make this happen! Greetings! On 25 September 2010 20:45, ankur gandhe ankoo...@gmail.com wrote: I was working on a Sound renderer project made in PD and to reduce the latency, we wanted to write the module in C, implementing all the features. Is their a simple way of doing so? If so, please do help Ankur ___ 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
[PD] biquad equation for vcf~?
Hi, I'm trying to convert some PD patches to MaxMSP. However I have a problem with the vcf~ object, it seems it doesnt have an EXACT equivalent in maxmsp: reson~, svf~, and the filtergraph~ bandpass all sound different from vcf~ I'd like to use biquad~ to emulate a vcf~ filter, but I don't have the vcf~ formula to calculate the coefficients. Does somebody know how I can calculate them? As I said filtergraph~, reson~ and the other maxmsp objects are not identical to vcf~ so they are not good for my pourpose. TIA! mau ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
On 2010-09-27 10:38, Ludwig Maes wrote: I think that if we could write a Pd = GIMPLE converter (hence a Pd frontend) for gcc, that gcc could do quite a lot of optimization for us. you might be interested in the Pd compiler presented at nime08: http://nime2008.casapaganini.org/documents/Proceedings/Posters/238.pdf fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] biquad equation for vcf~?
hello, you have some exter to compute biquad~ coef in ggee/filter repertory. i also made some abstraction to compute bq~ coef. you can find them in nusmuk directory in svn. Cyrille Le 27/09/2010 10:34, Maurizio Giri a écrit : Hi, I'm trying to convert some PD patches to MaxMSP. However I have a problem with the vcf~ object, it seems it doesnt have an EXACT equivalent in maxmsp: reson~, svf~, and the filtergraph~ bandpass all sound different from vcf~ I'd like to use biquad~ to emulate a vcf~ filter, but I don't have the vcf~ formula to calculate the coefficients. Does somebody know how I can calculate them? As I said filtergraph~, reson~ and the other maxmsp objects are not identical to vcf~ so they are not good for my pourpose. TIA! mau ___ 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
Re: [PD] GUI speed
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] jMax Phoenix
Jonathan Wilkes wrote: --- On Sun, 9/26/10, Kim Cascone k...@anechoicmedia.com wrote: From: Kim Cascone k...@anechoicmedia.com Subject: Re: [PD] jMax Phoenix To: pd-list pd-list@iem.at Cc: zmoel...@iem.at Date: Sunday, September 26, 2010, 2:52 PM you can make _very_ elegant super-readable control flow with the use of [route] and friends. IOhannes I find this particular subject very interesting I was recently working on a patch using [expr] found the lack of being able to send the results of multiple 'if' statements to the same outlet frustrating - I am also used The reason [expr] doesn't work well in that case is that you must nest multiple if statements, which quickly makes the args hard to decipher. yes I found this out by trying if, then-if, else-if (it would be nice if the help patch would be updated/improved a little with more examples) but also found it hard to decipher when coming back to it later even with copious comments so I used multiple if statements and then tried to deal with the multiple outputs which I did but can't remember off hand how will post the patch at some point I'm on tour now so busy with other things :) to using the Max/MSP [if] object for these sorts of tasks can point me to some examples of using [route] and friends as control statements to check out? thanks! KIM ___ 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
Re: [PD] GUI speed
FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. HTH Ico João Pais jmmmp...@googlemail.com wrote: Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. João ___ 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
Re: [PD] xrun-free file i/o using the coll external (SOLVED)
Here's the cleaned-up and hopefully final version with a couple more
improvements and bugfixes. Sorry for the barrage of sloppy patches...
--- coll.c.orig 2010-09-24 11:16:17.0 -0400
+++ coll.c 2010-09-26 16:21:40.0 -0400
@@ -9,6 +9,8 @@
#include common/loud.h
#include hammer/file.h
+#include pthread.h
+
/* LATER profile for the bottlenecks of insertion and sorting */
/* LATER make sure that ``reentrancy protection hack'' is really working... */
@@ -60,11 +62,34 @@
t_outlet *x_filebangout;
t_outlet *x_dumpbangout;
struct _coll *x_next;
+
+ //for thread-unsafe file i/o operations
+ //added by Ivica Ico Bukvic i...@vt.edu 9-24-2010
+ //http://disis.music.vt.edu http://l2ork.music.vt.edu
+ t_clock *x_clock;
+
+ pthread_t unsafe_t;
+ pthread_mutex_t unsafe_mutex;
+ pthread_cond_t unsafe_cond;
+
+ t_symbol *x_s;
+ t_int unsafe;
} t_coll;
+typedef struct _threadedFunctionParams
+{
+ t_coll *x;
+} t_threadedFunctionParams;
+
static t_class *coll_class;
static t_class *collcommon_class;
+void coll_tick(t_coll *x)
+{
+ //x-busy = 0;
+outlet_bang(x-x_filebangout);
+}
+
static t_collelem *collelem_new(int ac, t_atom *av, int *np, t_symbol *s)
{
t_collelem *ep = (t_collelem *)getbytes(sizeof(*ep));
@@ -201,6 +226,8 @@
}
}
+
+
/* atomic collcommon modifiers: clearall, remove, replace,
putbefore, putafter, swaplinks, swapkeys, changesymkey, renumber, sort */
@@ -621,7 +648,7 @@
t_coll *x;
/* LATER consider making this more robust */
for (x = cc-c_refs; x; x = x-x_next)
- outlet_bang(x-x_filebangout);
+ //outlet_bang(x-x_filebangout);
cc-c_lastcanvas = cv;
cc-c_filename = fn;
post(coll: finished reading %d lines from text file '%s',
@@ -952,234 +979,264 @@
static void coll_float(t_coll *x, t_float f)
{
-t_collcommon *cc = x-x_common;
-t_collelem *ep;
-int numkey;
-if (loud_checkint((t_pd *)x, f, numkey, s_float)
- (ep = collcommon_numkey(cc, numkey)))
-{
- coll_keyoutput(x, ep);
- if (!cc-c_selfmodified || (ep = collcommon_numkey(cc, numkey)))
- coll_dooutput(x, ep-e_size, ep-e_data);
-}
+ //if (!x-busy) {
+ t_collcommon *cc = x-x_common;
+ t_collelem *ep;
+ int numkey;
+ if (loud_checkint((t_pd *)x, f, numkey, s_float)
+ (ep = collcommon_numkey(cc, numkey)))
+ {
+ coll_keyoutput(x, ep);
+ if (!cc-c_selfmodified || (ep = collcommon_numkey(cc, numkey)))
+ coll_dooutput(x, ep-e_size, ep-e_data);
+ }
+ //}
}
static void coll_symbol(t_coll *x, t_symbol *s)
{
-t_collcommon *cc = x-x_common;
-t_collelem *ep;
-if (ep = collcommon_symkey(cc, s))
-{
- coll_keyoutput(x, ep);
- if (!cc-c_selfmodified || (ep = collcommon_symkey(cc, s)))
- coll_dooutput(x, ep-e_size, ep-e_data);
-}
+ //if (!x-busy) {
+ t_collcommon *cc = x-x_common;
+ t_collelem *ep;
+ if (ep = collcommon_symkey(cc, s))
+ {
+ coll_keyoutput(x, ep);
+ if (!cc-c_selfmodified || (ep = collcommon_symkey(cc, s)))
+ coll_dooutput(x, ep-e_size, ep-e_data);
+ }
+ //}
}
static void coll_list(t_coll *x, t_symbol *s, int ac, t_atom *av)
{
-if (ac = 2 av-a_type == A_FLOAT)
- coll_tokey(x, av, ac-1, av+1, 1, s_list);
-else
- loud_messarg((t_pd *)x, s_list);
+ //if (!x-busy) {
+ if (ac = 2 av-a_type == A_FLOAT)
+ coll_tokey(x, av, ac-1, av+1, 1, s_list);
+ else
+ loud_messarg((t_pd *)x, s_list);
+ //}
}
static void coll_anything(t_coll *x, t_symbol *s, int ac, t_atom *av)
{
-coll_symbol(x, s);
+ //if (!x-busy)
+ coll_symbol(x, s);
}
static void coll_store(t_coll *x, t_symbol *s, int ac, t_atom *av)
{
-if (ac = 2)
- coll_tokey(x, av, ac-1, av+1, 1, s);
-else
- loud_messarg((t_pd *)x, s);
+ //if (!x-busy) {
+ if (ac = 2)
+ coll_tokey(x, av, ac-1, av+1, 1, s);
+ else
+ loud_messarg((t_pd *)x, s);
+ //}
}
static void coll_nstore(t_coll *x, t_symbol *s, int ac, t_atom *av)
{
-if (ac = 3)
-{
- t_collcommon *cc = x-x_common;
- t_collelem *ep;
- int numkey;
- if (av-a_type == A_FLOAT av[1].a_type == A_SYMBOL)
- {
- if (loud_checkint((t_pd *)x, av-a_w.w_float, numkey, s))
- {
- if (ep = collcommon_symkey(cc, av[1].a_w.w_symbol))
- collcommon_remove(cc, ep);
- ep = collcommon_tonumkey(cc, numkey, ac-2, av+2, 1);
- ep-e_symkey = av[1].a_w.w_symbol;
- }
- }
- else if (av-a_type == A_SYMBOL av[1].a_type == A_FLOAT)
- {
- if (loud_checkint((t_pd *)x, av[1].a_w.w_float, numkey, s))
- {
- if (ep = collcommon_numkey(cc, numkey))
- collcommon_remove(cc, ep);
- ep = collcommon_tosymkey(cc, av-a_w.w_symbol, ac-2, av+2, 1);
- ep-e_hasnumkey = 1;
- ep-e_numkey = numkey;
- }
- }
- else loud_messarg((t_pd *)x, s);
-}
-else loud_messarg((t_pd *)x, s);
+ //if (!x-busy) {
+ if (ac = 3)
+ {
+ t_collcommon *cc = x-x_common;
+ t_collelem *ep;
+ int numkey;
+ if (av-a_type == A_FLOAT av[1].a_type == A_SYMBOL)
+ {
+ if (loud_checkint((t_pd *)x, av-a_w.w_float, numkey, s))
+ {
+ if (ep
[PD] odd key object behavior under Linux
In my recent troubleshooting saga dealing with xruns and coll object I identified one rather odd behavior that apparently stems from the [key] object. It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] dither8 (tramage)
http://gridflow.ca/gallery/dither8.png http://gridflow.ca/gallery/dither8b.png made with dither.pd (the new version found in GridFlow 9.12) ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] odd key object behavior under Linux
It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] xrun-free file i/o using the coll external (SOLVED)
No need to apologize for sending patches, but I think it would make more sense to submit them to the patch tracker: http://sourceforge.net/tracker/?group_id=55736atid=478072 On Sep 27, 2010, at 9:42 AM, Ivica Ico Bukvic wrote: Sorry for the barrage of sloppy patches... Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] odd key object behavior under Linux
Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.pe...@sympatico.ca wrote: It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys: [image: keytimetest.jpg] strange indeed :) gr, Tim 2010/9/27 Ivica Ico Bukvic i...@vt.edu Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.pe...@sympatico.ca wrote: It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list keytimetest.jpg___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] odd key object behavior under Linux
Yes, the OS also has its own event loop, which might be more responsible for that kind of timing, as it isn't running at a fixed rate and keyboard is probably a lower priority than mouse or network events. Martin Ico wrote: Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.pe...@sympatico.ca wrote: It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ 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
Re: [PD] editing puredata.info
On Mon, Sep 27, 2010 at 10:30 AM, IOhannes m zmoelnig zmoel...@iem.atwrote: On 2010-09-24 20:05, András Murányi wrote: I think it goes by tagging pages that are made elsewhere on the wiki, and 'Software' itself is a script. right. all software projects are listed on the software page. you can add a new software project by clicking on add software project in the top-right corner of the page. dfmar IOhannes I can't see that link (logged in) Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing puredata.info
On Mon, Sep 27, 2010 at 08:41:41PM +0200, András Murányi wrote: I can't see that link (logged in) you are talking about https://puredata.info/software (there it should show up) or https://puredata.info/downloads (there it should not) fgamdsr IOhannes Andras ___ 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
Re: [PD] PureData to C/C++ language
On Mon, 27 Sep 2010, IOhannes m zmoelnig wrote: On 2010-09-27 10:38, Ludwig Maes wrote: I think that if we could write a Pd = GIMPLE converter (hence a Pd frontend) for gcc, that gcc could do quite a lot of optimization for us. you might be interested in the Pd compiler presented at nime08: http://nime2008.casapaganini.org/documents/Proceedings/Posters/238.pdf But where does one download that software ? ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
http://www.media.mit.edu/resenv/PuDAC/sw.html Bottom of the page. On 09/27/2010 10:48 PM, Mathieu Bouchard wrote: On Mon, 27 Sep 2010, IOhannes m zmoelnig wrote: On 2010-09-27 10:38, Ludwig Maes wrote: I think that if we could write a Pd = GIMPLE converter (hence a Pd frontend) for gcc, that gcc could do quite a lot of optimization for us. you might be interested in the Pd compiler presented at nime08: http://nime2008.casapaganini.org/documents/Proceedings/Posters/238.pdf But where does one download that software ? ___ | Mathieu Bouchard -- Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- // ailo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing puredata.info
On Mon, Sep 27, 2010 at 9:22 PM, IOhannes m zmoelnig zmoel...@iem.atwrote: On Mon, Sep 27, 2010 at 08:41:41PM +0200, András Murányi wrote: I can't see that link (logged in) you are talking about https://puredata.info/software (there it should show up) or https://puredata.info/downloads (there it should not) fgamdsr IOhannes https://puredata.info/software which redirects me to https://puredata.info/community/projects/software ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] odd key object behavior under Linux
What is the range of the graph? How many hits is your graph showing? Would this perhaps warrant a small adjustment to Linux code where it checks whether the key of certain type has been outputted in this update and if so, discard repeated occurrence? Best wishes, Ico _ From: tim vets [mailto:timv...@gmail.com] Sent: Monday, September 27, 2010 1:21 PM To: Ivica Ico Bukvic Cc: martin.pe...@sympatico.ca; pd-list@iem.at; pd-...@iem.at Subject: Re: [PD] [PD-dev] odd key object behavior under Linux I got curious, so I did this little test with auto-repeated keys: keytimetest.jpg strange indeed :) gr, Tim 2010/9/27 Ivica Ico Bukvic i...@vt.edu Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.pe...@sympatico.ca wrote: It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list image001.jpg___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI speed
On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmp...@googlemail.com wrote: Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong! On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic i...@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI speed
maybe this is a bug od pd-gui? (well, poor performance *is* a bug) 2010/9/27 András Murányi muran...@gmail.com: On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmp...@googlemail.com wrote: Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong! On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic i...@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack Andras ___ 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
Re: [PD] Arduino, Pd and ultrasonics: HELP needed for degree project!
I am just thinking out of my head,
maybe you could send via serial someting like
IR
and then the ir value, on the PD side you make a route [route IR FX XPTO]
It should rout the data
now i am not sure if it will work just with spaces separating them, or maybe
with CR, but if you have the hardware at hand, should be easy to test.
2010/9/27 Chris Jack itsmrj...@gmail.com
Dear Pd'ers… I'm fairly new to Pd and have been using it during my 'Audio
Production' degree. I'm here to ask for help on my final degree project,
which aims to control objects within Pd by way of proximity sensors
connected to Arduino.
I have had moderate success, first using a Sharp GPD12 IR sensor connected
to an analog port on an Arduino Diecimila, then a Devantech SRF02 connected
via I2C to Arduino. I have managed to get Pure Data reading the sensor
values using the Pure Data example included in SimpleMessageSystem (
http://www.arduino.cc/playground/uploads/Code/SimpleMessageSystem.zip) ...
and only altering the number of the comport the Arduino appears on.
[image: SMS pic.jpg]
On the Arduino end, I have added the SimpleMessageSystem library, and am
using the following sketch to run one or both of the sensors depending on
whether or not I omit the SRF02 or GPD12 parts of the code.
// top //
#include Wire.h
#include Servo.h
#include SimpleMessageSystem.h
int sensorPin = 0;
int sensorValue = 0;
Servo servo1;
#define sensorAddress 0x70
#define readInches 0x50
#define readCentimeters 0x51
#define readMicroseconds 0x52
#define resultRegister 0x02
void setup()
{
Wire.begin();
Serial.begin(9600);
}
void sendCommand (int address, int command) {
Wire.beginTransmission(address);
Wire.send(0x00);
Wire.send(command);
Wire.endTransmission();
}
void setRegister(int address, int thisRegister) {
Wire.beginTransmission(address);
Wire.send(thisRegister);
Wire.endTransmission();
}
int readData(int address, int numBytes) {
int result = 0;
Wire.requestFrom(address, numBytes);
while (Wire.available() 2 );{
}
result = Wire.receive() * 256;
result = result + Wire.receive();
return result;
}
void loop()
{
// SRF02 READING //
sendCommand(sensorAddress, readInches);
delay(70);
setRegister(sensorAddress, resultRegister);
int sensorReading = readData(sensorAddress, 2);
Serial.println(sensorReading);
delay (200);
// GPD12 READING //
sensorValue = analogRead(sensorPin);
int range = (6787 / sensorValue);
Serial.println(range);
delay(200);
}
// bottom //
Pure data is picking up the sensor's output as a decimal number, through
the serial port, correctly, and showing this as a number in the SPECIAL
CHARACTER (note the '80' value in the Pd patch pic that my screen shot
caught) section of the Pd patch, which I can then use to control various Pd
parameters, like a slider for example.
If printing both sensor readings to the serial, the Pd patch will pick up
the two sensor values alternately, but there seems no way of differentiating
the two sensors within Pd, as they both come through the serial. I have
tried prepending the serial print at the Arduino stage with a tag such as
IR or UL for each sensor, but this simply ends up in nothing coming
through in Pd.
Using one sensor gives the ability to control parameters with a fairly
narrow detection range, but for the final version I would like to
incorporate 4 or 5 sensors in order that I can cover nearly a full 360
degree range.
After a bit of research I have gone and bought 4 x Maxsonar EZ0's. They've
got a wider range than the Devantech sensors, and can operate via I2C,
serial or PWM. A number of people online seem to mention the improved
stability when operating via PWM, so I thought this could be kinda useful.
I am going to London Hackspace tomorrow to get help with wiring up the
sensors to my Arduino Diecimila, but for now, my main problem seems to be
how to achieve greater communication between Pure Data and the sensors. It's
all very good and well being able to take the decimal readout from an analog
input to give one set of values in Pd, but I would like to know how to
either to read (and trigger) each sensor discretely via PWM, or to somehow
differentiate between each sensor's analog output, so that I can have the
different sensors controlling different objects within Pd.
As well as SimpleMessageSystem, I looked at using the Pduino object. But to
be honest, it is either not working properly (I have noticed reported issues
with bugginess), or I am being stupid, as it has totally boggled my brain.
In theory though, it seems like it should be able to do what I want, ie.
send and receive commands between Arduino and Pd.
So…. my questions for anyone out there with a knowledge of using Arduino +
multiple sensors (preferably Maxsonar EZ's) with Pd are:
What is
Re: [PD] GUI speed
well, i meant a bug in my patch... what i understood was that it overloaded the CPU on João's box too 2010/9/28 Bernardo Barros bernardobarr...@gmail.com maybe this is a bug od pd-gui? (well, poor performance *is* a bug) 2010/9/27 András Murányi muran...@gmail.com: On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmp...@googlemail.com wrote: Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong! On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic i...@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Muranyi Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI speed
you can post your patch, so maybe we will discover the problem. for the abstraction one solution is to change the name of your hacked abstractions and send them as well. 2010/9/27 András Murányi muran...@gmail.com: well, i meant a bug in my patch... what i understood was that it overloaded the CPU on João's box too 2010/9/28 Bernardo Barros bernardobarr...@gmail.com maybe this is a bug od pd-gui? (well, poor performance *is* a bug) 2010/9/27 András Murányi muran...@gmail.com: On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmp...@googlemail.com wrote: Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong! On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic i...@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Muranyi Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] odd key object behavior under Linux
2010/9/28 Ivica Ico Bukvic i...@vt.edu What is the range of the graph? How many hits is your graph showing? if you're talking about my graph: the actual keyboard autorepeat rate here is at about 30 ms with these mysterious regularly alternating highs and lows. The other peaks in the graph are just where I released a key for a while to choose another test key to hold down. arrow keys show a different result than, say, a letter key... (test done here on Ubuntu 8.04 - the Hardy Heron, Pd version 0.41.4-extended) gr, Tim Would this perhaps warrant a small adjustment to Linux code where it checks whether the key of certain type has been outputted in this update and if so, discard repeated occurrence? Best wishes, Ico -- *From:* tim vets [mailto:timv...@gmail.com] *Sent:* Monday, September 27, 2010 1:21 PM *To:* Ivica Ico Bukvic *Cc:* martin.pe...@sympatico.ca; pd-list@iem.at; pd-...@iem.at *Subject:* Re: [PD] [PD-dev] odd key object behavior under Linux I got curious, so I did this little test with auto-repeated keys: [image: keytimetest.jpg] strange indeed :) gr, Tim 2010/9/27 Ivica Ico Bukvic i...@vt.edu Many thanks for the explanation! What seems weird, however, is how divergent time delta between repeats is. On Windows it is always around 30ms (at least on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. Even when accounting for jitter between two events I cannot imagine that they oscillate that much (unless my flavor of kernel/hardware treats keypress timing like a dirt :-). Best wishes, Ico martin.pe...@sympatico.ca wrote: It probably happens when you get two keydowns in the space of one Pd event loop. The second is output at the same time. The same thing happens with [metro] banging serial data into [comport] or [midiout]. The metro rate is quantized to the event loop rate, so individual bangs are irregularly spaced but the mean time over many bangs is perfect. The only way to get perfect timing is to use signals, messages are always handled after the sound has been computed. So if you don't like it you could slow down your keyboard repeat rate to slower than Pd, or use a microphone to detect the keypresses ;) Martin Ico wrote: It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd-gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list
Re: [PD] GUI speed
Another thing to consider is if you have large GUI objects that are updating quickly (e.g. number2 with huge fonts). This will also potentially tax the cpu. Bernardo Barros bernardobarr...@gmail.com wrote: you can post your patch, so maybe we will discover the problem. for the abstraction one solution is to change the name of your hacked abstractions and send them as well. 2010/9/27 András Murányi muran...@gmail.com: well, i meant a bug in my patch... what i understood was that it overloaded the CPU on João's box too 2010/9/28 Bernardo Barros bernardobarr...@gmail.com maybe this is a bug od pd-gui? (well, poor performance *is* a bug) 2010/9/27 András Murányi muran...@gmail.com: On Mon, Sep 27, 2010 at 11:45 AM, João Pais jmmmp...@googlemail.com wrote: Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure. not much, some abstractions are missing. anyway, even with the patch not working, I can see something is definitively wrong. just by opening it with audio off, I get consistent 50% cpu usage - which means it's using a whole processor of my dual core. unless one of the missing abs is the problem, I would suggest you spend some hours bug tracking. yes, i've spent some nights bug tracking, and at one point i thought ask the list too... :o) something is definitely wrong! On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic i...@vt.edu wrote: FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. yes, i was trying thing like this, and will go on until i find what i messed up. I was just starting to think that it's normal and i have to live with it (or get a few more CPU cores) but now you guys reassured me that the bug is somewhere... in the haystack Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Muranyi Andras ___ 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
Re: [PD] [PD-announce] dither8 (tramage)
are you naked-? Mathieu Bouchard wrote: http://gridflow.ca/gallery/dither8.png http://gridflow.ca/gallery/dither8b.png made with dither.pd (the new version found in GridFlow 9.12) ___ | Mathieu Bouchard -- Villeray, Montréal, QC ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ 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
Re: [PD] Arduino, Pd and ultrasonics: HELP needed for degree project!
hi, i use Messenger instead of Simple Message System: http://www.arduino.cc/playground/Code/Messenger as for sending multiple sensors, just add an identifier: ... sensor1 789 sensor2 345 ... pat ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino, Pd and ultrasonics: HELP needed for degree project!
I've done this a few times adding a char and a space before the value and sorting it out with a [route] The char goes in quotes, and don't forget the space! On Sep 27, 2010, at 10:59 AM, pd-list-requ...@iem.at wrote: // SRF02 READING // sendCommand(sensorAddress, readInches); delay(70); setRegister(sensorAddress, resultRegister); int sensorReading = readData(sensorAddress, 2); Serial.print(s ); Serial.println(sensorReading); delay (200); // GPD12 READING // sensorValue = analogRead(sensorPin); int range = (6787 / sensorValue); Serial.print(r ); Serial.println(range); then in the patch: [comport 8 9600] | [ascii2pd CR] | [route list] | [route s r] Collin collinoldham.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
