Re: [PD] [GEM-dev] Timing and PD....
helo, i'm also having this kind of problem. specially when loading a picture in pix_image. i think the best would be the have a bang when things are ready... C B. Bogart a écrit : Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. This approach is not very scalable. I find myself using the timer object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. What is the long-term solution for PD to solve these issues? Should all objects that introduce a delay send a bang when they are complete? (for example pix_buffer? Of course an additional delay occurs when when the pix_buffer is written to memory and when it gets to the gfx card for display. I'm banging my head over these issues a lot lately and wonder if there is a better approach. Back to attempting kludging a solution. .b. ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
hello, thanks all for your answer. i fact, i've got only 1 /dev/midi* device when i plug my interface. so the problem does not really come from pd. did anyone succesfully using multiple in / out usb/midi interface under linux (ubuntu)? thx Cyrille patco a écrit : hello, you might want to try to create a symlink to your other midi ports? http://lists.puredata.info/pipermail/pd-list/2007-08/052968.html Le mercredi 29 octobre 2008 à 20:02 +0100, cyrille henry a écrit : hello, i've got a usb / midi device with 2 in and 2 out (bcf2000 by example, but i've got the same problem with other hardware). With pd/linux (ubuntu), i can't use the 2nd in / out : just the 1st one is usable. does anyone know how to use device with multiple midi in / out? thanks Cyrille ___ 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] Timing and PD....
hi ben B. Bogart wrote: Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. do you mean you are using buffers and delays to distribute the workload over time, in order to not get cpu peaks? This approach is not very scalable. I find myself using the timer object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) i am not sure i understand you here. it seems like you are having problem to synchronize 2 threads (e.g. the main Pd thread an an image-loading thread). if everything is done in a single thread, then no timing problems should occur, as everything will happen in 0 logical time (though it might block the main thread considerably long so that the patch will stutter). if multiple threads are involved (e.g. to avoid the stuttering), then you might experience problems where you try to access images before they are actually loaded. when using [pix_buffer] to load images with the [open $1( message, then afair, everything will be in a single thread. thus, no timing problems should occur. using [pix_image] to load images will default to using threads (if available), at least on linux. you can turn this off by sending a [thread 0( message to [pix_image]. it would be interesting to see examples that expose your problem. A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. the solution is timestamps. (which i think [pix_share] doesn't have right now...) I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. sorry to give specific answers. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
cyrille henry wrote: hello, thanks all for your answer. i fact, i've got only 1 /dev/midi* device when i plug my interface. so the problem does not really come from pd. did anyone succesfully using multiple in / out usb/midi interface under linux (ubuntu)? yes i am (i think) my solution is: - use alsa-midi (forget about /dev/midi*) - open 2 alsa-midi ports from Pd - connect your 2 hw-devices to the Pd's 2 alsa-midi ports (i usually conveniently use qjackctl for this; but you can do so by using [aconnect] as well) - access the device connected to Pd's 1st port via channel1-16 and the device connected to the 2nd port via channel17-32 - scale at will fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
cyrille henry wrote: hello, IOhannes m zmoelnig a écrit : cyrille henry wrote: hello, thanks all for your answer. i fact, i've got only 1 /dev/midi* device when i plug my interface. so the problem does not really come from pd. did anyone succesfully using multiple in / out usb/midi interface under linux (ubuntu)? yes i am (i think) my solution is: - use alsa-midi (forget about /dev/midi*) ok. aconnect -o and -i can see both output and input of my BCF, so it's certainly the way to go. - open 2 alsa-midi ports from Pd i don't really understand. did you mean that i should create 2 virtual midi device, and open them with pd? or should i have something in my pd midi configuration. the latter. starting Pd with pd -alsamidi 1,1 (apologies for the weird syntax), should give you 2 midi-in ports and 2 midi-out ports. you can also select alsamidi via the media-menu, and chose the number of ports you want. fmgasdrt IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
IOhannes m zmoelnig wrote: the latter. starting Pd with pd -alsamidi 1,1 (apologies for the weird syntax), should give you 2 midi-in ports and 2 midi-out ports. you can also select alsamidi via the media-menu, and chose the number of ports you want. btw, i've updated the aconnectgui patch in externals/iem/aconnect that provides a graphical interface to change connections (from within Pd). you can now modify the number of midi-ports Pd provides from within this patch. (it doesn't set the midi-API to ALSA by itself though) fg,adsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] DL.1 Digital Light and pure data
hello, did anybody work on controlling a dl1 projector via pd ? it is dmx controllable. http://www.highend.com/products/digital_lighting/dl_1.asp thx + best erich - http://randomseed.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
IOhannes m zmoelnig a écrit : ... the latter. starting Pd with pd -alsamidi 1,1 (apologies for the weird syntax), should give you 2 midi-in ports and 2 midi-out ports. -alsamidi did not work here (got same result than pd -help) you can also select alsamidi via the media-menu, and chose the number of ports you want. i don't have this choice in the media menu. i'm using vanillia pd 0.41.4. is there any specific configuration before compilation? should i install some lib? or is it only with pd-extended? thanks Cyrille fmgasdrt IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
cyrille henry wrote: IOhannes m zmoelnig a écrit : ... the latter. starting Pd with pd -alsamidi 1,1 (apologies for the weird syntax), should give you 2 midi-in ports and 2 midi-out ports. -alsamidi did not work here (got same result than pd -help) you can also select alsamidi via the media-menu, and chose the number of ports you want. i don't have this choice in the media menu. i'm using vanillia pd 0.41.4. you need alsa-headers in order to have alsamidi. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
Hi Roman, On Thu, 2008-10-30 at 01:46 +0100, Roman Haefeli wrote: unfortunately, there are cases, where there are interferences between both threads; for instance when moving around an array with 1'000'000 elements. i get clicks when i open a subpatch containing a big array, but not when opening a subpatch containing only message boxes and objects. The sub patches contain the elements of a auxillary return channel strip nothing more. A DSP, other (9 other) auxillary sends, pan, volume, gain. For this to be nicely modelled I have built sub patches contained within sub patches. I never thought this would be a problem. Has anyone else experienced this sort of behaviour of PD with a similar type patch. I can send you my patch if you like ... I need to find out if the problem lies with PD or my setup particularly. Conor ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Timing and PD....
I agree. I think for any indeterminate operation, like anything in a separate thread, there should be a bang when that operation is complete. That way you can guarantee that things are ready when you run a process. If you want to make sure that things will be there on time, then these threaded/indeterminate operations should run well in advance. Using guesswork and delays is not a real solution... .hc On Oct 30, 2008, at 4:25 AM, cyrille henry wrote: helo, i'm also having this kind of problem. specially when loading a picture in pix_image. i think the best would be the have a bang when things are ready... C B. Bogart a écrit : Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. This approach is not very scalable. I find myself using the timer object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. What is the long-term solution for PD to solve these issues? Should all objects that introduce a delay send a bang when they are complete? (for example pix_buffer? Of course an additional delay occurs when when the pix_buffer is written to memory and when it gets to the gfx card for display. I'm banging my head over these issues a lot lately and wonder if there is a better approach. Back to attempting kludging a solution. .b. ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd tools for syncing to video
Hey all, I am currently working on another sound design project to be synced to video, so I am further developing some tools to make it easy to programmatically sync the sounds to the video, using frame numbers as the reference. So I have made a framesyncplayer~ and framesynclooper~ that use frame numbers as start/stop play points, and only play while the frame counter is running (attached). I was wondering whether anyone else has done anything along these lines? I am trying to figure out the best approach for building a library for this kind of stuff. .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd tools for syncing to video
Doh, it might help if I actually attached the files: framesynclooper~.pd Description: Binary data framesyncplayer~.pd Description: Binary data .hc On Oct 30, 2008, at 11:00 AM, Hans-Christoph Steiner wrote: Hey all, I am currently working on another sound design project to be synced to video, so I am further developing some tools to make it easy to programmatically sync the sounds to the video, using frame numbers as the reference. So I have made a framesyncplayer~ and framesynclooper~ that use frame numbers as start/stop play points, and only play while the frame counter is running (attached). I was wondering whether anyone else has done anything along these lines? I am trying to figure out the best approach for building a library for this kind of stuff. .hc -- -- News is what people want to keep hidden and everything else is publicity. - Bill Moyers [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] usb midi device
hello, i can't test right now, but i now have alsa-midi. aconnect can see pd, so i think i'll will be ok. thanks a lot Cyrille IOhannes m zmoelnig a écrit : cyrille henry wrote: IOhannes m zmoelnig a écrit : ... the latter. starting Pd with pd -alsamidi 1,1 (apologies for the weird syntax), should give you 2 midi-in ports and 2 midi-out ports. -alsamidi did not work here (got same result than pd -help) you can also select alsamidi via the media-menu, and chose the number of ports you want. i don't have this choice in the media menu. i'm using vanillia pd 0.41.4. you need alsa-headers in order to have alsamidi. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] line~ for syncing to video
I am trying to make a version of [line~] that gives me a line based on the frame numbers I give it. Basically, I give it a frame counter in the first inlet, then start frame and stop frame as arguments. The hard part is that I want it to behave like [line] in that the last value stays in effect until something else overrides it. How do I do that with DSP data? If I use [switch~], then the [outlet~] will just retain its last value. .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PD, arduino and sharp range detectors
Hi All, We are having trouble with a PD - Arduino - Sharp IR gp2d12 IR range sensor. everything works for a while, then the arduino just stops and sometimes takes PD down with it. once we had a warning from the OS that there was too much current being sucked on the USB port. we are using three such things, each uses typically 33 and up to 50 mA. This should (according to the Arduino and USB specs) not be too much, but perhaps these are wrong. Any other ideas? I have heard of people using smoothing capacitors on the sharp sensors. Hmm, puzzled in Linz, Tim ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] line~ for syncing to video
Hans-Christoph Steiner wrote: I am trying to make a version of [line~] that gives me a line based on the frame numbers I give it. Basically, I give it a frame counter in the first inlet, then start frame and stop frame as arguments. The hard part is that I want it to behave like [line] in that the last value stays in effect until something else overrides it. i think i don't fully understand it. can't you do this with [line~]? how do you make your version of it? pure-pd or C or lua? fgam,sdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
Hi Derek, Did you try running as sudo or root? Of course! Just tried this and yes no clicks!!! Before I was using qjack ctrl to control jackd. What is strange is that when I run jackd from command line without sudo privileges there are no clicks either !? So following from that discovery it seems sudo privileges are not necessary to avoid the clicks but avoid the use of or running of qjackctrl under normal privileges to run the jack daemon. I wonder why this is ? odd - maintaining jack connections between apps will be a headache without the GUI. I suppose I could also start the qjackctrl from command line with sudo privileges ... thanks Derek, Conor ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Timing and PD....
Internally, objects like pix_image and pix_film set flags for whether an image is new or not. This tells other objects to update. Perhaps a generic object (pix_info ?) can output when that flag is set. pix_share is a little different than image loading as it just dumps a new image into the gemlist each frame. It is not designed to do sync between instances of pd, but rather to be an asynchronous way to distribute processing. Making it sync would remove the performance gains. On Thu, Oct 30, 2008 at 9:32 AM, Hans-Christoph Steiner [EMAIL PROTECTED]wrote: I agree. I think for any indeterminate operation, like anything in a separate thread, there should be a bang when that operation is complete. That way you can guarantee that things are ready when you run a process. If you want to make sure that things will be there on time, then these threaded/indeterminate operations should run well in advance. Using guesswork and delays is not a real solution... .hc On Oct 30, 2008, at 4:25 AM, cyrille henry wrote: helo, i'm also having this kind of problem. specially when loading a picture in pix_image. i think the best would be the have a bang when things are ready... C B. Bogart a écrit : Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. This approach is not very scalable. I find myself using the timer object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. What is the long-term solution for PD to solve these issues? Should all objects that introduce a delay send a bang when they are complete? (for example pix_buffer? Of course an additional delay occurs when when the pix_buffer is written to memory and when it gets to the gfx card for display. I'm banging my head over these issues a lot lately and wonder if there is a better approach. Back to attempting kludging a solution. .b. ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ¡El pueblo unido jamás será vencido! ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
forwind wrote: Hi Derek, Did you try running as sudo or root? Of course! Just tried this and yes no clicks!!! Before I was using qjack ctrl to control jackd. What is strange is that when I run jackd from command line without sudo privileges there are no clicks either !? you can tell qjackctl to start jack with realtime priority fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
you can tell qjackctl to start jack with realtime priority I was running jackd through qjackctrl with realtime priorities. That didn't make a difference. On Thu, 2008-10-30 at 17:08 +0100, IOhannes m zmoelnig wrote: forwind wrote: Hi Derek, Did you try running as sudo or root? Of course! Just tried this and yes no clicks!!! Before I was using qjack ctrl to control jackd. What is strange is that when I run jackd from command line without sudo privileges there are no clicks either !? you can tell qjackctl to start jack with realtime priority fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Timing and PD....
Hey all, I'll try and work on some test patches, right now I'm trying hard to get an installation ready, and these issues turned out to be a large stumbling block. I suppose I'm doing lots of processing that may be unusual, like: Grab an image from video device put the image in a buffer for each frame send the image in the buffer to a second buffer on each bang from a metro. pix_share the image in the second buffer send a bang to tell second pd instance to pix_dump. turn off the metro. pix_dump (640x480 GRAY) to ann_som in a second thread netreceive the winning BMU use that BMU as the index in which the image has saved in a third buffer. turn the metro back on. I'm not thinking pix_share should do sync!! But I feel the need for some infrastructure better than trigger for complex timing problems like those I'm having. I'm still debugging my patch, but adding a whole lot of arbitrary delays (150ms) are being used to get PD to wait a little bit before accessing the image in a buffer once it has been written. Seems the safest way... I remember Cyrille did mention needing to use these delays to make things work. I had to use them in parts of pixelTANGO also (when a message gets passed through many objects and many routes it takes time...) As I have not noticed any render blocks with pix_buffer stuff, can I assume it uses a thread like pix_image and so on? I think a done bang would be really useful there. I also had issues with things like pix_histo, where I would try and save the hist, but the hist had not changed for the new pix_buffer_read frame, just because the delay was slower than t b b delay. Are cyrille and I the only ones seeing these kinds of issues? Thanks for the comments. .b. chris clepper wrote: Internally, objects like pix_image and pix_film set flags for whether an image is new or not. This tells other objects to update. Perhaps a generic object (pix_info ?) can output when that flag is set. pix_share is a little different than image loading as it just dumps a new image into the gemlist each frame. It is not designed to do sync between instances of pd, but rather to be an asynchronous way to distribute processing. Making it sync would remove the performance gains. On Thu, Oct 30, 2008 at 9:32 AM, Hans-Christoph Steiner [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I agree. I think for any indeterminate operation, like anything in a separate thread, there should be a bang when that operation is complete. That way you can guarantee that things are ready when you run a process. If you want to make sure that things will be there on time, then these threaded/indeterminate operations should run well in advance. Using guesswork and delays is not a real solution... .hc On Oct 30, 2008, at 4:25 AM, cyrille henry wrote: helo, i'm also having this kind of problem. specially when loading a picture in pix_image. i think the best would be the have a bang when things are ready... C B. Bogart a écrit : Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. This approach is not very scalable. I find myself using the timer object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. What is the long-term solution for PD to solve these issues? Should all objects that introduce a delay send a bang when they are complete? (for example pix_buffer? Of course an additional delay occurs when when the pix_buffer is written to memory and when it gets to the gfx card for display. I'm banging my head over these issues a lot lately and wonder if there is a better approach. Back to attempting kludging a solution. .b. ___ GEM-dev
Re: [PD] [GEM-dev] Timing and PD....
hello all i just ran into a similar problem. for the logic of some video players we used the end 'bang' of [pix_film] for triggering some other filmplayer. as soon, as the movie should be started again, we first set the frame number to 1 and then in zero logical time we started the according [gemhead] to start film playing / rendering of the gemchain. by doing this, [pix_film] sent the end bang, although we've set the frame number to 1 before. it took me some time to figure out, that this is probably related to what you're discussing here. after i added a delay between setting frame no to 1 and starting [gemhead], it worked well (no bogus end 'bang' from [pix_film]). don't know how this could be solved in an meaningful and understandable way. however, i think that having to use a [delay] is the worst imaginable case. in this particular case, we found a clean solution by setting the startframe number on filmend instead of filmstart. a generic solution to achieve something like that within 'pseudo-zero' logical time would be good, i think. by 'pseud-zero' logical time i mean, that instead of waiting to the left bang of [t b b], one could wait on the 'ready' bang from the [pix_[film|image|etc]] object. roman On Thu, 2008-10-30 at 10:32 -0400, Hans-Christoph Steiner wrote: I agree. I think for any indeterminate operation, like anything in a separate thread, there should be a bang when that operation is complete. That way you can guarantee that things are ready when you run a process. If you want to make sure that things will be there on time, then these threaded/indeterminate operations should run well in advance. Using guesswork and delays is not a real solution... .hc On Oct 30, 2008, at 4:25 AM, cyrille henry wrote: helo, i'm also having this kind of problem. specially when loading a picture in pix_image. i think the best would be the have a bang when things are ready... C B. Bogart a écrit : Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. This approach is not very scalable. I find myself using the timer object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. What is the long-term solution for PD to solve these issues? Should all objects that introduce a delay send a bang when they are complete? (for example pix_buffer? Of course an additional delay occurs when when the pix_buffer is written to memory and when it gets to the gfx card for display. I'm banging my head over these issues a lot lately and wonder if there is a better approach. Back to attempting kludging a solution. .b. ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ¡El pueblo unido jamás será vencido! ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] reproduce envelope
Hello, Is is possible in Pd to produce exactly the same envelope again and again? If I send the same message to vline and use this to cut an envelope out of noise or a sine wave, it always changes a bit (if you listen carefully). (The phase is always reset, that's not the problem.) I recorded the sounds, had a look at the soundfiles in an edit program and noticed that all the envelopes were slightly different. Then I used line~ in a subpatch with blocksize 1 and did the same thing. This sounds better and if I looked at the recorded sound files they were more identical (although the release changes a bit, there seems to be a very small inaccuracy in the delay... but you can't hear this with the sine sound. The noise sound is always a bit different, I guess because it are randomly generated frequencies?). Anyway I thought that vline~ was more precise than line~ but this doesn't seem to be true...? Have a look at the file in attach. Hans R #N canvas 42 23 722 623 12; #X obj 106 154 vline~; #X obj 68 185 *~; #X obj 59 259 dac~; #X obj 145 81 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 106 130 0.5 20 \, 0 50 20; #X obj 146 15 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 145 43 metro 500; #N canvas 0 0 450 300 (subpatch) 0; #X array view 1000 float 2; #X coords 0 1 1000 -1 200 140 1; #X restore 297 25 graph; #X obj 121 447 vline~; #X obj 81 521 *~; #X obj 62 580 dac~; #X obj 154 367 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 122 425 0.5 20 \, 0 50 20; #X obj 158 313 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 158 338 metro 500; #X obj 115 578 tabwrite~ view; #X obj 37 438 osc~ 440; #X msg 81 409 0; #X obj 31 114 noise~; #X obj 100 260 tabwrite~ view; #X obj 258 216 loadbang; #X msg 256 243 \; view resize 1000 \;; #X msg 408 243 \; view resize 5000 \;; #X obj 421 436 dac~; #N canvas 738 321 564 342 blocksize1-osc 0; #X obj 15 7 block~ 1; #X obj 58 222 *~; #X obj 134 20 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 133 48 metro 500; #X obj 59 258 outlet~; #X obj 96 191 line~; #X obj 152 77 t b b; #X msg 169 125 0.5 20; #X obj 112 111 del 20; #X msg 89 145 0 50; #X obj 152 262 tabwrite~ view2; #N canvas 0 0 450 300 (subpatch) 0; #X array view2 1000 float 2; #X coords 0 1 1000 -1 200 140 1; #X restore 280 30 graph; #X obj 21 151 osc~ 440; #X msg 71 110 0; #X text 170 207 the attack is more exact now \, the release (the delay object...?) still changes a bit though...; #X connect 1 0 4 0; #X connect 2 0 3 0; #X connect 3 0 6 0; #X connect 5 0 1 1; #X connect 5 0 10 0; #X connect 6 0 8 0; #X connect 6 1 7 0; #X connect 6 1 10 0; #X connect 6 1 13 0; #X connect 7 0 5 0; #X connect 8 0 9 0; #X connect 9 0 5 0; #X connect 12 0 1 0; #X connect 13 0 12 1; #X restore 330 348 pd blocksize1-osc; #N canvas 687 533 628 346 blocksize1-noise 0; #X obj 15 7 block~ 1; #X obj 58 222 *~; #X obj 134 20 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 133 48 metro 500; #X obj 59 258 outlet~; #X obj 96 191 line~; #X obj 152 77 t b b; #X msg 169 125 0.5 20; #X obj 112 111 del 20; #X msg 89 145 0 50; #N canvas 0 0 450 300 (subpatch) 0; #X array view3 1000 float 2; #X coords 0 1 1000 -1 200 140 1; #X restore 280 30 graph; #X msg 71 110 0; #X obj 21 151 noise~; #X obj 152 262 tabwrite~ view3; #X text 153 183 the attack is more exact now \, the release (the delay object...?) still changes a bit though...; #X connect 1 0 4 0; #X connect 2 0 3 0; #X connect 3 0 6 0; #X connect 5 0 1 1; #X connect 5 0 13 0; #X connect 6 0 8 0; #X connect 6 1 7 0; #X connect 6 1 11 0; #X connect 6 1 13 0; #X connect 7 0 5 0; #X connect 8 0 9 0; #X connect 9 0 5 0; #X connect 12 0 1 0; #X restore 478 351 pd blocksize1-noise; #X text 332 323 better solution in here:; #N canvas 369 718 474 156 record-file 0; #X obj 66 51 bng 15 250 50 0 1-refsrec 1-refrrec rec 0 -6 0 8 -258699 -1 -1; #X obj 107 52 bng 15 250 50 0 1-refsstop 1-refrstop stop -5 -6 0 8 -262144 -1 -1; #X msg 136 313 start; #X msg 294 358 stop; #X obj 48 424 inlet~; #X obj 28 226 savepanel; #X msg 45 289 open \$1.wav; #X obj 407 203 inlet; #X obj 406 259 select 0 1; #X text 411 171 1 = record \, 0 = stop recording; #X obj 140 189 r 1-refsrec; #X obj 303 328 r 1-refsstop; #X obj 517 299 s 1-refrrec; #X obj 405 299 s 1-refrstop; #X symbolatom 26 77 45 0 0 0 - #1-refrsym -; #X obj 25 345 s 1-refrsym; #X text 388 79 .wav; #X obj 26 51 bng 15 250 50 0 1-refsopen 1-refropen open -5 -6 0 8 -262144 -1 -1; #X obj 23 194 r 1-refsopen; #X obj 275 432 inlet~; #X obj 46 520 writesf~ 1; #X obj 245 534 writesf~ 2; #X obj 129 431 spigot; #X obj 218 431 spigot; #X obj 197 375 == 0; #X obj 170 50 tgl 15 0 1-refsstereo 1-refrstereo stereo_rec_on 17 7 0 9 -262144 -1 -1 0 1; #X obj 220 282 r 1-refsstereo; #X obj 426 373 loadbang; #X msg 426 399 0; #X obj 424 468 s 1-refrstereo; #X obj 45 258 symbol; #X obj 211 314 t b f; #X obj 406 230 0; #X obj 137 459 print m; #X obj 208 465 print s; #X text
Re: [PD] glitches when moving between sub patches
Hi Conor, a few things: 1) I would check every single setting in Qjackctl against the ones you use in the command line, maybe there's some difference. 2) I would doublecheck how Qjackctl is called (i.e. do you start from commandline or menu bar, and if menu bar then how is it actually being called?) 3) Once jackd has been started you can start Qjackctl and use it to manage connections. It will recognize that the jack engine is already started. 4) Yes, you could sudo qjackctl. You could also make one bash script that starts everything, and sudo that. best! Derek forwind wrote: Hi Derek, Did you try running as sudo or root? Of course! Just tried this and yes no clicks!!! Before I was using qjack ctrl to control jackd. What is strange is that when I run jackd from command line without sudo privileges there are no clicks either !? So following from that discovery it seems sudo privileges are not necessary to avoid the clicks but avoid the use of or running of qjackctrl under normal privileges to run the jack daemon. I wonder why this is ? odd - maintaining jack connections between apps will be a headache without the GUI. I suppose I could also start the qjackctrl from command line with sudo privileges ... thanks Derek, Conor ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 48: Discover your formulas and abandon them ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd tools for syncing to video
The pdmtl abstractions have gems.movies~ to sync/play audio files with movies. You can also use gems.movies with a 0-1 signal snapshot~ed to the frame input (in relative mode). Both abstractions will loop movies and audio files simultaneously, meaning, that if the audio is shorter than the movie, it will be played faster. Thomas ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD, arduino and sharp range detectors
Tim Boykett wrote: We are having trouble with a PD - Arduino - Sharp IR gp2d12 IR range sensor. everything works for a while, then the arduino just stops and sometimes takes PD down with it. once we had a warning from the OS that there was too much current being sucked on the USB port. we are using three such things, each uses typically 33 and up to 50 mA. This should (according to the Arduino and USB specs) not be too much, but perhaps these are wrong. I have built a circuit with six of those sensors on an Arduino Diecimila, it worked fine with external power, but I didn't even try it with USB power because for me 50mA is too much. (At first it crashed sporadically because I was sending too much data through the serial port.) The actual USB port you are using may not be able to supply that much current even if the USB circuit is able to handle it. If it only happens occasionally it's probably because the sensors sometimes pull more than the average current, so a ~100uF capacitor on the power pins would help, but you should really use a separate power supply for the sensors, or just power the entire Arduino externally. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
On Thu, 2008-10-30 at 16:21 +, forwind wrote: you can tell qjackctl to start jack with realtime priority I was running jackd through qjackctrl with realtime priorities. That didn't make a difference. On Thu, 2008-10-30 at 17:08 +0100, IOhannes m zmoelnig wrote: forwind wrote: Hi Derek, Did you try running as sudo or root? Of course! Just tried this and yes no clicks!!! are you member of the audio group? $ groups username the printed list should contain 'audio'. if not, do: sudo adduser username audio also, if you're not part of the audio group and therefore don't have realtime privileges, you shouldn't see the 'RT' sign in qjackctl. if you're seeing 'RT' in qjackctl, then you shouldn't have clicks. can you confirm all of that? in recent linux' systems, there shouldn't be a need to do realtime audio as root. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: midi_sync_out
So it turns out that with the newer stable pd (0.41-4) [midiout] works. So I've changed my external into a very simple abstraction. I'm providing it here as an attachment with a help file that shows a simple syncing solution. Note: it does not work with pd 0.40-2 and alsa, I'm figuring it wouldn't work with pd-extended and alsa... but maybe Hans has rolled back the [midiout] fixes into the current extended? I haven't tested with any of the other midi apis. Basically this patch allows you to sync an external midi device with a metro so you can have pd do things in sync with an external drum machine, synthesizer, whatever.. that accepts sync in. Enjoy! -Alex On Wed, Oct 29, 2008 at 4:39 PM, Alex [EMAIL PROTECTED] wrote: I'm running the latest stable (0.41-4) and [midiout] is working, at least for sending mid clock/start/stop/continue messages. I'm running linux and use alsa for midi with pd. -Alex On Wed, Oct 29, 2008 at 5:20 AM, mrtoftrash [EMAIL PROTECTED] wrote: For Linux, midiout only works in the latest TEST version of PD from Miller. Thomas ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list x37v-midi_sync_out.pd Description: Binary data x37v-midi_sync_out-help.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
Assuming you are Ubuntu ... are you using the realtime kernel? In Hardy at least, I get smooth pd audio with realtime jack and dropouts when using the same with the regular kernel. It seems the realtime kernel is *too* agressive for my laptop ... ? On Thu, 2008-10-30 at 16:21 +, forwind wrote: you can tell qjackctl to start jack with realtime priority I was running jackd through qjackctrl with realtime priorities. That didn't make a difference. On Thu, 2008-10-30 at 17:08 +0100, IOhannes m zmoelnig wrote: forwind wrote: Hi Derek, Did you try running as sudo or root? Of course! Just tried this and yes no clicks!!! Before I was using qjack ctrl to control jackd. What is strange is that when I run jackd from command line without sudo privileges there are no clicks either !? you can tell qjackctl to start jack with realtime priority fgmasdr IOhannes --- Dan Wilcox robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glitches when moving between sub patches
Before when I ran jack from qjackctl the RT flag was enabled. The user is/was part of the audio group. It must be some thing to do with the way qjackctrl is running the daemon. as i said earlier sudo is not essential but running from terminal is. Eitherway I can continue working with this patch which is a big relief. the distribution is 64studio kernel - 2.6.21 64bit RT On Thu, 2008-10-30 at 17:46 +0100, Roman Haefeli wrote: are you member of the audio group? $ groups username the printed list should contain 'audio'. if not, do: sudo adduser username audio also, if you're not part of the audio group and therefore don't have realtime privileges, you shouldn't see the 'RT' sign in qjackctl. if you're seeing 'RT' in qjackctl, then you shouldn't have clicks. can you confirm all of that? in recent linux' systems, there shouldn't be a need to do realtime audio as root. roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] reproduce envelope
On Thu, 2008-10-30 at 17:32 +0100, Hans Roels wrote: Hello, Is is possible in Pd to produce exactly the same envelope again and again? If I send the same message to vline and use this to cut an envelope out of noise or a sine wave, it always changes a bit (if you listen carefully). (The phase is always reset, that's not the problem.) I recorded the sounds, had a look at the soundfiles in an edit program and noticed that all the envelopes were slightly different. this is actually a feature of [vline~]. [vline~] understands scheduled messages, which means, that messages triggered by [metro] or [delay] are executed by [vline~] at the exact time of the [metro]/[delay] initiated message. in other words: [vline~] starts ramps between audio blocks, even between samples. the phase setting for [osc~] is only executed on block boundaries. this is why you're getting inconsistent results with [vline~] and [osc~] Then I used line~ in a subpatch with blocksize 1 and did the same thing. This sounds better and if I looked at the recorded sound files they were more identical (although the release changes a bit, there seems to be a very small inaccuracy in the delay... [line~] on the other hand is starting the ramp always on block boundaries, that is why the phase reset and the ramp start at the same time, which is giving you consistent results. different decays might be the effect of rounding errors, since - in case you're not using a multiple of the block size as ramp length - the resulting ramp length is sometimes rounded up and sometimes rounded off. (this is a only theory, that needs to be confirmed by someone who knows to read the c code of [line~]). but you can't hear this with the sine sound. The noise sound is always a bit different, I guess because it are randomly generated frequencies?). there is no phase reset for [noise~], so the results will always be different. Anyway I thought that vline~ was more precise than line~ but this doesn't seem to be true...? it is true, but many other objectclasses aren't. to mention only a few: - right inlet of [osc~] and [phasor~] - [tabwrite~] - [tabplay~] - [writesf~] - [readsf~] probably more. all those objectclasses execute incoming message only on blockboundaries, which means, you get inconsistent results, when using them together with the indeed more accurate [vline~]. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD, arduino and sharp range detectors
that seems to be the case! thanks tim On 30 Oct 2008, at 17:41, Martin Peach wrote: Tim Boykett wrote: We are having trouble with a PD - Arduino - Sharp IR gp2d12 IR range sensor. everything works for a while, then the arduino just stops and sometimes takes PD down with it. once we had a warning from the OS that there was too much current being sucked on the USB port. we are using three such things, each uses typically 33 and up to 50 mA. This should (according to the Arduino and USB specs) not be too much, but perhaps these are wrong. I have built a circuit with six of those sensors on an Arduino Diecimila, it worked fine with external power, but I didn't even try it with USB power because for me 50mA is too much. (At first it crashed sporadically because I was sending too much data through the serial port.) The actual USB port you are using may not be able to supply that much current even if the USB circuit is able to handle it. If it only happens occasionally it's probably because the sensors sometimes pull more than the average current, so a ~100uF capacitor on the power pins would help, but you should really use a separate power supply for the sensors, or just power the entire Arduino externally. Martin ___ 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] gem, texture management
Hi people, Can someone, explain how gem manage the textures in the graphics card memory? Is it possible to load and unload the files/textures from the graphic card? Or once the texture is in the memory, stay in there...until when? I'm using a patch to control 16 patches for my perfomance. And it seems like at the end of the performance the management of the textures dicreasse consideratly. Thx ddd http://gollum.artefacte.org/t4/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gem, texture management
On Thu, Oct 30, 2008 at 3:22 PM, [EMAIL PROTECTED] wrote: Hi people, Can someone, explain how gem manage the textures in the graphics card memory? To the best of my knowledge there is no way to map memory on the GPU from the user side. The driver either handles the memory well or it does not. Is it possible to load and unload the files/textures from the graphic card? Or once the texture is in the memory, stay in there...until when? I'm using a patch to control 16 patches for my perfomance. And it seems like at the end of the performance the management of the textures dicreasse consideratly. Thx ddd http://gollum.artefacte.org/t4/ ___ 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
