Re: [PD] GUI overload
OK, well in fact the problem was not arrays updating. It was all the other GUI
objects (sliders, mknob, num2 etc) that would freeze, and this is running on
GNU/Linux. This was a real problem, since I could change them with the mouse,
but the results of the change were not shown (e.g. the pattern-number in one of
my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually dealing
with is two separate issues, one concerning arrays and another concerning the
rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that Porres
reported. I think its a totally different problem related to Pd-0.43's new
portaudio implementation. It does not affect GNU/Linux, which doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detailaid=3573542group_id=55736atid=478070
Ed, if part of your problem is arrays that stop updating and you're running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I
don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per second down
to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can take
advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) || sys_poll_togui());
}
with:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) + sys_poll_togui());
}
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning idle (zero) so
that sys_poll_togui() never
gets called.
I've also seen a patch's GUI stop updating, but rather than
bewail the fact
that my GUI was dead, my immediate reactions was to be astonished
that the
sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a
recurrent problem as it's hard to say whether the rewrite of the
GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point where the
GUI
objects stop responding in a patch when it is reloaded. I am wondering if
there
is a specific limit to GUI objects that could be changed. I think Pd is
making
some kind of decision that there's too much of this stuff - I'm
gonna prioritize the audio and not worry about it and I'd like to know
how or if it is possible to control this process from within Pd, or by
setting
flags on the command line.
I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers which I
will
not want to program when I am performing. Example patch enclosed to give you
an
idea. The really GUI-intensive objects are the trackers, especially
quadtracker
(which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes,
Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
http://sharktracks.co.uk/
___
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-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-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
Hi Miller, Thank you for your reply. I didn't know there could be such a difference in performance between two ARM chips. It seems very attractive indeed, and i think i'll contact the people at CCRMA to ask about the latency they achieved. If it's low enough i'll definitely give it a try. Cheers, Pierre. 2012/12/17 Miller Puckette m...@ucsd.edu I could be wrong, but I believe the Beagleboard is ARMv7 and the Pi is ARM v6 - so BB could easily have twice the floating-point erformance of Pi. I'm not sure why and whether there would be any difference in Jack for the two. I believe (but am not sure at all) that BB doesn't have the same USB problems the Pi has. All in all it's still a very attractive possibliity, perticularly since the Stanford people have tested and exercised it thoroughly. cheers Miller On Mon, Dec 17, 2012 at 04:38:40PM +0100, Pierre Massat wrote: Dear List, I came accross this Stompbox design workshop ( https://ccrma.stanford.edu/wiki/Stompbox_2011). They use Pd on a beagleboard to make stompboxes. They talk about the older version of the beagleboard with a CPU running at around 700 MHz. This is the same speed as the RPi's. I'm wondering what kind of latency they achieved on the beagleboard. Leaving aside the problem of the lack of audio in, don't you think we should be able to get the same performance on a raspberry pi ? Also, I wonder why JACK runs on the beagleboard and not on the RPi. Cheers, Pierre. ___ 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] Raspberry Pi versus BeagleBoard ?
On Mon, Dec 17, 2012 at 7:35 PM, Miller Puckette m...@ucsd.edu wrote: I could be wrong, but I believe the Beagleboard is ARMv7 and the Pi is ARM v6 - so BB could easily have twice the floating-point erformance of Pi. I'm not sure why and whether there would be any difference in Jack for the two. I believe (but am not sure at all) that BB doesn't have the same USB problems the Pi has. All in all it's still a very attractive possibliity, perticularly since the Stanford people have tested and exercised it thoroughly. Yes, BB has a _LOT_ better performance than RasPi .. Btw, if you want a cheaper board with BB like performance but RasPi like price, look at Cubieboard .. ( http://cubieboard.org/ ) -- buZz ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mastering to vinyl live w/ pd
These are some abstractions I have made that do some of what you are asking...the compressor~ is vanilla. Mastering is primarily about developing golden ears but you also need to take into account the RIAA curve: http://www.tanker.se/lidstrom/riaa.htm Remember it's mechanical - I understand that once the RIAA is taken into account, the most pressing issue is bass - extreme bass and the needle jumps, too much and the track is too wide so you get less time. If it's set up wrong then tracks will overlap (but there could be some interesting jumping record experiments in there. Best, Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ - Original Message - From: Lorenzo Sutton lorenzofsut...@gmail.com To: pd-list@iem.at Cc: Sent: Wednesday, 19 December 2012, 21:23 Subject: Re: [PD] mastering to vinyl live w/ pd On 19/12/12 03:10, me.grimm wrote: does anyone know much about mastering? i dont. anyway i have this record recorder/cutter/lathe and was thinking of doing something like this: http://www.youtube.com/watch?v=TDnpXVUKXM0 Very interesting--- thanks for sharing, I couldn't resist noting (and continuously concentrating) on the ground loop (maybe empathised by the woofer..) I'm not totally sure that was intended though .. which is funny because i have a similar recorder. although i was thinking just cutting in real-time straight from PD. but to get the best sound maybe i could run it through some kind of mastering patch. has anyone made such a thing or know best to do in terms of getting decent masters right from PD? I would think something like: Emulating it as well? I know you lose all the materic thing, but it could be fun. The voice as heard in the video has something fascinating, it would be interesting to find out what modern digital audio compressions (data such as mp3, ogg etc. can create similar suggetions...) Lorenzo. [equilizer~] - but what one? [adaptive/nlms3~]? adaptive_equilization example which im not sure i would know how to use for this | [unauthorized/compressor~] - although there is prob a good vanilla one no? | [expander~] ??? | [exciter~] | [zexy/limiter~] | [hip~ 40] | [lop~ 16000] | [dac~] but i might just make a mess with this m ___ 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 #N canvas 0 0 561 431 10; #X obj 143 40 env~; #X obj 178 160 swap 100; #X obj 178 183 -; #X obj 178 216 dbtorms; #X obj 143 273 line~; #X obj 107 141 moses 0; #X msg 102 160 100; #X obj 107 198 dbtorms; #X obj 124 292 *~; #X obj 220 289 dbtorms; #X msg 135 160 set 0; #X obj 107 179 change; #X obj 124 347 clip~ -0.9 0.9; #X obj 39 79 swap 100; #X obj 39 103 -; #X obj 107 217 pack f 52; #X obj 39 125 * 0.9; #X obj 220 269 + 100; #X obj 124 315 *~ 2.29087; #X obj 124 13 inlet~; #X obj 255 18 inlet; #X obj 124 380 outlet~; #X obj 254 40 route threshm thresh attack decay makeup; #X obj 143 252 pack f 1; #X obj 143 81 - 90; #X text 205 103 The problem with the line~ here is that attacks generate breakpoints \, and hence clicks. Perhaps it needs to be smoothed?; #X connect 0 0 24 0; #X connect 1 0 2 0; #X connect 1 1 2 1; #X connect 2 0 3 0; #X connect 3 0 23 0; #X connect 4 0 8 1; #X connect 5 0 6 0; #X connect 5 1 1 0; #X connect 5 1 10 0; #X connect 6 0 11 0; #X connect 7 0 15 0; #X connect 8 0 18 0; #X connect 9 0 18 1; #X connect 10 0 11 0; #X connect 11 0 7 0; #X connect 12 0 21 0; #X connect 13 0 14 0; #X connect 13 1 14 1; #X connect 14 0 16 0; #X connect 15 0 4 0; #X connect 16 0 17 0; #X connect 17 0 9 0; #X connect 18 0 12 0; #X connect 19 0 0 0; #X connect 19 0 8 0; #X connect 20 0 22 0; #X connect 22 0 13 0; #X connect 22 0 24 1; #X connect 22 1 24 1; #X connect 22 2 23 1; #X connect 22 3 15 1; #X connect 22 4 17 0; #X connect 23 0 4 0; #X connect 24 0 5 0; #N canvas 9 100 1108 575 10; #N canvas 3 50 450 300 route 0; #X obj 110 56 inlet~; #X obj 109 191 outlet~; #X obj 207 192 outlet~; #X obj 228 47 inlet; #X obj 109 124 *~ 1; #X obj 207 124 *~ 0; #X obj 133 100 == 0; #X connect 0 0 4 0; #X connect 0 0 5 0; #X connect 3 0 6 0; #X connect 3 0 5 1; #X connect 4 0 1 0; #X connect 5 0 2 0; #X connect 6 0 4 1; #X restore 59 130 pd route; #N canvas 3 50 450 300 para_eq~ 0; #X obj 116 171 para_bp2~ 1800 1.6 0 200; #X obj 310 117 switch~; #X obj 318 63 inlet; #X obj 144 90 inlet; #X obj 183 90 inlet; #X obj 222 90 inlet; #X obj 115 50 inlet~; #X obj 111 221 outlet~; #X connect 0 0 7 0; #X connect 2 0 1 0; #X connect 3 0 0 1; #X connect 4 0 0 2; #X connect 5 0 0 3; #X connect 6 0 0 0; #X restore 104 252 pd para_eq~; #N canvas 3 50 450 300 para_eq~
Re: [PD] gui-plugin to creat objects
pdsend allows you to send any Pd message that you can send with [send] or [; foo( so you could think of it in terms of how would I do that in Pd? .hc On Dec 19, 2012, at 11:56 PM, Jonathan Wilkes wrote: Yeah but as you mention the connection is tricky so Put menu type messages to pdsend won't cut it. I can't think of a way without making a temporary patch and poisoning the clipboard, so I guess I have to do it in c. :( -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Wednesday, December 19, 2012 10:33 PM Subject: Re: [PD] gui-plugin to creat objects Hmm, probably, but it might be tricky to make the connection. Look at the menu items for the Put menu. Basically you can use the pdsend proc to send messages like dynamic patching. .hc On Dec 19, 2012, at 10:17 PM, Jonathan Wilkes wrote: [bang( | [print hello_world] Is there a way to generate the object chain above in a gui-plugin and have it hanging from the mouse cursor? -Jonathan ___ 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] Raspberry Pi versus BeagleBoard ?
Hi, I wrote an e-mail to the guys who made the Satellite CCRMA image for the BB, asking about latency and quality of the built-in audio interface. I didn't get a reply to any of these questions, so I guess i'll have to buy one and figure out myself. One interesting news though is that they are preparing an image for the Raspberry Pi. It should be the first image for this machine optimized for audio, beside the Raspbian image recently tweaked by Miller Puckette. And finally, just so you know : I haven't published about it, but I can safely say that if you don't use the satellite CCRMA images, you will be sorry later on down the road. As far as I know, no one else is bothering to make good images. I'm not sure what to make of these statements ;) Cheers, Pierre. 2012/12/20 Bastiaan van den Berg b...@spacedout.nl On Mon, Dec 17, 2012 at 7:35 PM, Miller Puckette m...@ucsd.edu wrote: I could be wrong, but I believe the Beagleboard is ARMv7 and the Pi is ARM v6 - so BB could easily have twice the floating-point erformance of Pi. I'm not sure why and whether there would be any difference in Jack for the two. I believe (but am not sure at all) that BB doesn't have the same USB problems the Pi has. All in all it's still a very attractive possibliity, perticularly since the Stanford people have tested and exercised it thoroughly. Yes, BB has a _LOT_ better performance than RasPi .. Btw, if you want a cheaper board with BB like performance but RasPi like price, look at Cubieboard .. ( http://cubieboard.org/ ) -- buZz ___ 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] Raspberry Pi versus BeagleBoard ?
I just tried out the latency.pd patch in 7.stuff/tools on my beagleboard and [timer] shifts between 72.5 and 75.4, if this answers your question. I've attended a workshop on the BB with Pd by the buys at CCRMA, it was a rather nice one. On Thu, Dec 20, 2012 at 4:54 PM, Pierre Massat pimas...@gmail.com wrote: Hi, I wrote an e-mail to the guys who made the Satellite CCRMA image for the BB, asking about latency and quality of the built-in audio interface. I didn't get a reply to any of these questions, so I guess i'll have to buy one and figure out myself. One interesting news though is that they are preparing an image for the Raspberry Pi. It should be the first image for this machine optimized for audio, beside the Raspbian image recently tweaked by Miller Puckette. And finally, just so you know : I haven't published about it, but I can safely say that if you don't use the satellite CCRMA images, you will be sorry later on down the road. As far as I know, no one else is bothering to make good images. I'm not sure what to make of these statements ;) Cheers, Pierre. 2012/12/20 Bastiaan van den Berg b...@spacedout.nl On Mon, Dec 17, 2012 at 7:35 PM, Miller Puckette m...@ucsd.edu wrote: I could be wrong, but I believe the Beagleboard is ARMv7 and the Pi is ARM v6 - so BB could easily have twice the floating-point erformance of Pi. I'm not sure why and whether there would be any difference in Jack for the two. I believe (but am not sure at all) that BB doesn't have the same USB problems the Pi has. All in all it's still a very attractive possibliity, perticularly since the Stanford people have tested and exercised it thoroughly. Yes, BB has a _LOT_ better performance than RasPi .. Btw, if you want a cheaper board with BB like performance but RasPi like price, look at Cubieboard .. ( http://cubieboard.org/ ) -- buZz ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui-plugin to creat objects
FWIW pd-l2ork already has create object from an abstraction (used in K12 mode with buttons in the menu linking to various abstractions). As soon as you create an object, provided it is not autopatched, it follows mouse as soon as the pointer enters the canvas area. This could be easily repurposed to create code chunks like the one you proposed... On 12/20/2012 09:14 AM, Hans-Christoph Steiner wrote: pdsend allows you to send any Pd message that you can send with [send] or [; foo( so you could think of it in terms of how would I do that in Pd? .hc On Dec 19, 2012, at 11:56 PM, Jonathan Wilkes wrote: Yeah but as you mention the connection is tricky so Put menu type messages to pdsend won't cut it. I can't think of a way without making a temporary patch and poisoning the clipboard, so I guess I have to do it in c. :( -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Wednesday, December 19, 2012 10:33 PM Subject: Re: [PD] gui-plugin to creat objects Hmm, probably, but it might be tricky to make the connection. Look at the menu items for the Put menu. Basically you can use the pdsend proc to send messages like dynamic patching. .hc On Dec 19, 2012, at 10:17 PM, Jonathan Wilkes wrote: [bang( | [print hello_world] Is there a way to generate the object chain above in a gui-plugin and have it hanging from the mouse cursor? -Jonathan ___ 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 -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
Wow! Are you using their satellite distro ? What version of the beagleboard are you using ? 72 ms is definitely unusable for realtime effects. I can't seem to find any info about the latency they achieve and this is a bit strange. A low latency is a sine qua non condition if one wants to build a stompbox. Cheers, Pierre. 2012/12/20 Alexandros Drymonitis adr...@gmail.com I just tried out the latency.pd patch in 7.stuff/tools on my beagleboard and [timer] shifts between 72.5 and 75.4, if this answers your question. I've attended a workshop on the BB with Pd by the buys at CCRMA, it was a rather nice one. On Thu, Dec 20, 2012 at 4:54 PM, Pierre Massat pimas...@gmail.com wrote: Hi, I wrote an e-mail to the guys who made the Satellite CCRMA image for the BB, asking about latency and quality of the built-in audio interface. I didn't get a reply to any of these questions, so I guess i'll have to buy one and figure out myself. One interesting news though is that they are preparing an image for the Raspberry Pi. It should be the first image for this machine optimized for audio, beside the Raspbian image recently tweaked by Miller Puckette. And finally, just so you know : I haven't published about it, but I can safely say that if you don't use the satellite CCRMA images, you will be sorry later on down the road. As far as I know, no one else is bothering to make good images. I'm not sure what to make of these statements ;) Cheers, Pierre. 2012/12/20 Bastiaan van den Berg b...@spacedout.nl On Mon, Dec 17, 2012 at 7:35 PM, Miller Puckette m...@ucsd.edu wrote: I could be wrong, but I believe the Beagleboard is ARMv7 and the Pi is ARM v6 - so BB could easily have twice the floating-point erformance of Pi. I'm not sure why and whether there would be any difference in Jack for the two. I believe (but am not sure at all) that BB doesn't have the same USB problems the Pi has. All in all it's still a very attractive possibliity, perticularly since the Stanford people have tested and exercised it thoroughly. Yes, BB has a _LOT_ better performance than RasPi .. Btw, if you want a cheaper board with BB like performance but RasPi like price, look at Cubieboard .. ( http://cubieboard.org/ ) -- buZz ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
Am 20.12.2012 um 16:09 schrieb Alexandros Drymonitis adr...@gmail.com: I just tried out the latency.pd patch in 7.stuff/tools on my beagleboard and [timer] shifts between 72.5 and 75.4, if this answers your question. I've attended a workshop on the BB with Pd by the buys at CCRMA, it was a rather nice one. AFAIK you also need to say what the delay setting was in the audio properties of Pd. It makes a difference for the numbers you get. m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
Yup, I'm using their distro as I got it from them at the workshop. Not sure which version it is, the workshop took place last June, so it shouldn't be old... Building a stombox out of a machine as powerful as a smart phone...dunno. Edgar Berahl himself said that the BB is as powerful as an iPhone 4, or something. How much could it take?...And we did have some CPU issues during the workshop, especially with [expr~].. On Thu, Dec 20, 2012 at 5:15 PM, Pierre Massat pimas...@gmail.com wrote: Wow! Are you using their satellite distro ? What version of the beagleboard are you using ? 72 ms is definitely unusable for realtime effects. I can't seem to find any info about the latency they achieve and this is a bit strange. A low latency is a sine qua non condition if one wants to build a stompbox. Cheers, Pierre. 2012/12/20 Alexandros Drymonitis adr...@gmail.com I just tried out the latency.pd patch in 7.stuff/tools on my beagleboard and [timer] shifts between 72.5 and 75.4, if this answers your question. I've attended a workshop on the BB with Pd by the buys at CCRMA, it was a rather nice one. On Thu, Dec 20, 2012 at 4:54 PM, Pierre Massat pimas...@gmail.comwrote: Hi, I wrote an e-mail to the guys who made the Satellite CCRMA image for the BB, asking about latency and quality of the built-in audio interface. I didn't get a reply to any of these questions, so I guess i'll have to buy one and figure out myself. One interesting news though is that they are preparing an image for the Raspberry Pi. It should be the first image for this machine optimized for audio, beside the Raspbian image recently tweaked by Miller Puckette. And finally, just so you know : I haven't published about it, but I can safely say that if you don't use the satellite CCRMA images, you will be sorry later on down the road. As far as I know, no one else is bothering to make good images. I'm not sure what to make of these statements ;) Cheers, Pierre. 2012/12/20 Bastiaan van den Berg b...@spacedout.nl On Mon, Dec 17, 2012 at 7:35 PM, Miller Puckette m...@ucsd.edu wrote: I could be wrong, but I believe the Beagleboard is ARMv7 and the Pi is ARM v6 - so BB could easily have twice the floating-point erformance of Pi. I'm not sure why and whether there would be any difference in Jack for the two. I believe (but am not sure at all) that BB doesn't have the same USB problems the Pi has. All in all it's still a very attractive possibliity, perticularly since the Stanford people have tested and exercised it thoroughly. Yes, BB has a _LOT_ better performance than RasPi .. Btw, if you want a cheaper board with BB like performance but RasPi like price, look at Cubieboard .. ( http://cubieboard.org/ ) -- buZz ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
15 ms, by default, meaning I never touched it, maybe Edgar did the whole setup. On Thu, Dec 20, 2012 at 5:16 PM, Max abonneme...@revolwear.com wrote: Am 20.12.2012 um 16:09 schrieb Alexandros Drymonitis adr...@gmail.com: I just tried out the latency.pd patch in 7.stuff/tools on my beagleboard and [timer] shifts between 72.5 and 75.4, if this answers your question. I've attended a workshop on the BB with Pd by the buys at CCRMA, it was a rather nice one. AFAIK you also need to say what the delay setting was in the audio properties of Pd. It makes a difference for the numbers you get. m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
Hm, ok. So if it's the satellite distro then Pd should run in rt with JACK, which means that the latency you mention is fairly close to the minimum one can get. Am I wrong ? Even 50 ms is unusable for a realtime effect processor. Why call it a stompbox workshop then ? :( Thank you Alexandros! 2012/12/20 Alexandros Drymonitis adr...@gmail.com 15 ms, by default, meaning I never touched it, maybe Edgar did the whole setup. On Thu, Dec 20, 2012 at 5:16 PM, Max abonneme...@revolwear.com wrote: Am 20.12.2012 um 16:09 schrieb Alexandros Drymonitis adr...@gmail.com: I just tried out the latency.pd patch in 7.stuff/tools on my beagleboard and [timer] shifts between 72.5 and 75.4, if this answers your question. I've attended a workshop on the BB with Pd by the buys at CCRMA, it was a rather nice one. AFAIK you also need to say what the delay setting was in the audio properties of Pd. It makes a difference for the numbers you get. m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Webcam recommendations (linux/osx)
- USB cam like PSEye or logitech (don't remember equivalent model to PSEye but it exists) : pros : could have good image quality, framerate and resolution, cons : cable lenght limitation, mostly fixed lens and sometimes fixed focus I'd be interested in hearing about this logitech equivalent. How is it equivalent? also has high frame rates? about the length of usb cables, you can get a long extender with an amplifier and even chain them. best, J 2012/12/20 Dario Pedrioli dariopedri...@gmail.com: We use too PS3-eye webcams on Linux for various IR input management (we don't output the input image) For our installation we have modified the lens part:removed original lens and replaced with a new one M12x0.5 lens mount + a set of cheap M12 for various distance. Image quality is not the best you can have but you have a great camera for less than 100 euro (including modifications) considering high framerate - very important for us. Ciao Dario ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
Hi, just so people know, there is some hardware, not open, but way more powerful available for cheap: look for MK808 tv box on geekbuying. Dual arm cortex A9 running Android, 1GB ram, at less than 60USD. Maybe can pd runs on these. Pierre Massat wrote: Dear List, I came accross this Stompbox design workshop ( https://ccrma.stanford.edu/wiki/Stompbox_2011). They use Pd on a beagleboard to make stompboxes. They talk about the older version of the beagleboard with a CPU running at around 700 MHz. This is the same speed as the RPi's. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi versus BeagleBoard ?
One thing to remember with all these boards is that ARM boards are not PCs. That means that they are not easily interchangeable. There is not standardized techniques for booting, for example. That means you better be sure you can get the distro that you want running on that board. A Debian image running on a Beagleboard most likely will not boot on a RPi or the MK808. .hc On Dec 20, 2012, at 10:36 AM, Charles Goyard wrote: Hi, just so people know, there is some hardware, not open, but way more powerful available for cheap: look for MK808 tv box on geekbuying. Dual arm cortex A9 running Android, 1GB ram, at less than 60USD. Maybe can pd runs on these. Pierre Massat wrote: Dear List, I came accross this Stompbox design workshop ( https://ccrma.stanford.edu/wiki/Stompbox_2011). They use Pd on a beagleboard to make stompboxes. They talk about the older version of the beagleboard with a CPU running at around 700 MHz. This is the same speed as the RPi's. ___ 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 overload
It seems that there are a number of issues here:
* GUI objects sending every update, regardless of change (fixed)
* arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows,
and it looks like only Mac OS X is affected
* all GUI activity stopping related to:
return (sys_domicrosleep(0, 1) || sys_poll_togui())
* GUI objects sending updates to GUI as fast as they receive them even tho the
screen will never update faster than every ~10ms.
* some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in
realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the other
GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running
on GNU/Linux. This was a real problem, since I could change them with the
mouse, but the results of the change were not shown (e.g. the pattern-number
in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually dealing
with is two separate issues, one concerning arrays and another concerning the
rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that Porres
reported. I think its a totally different problem related to Pd-0.43's new
portaudio implementation. It does not affect GNU/Linux, which doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detailaid=3573542group_id=55736atid=478070
Ed, if part of your problem is arrays that stop updating and you're running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I
don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per second down
to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can take
advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) || sys_poll_togui());
}
with:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) + sys_poll_togui());
}
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning idle (zero) so
that sys_poll_togui() never
gets called.
I've also seen a patch's GUI stop updating, but rather than
bewail the fact
that my GUI was dead, my immediate reactions was to be astonished
that the
sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a
recurrent problem as it's hard to say whether the rewrite of the
GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point where the
GUI
objects stop responding in a patch when it is reloaded. I am wondering if
there
is a specific limit to GUI objects that could be changed. I think Pd is
making
some kind of decision that there's too much of this stuff - I'm
gonna prioritize the audio and not worry about it and I'd like to know
how or if it is possible to control this process from within Pd, or by
setting
flags on the command line.
I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers which I
will
not want to program when I am performing. Example patch enclosed to give you
an
idea. The really GUI-intensive objects are the trackers, especially
quadtracker
(which I think has pushed the GUI of Pd patches about as far as I can go
now).
System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes,
Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
http://sharktracks.co.uk/
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
Re: [PD] [PD-announce] Pd group in Athens
No worries for the highjack Lorenzo and thanks for your wishes. Unfortunately it seems that people in Athens are using Max too, as I got no replies and till now I've found something like four people. I guess that I'll have to manage without a Pd group for now. Cheers On 12 Δεκ 2012, at 11:40, Lorenzo Sutton lorenzofsut...@gmail.com wrote: On 12/12/12 08:09, Alexandros Drymonitis wrote: Hi list, I'd like to call people who reside in Athens and use Pd of course to form a group so we can make regular meetups and all. I'm willing to organize things (arrange dates and places for the meetups, invite people, suggest discussion/presentation subjects etc.). It would be nice if Athenian Pders get active as a community, we could all benefit from it. Alexandros, I wish you all the best luck!! I'd love to have something like that over here, but it seems everyone uses using max/msp (on a mac) here in Italy, at least in Rome. :/ Sorry for hijacking the thread :) Lorenzo ___ 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] Pd group in Athens
We've had good luck in NYC having a mixed Pd+Max meeting. They are both quite similar, and so many people use both. I'm curious to hear what the Athens Pders and Maxers have to say about the Greek UI in Pd-extended 0.43. .hc On Dec 20, 2012, at 2:17 PM, adr...@gmail.com wrote: No worries for the highjack Lorenzo and thanks for your wishes. Unfortunately it seems that people in Athens are using Max too, as I got no replies and till now I've found something like four people. I guess that I'll have to manage without a Pd group for now. Cheers On 12 Δεκ 2012, at 11:40, Lorenzo Sutton lorenzofsut...@gmail.com wrote: On 12/12/12 08:09, Alexandros Drymonitis wrote: Hi list, I'd like to call people who reside in Athens and use Pd of course to form a group so we can make regular meetups and all. I'm willing to organize things (arrange dates and places for the meetups, invite people, suggest discussion/presentation subjects etc.). It would be nice if Athenian Pders get active as a community, we could all benefit from it. Alexandros, I wish you all the best luck!! I'd love to have something like that over here, but it seems everyone uses using max/msp (on a mac) here in Italy, at least in Rome. :/ Sorry for hijacking the thread :) Lorenzo ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI overload
OK... I've pushed a change that seems to have fixed the arrays-atop-updating
problem (at lest in the Brane example). Not sure if I should also commit the
return (sys_domicrosleep(0, 1) || sys_poll_togui()) --- + change
as well (somehow I think it should never be necessary to do that but I'm
realizing how little I understand Pd's scheduler.)
cheers
M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote:
It seems that there are a number of issues here:
* GUI objects sending every update, regardless of change (fixed)
* arrays stop updating on Mac OS X (pinpointed) I just tested this on
Windows, and it looks like only Mac OS X is affected
* all GUI activity stopping related to:
return (sys_domicrosleep(0, 1) || sys_poll_togui())
* GUI objects sending updates to GUI as fast as they receive them even tho
the screen will never update faster than every ~10ms.
* some GUI updates send lots of raw Tcl code to be parsed, compiled, and run
in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the other
GUI objects (sliders, mknob, num2 etc) that would freeze, and this is
running on GNU/Linux. This was a real problem, since I could change them
with the mouse, but the results of the change were not shown (e.g. the
pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually
dealing with is two separate issues, one concerning arrays and another
concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that Porres
reported. I think its a totally different problem related to Pd-0.43's
new
portaudio implementation. It does not affect GNU/Linux, which doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detailaid=3573542group_id=55736atid=478070
Ed, if part of your problem is arrays that stop updating and you're
running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I
don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per second down
to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can take
advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) || sys_poll_togui());
}
with:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) + sys_poll_togui());
}
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning idle (zero) so
that sys_poll_togui() never
gets called.
I've also seen a patch's GUI stop updating, but rather than
bewail the fact
that my GUI was dead, my immediate reactions was to be astonished
that the
sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a
recurrent problem as it's hard to say whether the rewrite of the
GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point where
the GUI
objects stop responding in a patch when it is reloaded. I am wondering if
there
is a specific limit to GUI objects that could be changed. I think Pd is
making
some kind of decision that there's too much of this stuff - I'm
gonna prioritize the audio and not worry about it and I'd like to know
how or if it is possible to control this process from within Pd, or by
setting
flags on the command line.
I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers which
I will
not want to program when I am performing. Example patch enclosed to give
you an
idea. The really GUI-intensive objects are the trackers, especially
quadtracker
Re: [PD] GUI overload
Miller,
Pd-l2ork has this fix since your original post on the PD list and I've yet
to see any regressions. Many thanks for the suggestion. That said, I've yet
to understand the logic behind it ;-).
P.S. I also discovered quite a while ago that netreceive had a tendency to
freeze GUI permanently, likely due to asynchronous message processing. I
fixed this by enqueuing its messages and syncing them with the main PD
loop. This has been a part of pd-l2ork for over a year without a single GUI
freeze. That said, I did encounter situations where high traffic would
freeze GUI temporarily and then resume (albeit running now behind the
actual timeline as the GUI would simply resume as if nothing happened,
rather than processing all calls that have piled up since the temporary
freeze happened and for which time has already passed, e.g. having a timer
in a score that freezes and then resumes from the moment it was stuck
rather than adding seconds lost since such calls should've been enqueued
while the freeze was in effect). This may have been in part due to atom
cpus being taxed to their very limits. I've yet to see whether your
proposed fix resolves the lingering issue.
HTH
Best wishes,
Ico
On Dec 20, 2012 7:02 PM, Miller Puckette m...@ucsd.edu wrote:
OK... I've pushed a change that seems to have fixed the
arrays-atop-updating
problem (at lest in the Brane example). Not sure if I should also commit
the
return (sys_domicrosleep(0, 1) || sys_poll_togui()) --- + change
as well (somehow I think it should never be necessary to do that but I'm
realizing how little I understand Pd's scheduler.)
cheers
M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote:
It seems that there are a number of issues here:
* GUI objects sending every update, regardless of change (fixed)
* arrays stop updating on Mac OS X (pinpointed) I just tested this on
Windows, and it looks like only Mac OS X is affected
* all GUI activity stopping related to:
return (sys_domicrosleep(0, 1) || sys_poll_togui())
* GUI objects sending updates to GUI as fast as they receive them even
tho the screen will never update faster than every ~10ms.
* some GUI updates send lots of raw Tcl code to be parsed, compiled, and
run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the
other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is
running on GNU/Linux. This was a real problem, since I could change them
with the mouse, but the results of the change were not shown (e.g. the
pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually
dealing with is two separate issues, one concerning arrays and another
concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that
Porres
reported. I think its a totally different problem related to
Pd-0.43's new
portaudio implementation. It does not affect GNU/Linux, which
doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detailaid=3573542group_id=55736atid=478070
Ed, if part of your problem is arrays that stop updating and you're
running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i
mean, I
don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per
second down
to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner
wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that
gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can
take
advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) || sys_poll_togui());
}
with:
int sys_pollgui(void)
{
return (sys_domicrosleep(0, 1) + sys_poll_togui());
}
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning idle (zero) so
that sys_poll_togui() never
gets called.
Re: [PD] GUI overload
My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal definition of what working correctly should consist of :) M On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote: Miller, Pd-l2ork has this fix since your original post on the PD list and I've yet to see any regressions. Many thanks for the suggestion. That said, I've yet to understand the logic behind it ;-). P.S. I also discovered quite a while ago that netreceive had a tendency to freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single GUI freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a timer in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue. HTH Best wishes, Ico On Dec 20, 2012 7:02 PM, Miller Puckette m...@ucsd.edu wrote: OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also commit the return (sys_domicrosleep(0, 1) || sys_poll_togui()) --- + change as well (somehow I think it should never be necessary to do that but I'm realizing how little I understand Pd's scheduler.) cheers M On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote: It seems that there are a number of issues here: * GUI objects sending every update, regardless of change (fixed) * arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected * all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui()) * GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms. * some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime .hc On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote: OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers). Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI. Ed I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows. https://sourceforge.net/tracker/?func=detailaid=3573542group_id=55736atid=478070 Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you. .hc On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote: OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd. Reducing the average volume of trafic won't solve the underlying problem, it will just make it harder to recreate it :) M On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote: I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs. .hc On 12/16/2012 01:47 PM, Miller Puckette wrote: This is just a guess... in s_inter.c, try replacing:
