Re: [PD] d-scale abstraction with rjdj
Hi, On Fri, Jun 17, 2011 at 10:45:45AM -0400, Pagano, Patrick wrote: But here is an FM glitcher using d-scale and Tonalatonal, I patch I found on list a few years ago that is RIPE for rjDJ-ness Maybe you can look at these and help me make em a little more spiffy, or at very least get tonal working! Okay, that's a bit of tedious work. but doable. The patches only use [sort], which you can replace by [list-sort] with [list-rdrip] from the [list]-abstractions. They only use [sort 1] which is ascending sort i.e. a naked [list-sort]. A bit more tricky to replace are the expr-constructs used. Fortunatly [d-scale] is only used as [d-scale -1 1 1 100 100]. This is sufficiently similar to [m_scale -1 1 1 100 dB] from the rj-library, so I'd just use that. Another expression used several times is this: expr~ if ($v1 == 0, 0, (if ($v1 0, -1, 1))) This is a signum function for signals. You can replace this with the sgn~.pd from the purepd collection in CVS/Pd-extended. Make sure to also get the lt~.pd and gt~.pd abstractions. Alternatively you can also get away with this: [inlet~] |\ | [abs~] | | [/~] | [outlet~] I.e. divide a signal by its absolute value. Division of 0/0 in Pd here gives 0 again, so you're cheating okay around this exceptional case. The other expr-expression just require some work to explode them into normal math objects. You will gain a bit of execution speed by this, as expr is a bit slower than exploded math. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] What's the workaround for pix_resize/pix_crop non-refreshing bug?
Hi, On Windows (not linux, dunnow mac), the current release of Gem has a known bug (2972166) in that [pix_resize] and [pix_crop] don't update the image when you change the crop parameters or the dimen of the resize. According to the bug tracker it has been fixed (can anyone confirm on Windows and Mac?), but the fix hasn't been released yet. IOHannes suggested me to use [pix_separator] as a workaround, but it doesn't work, or I haven't understood the suggestion fully. Neither putting a [pix_separator] just before nor just after [pix_resize] fixes the issue. Is there a workaround at all? Thanks m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] What's the workaround for pix_resize/pix_crop non-refreshing bug?
On 06/18/2011 12:52 PM, Matteo Sisti Sette wrote: IOHannes suggested me to use [pix_separator] as a workaround, but it doesn't work, or I haven't understood the suggestion fully. Ok sorry, I have to bang the pix_separator in order to refresh the image. That's the workaround. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd-con 2011: CALL FOR SUBMISSIONS
Dear pd-community, you have the chance to rock the bells of weimar city hall! During the pd-convention from 8.8-14.8.2011 in weimar there will be the possibility for little evening concerts on the porcelain carillon in the tower of weimar cityhall. It is a great opportunity to present your compositions/generated music/etc. in public space on an ancient instrument. The city hall faces the market place - a touristic hotspot of weimar. - The concerts will take place every evening during 7p.m and 8p.m. - There will be 5 concerts - one for every evening. The pd-con team will select 5 pieces out of your submissions - The compositions should not take longer than 12 minutes so they'll fit in between the quarter-hour chime - The compositions can be reached in either as a MIDI-file or as a pure-data patch that outputs MIDI-notes (The carillon is MIDI- compatible) For more information visit this wiki-page: http://www.uni-weimar.de/medien/wiki/PDCON:Porcelain_carillon There you'll also find a pure data sample player with the original sound of the bells - so you can test your artwork wherever you are Please send your suggestions/concepts/compositions until latest the END OF JULY to: moritz.sch...@uni-weimar.de looking forward to the results and to see you all in weimar, frederic, max and moritz Moritz Schell MKG, Master Matrikelnr. 100498 Trierer Straße 42 99423 Weimar 0170 - 851 08 87 moritz.sch...@uni-weimar.de moritzsch...@gmx.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Launching puredata -nogui from a terminal
On Fri, 17 Jun 2011, Bernardo Barros wrote: 2011/6/17 Matteo Sisti Sette matteosistise...@gmail.com: Is there a way to launch Pd from a script with -nogui in such a way that when the terminal in which it was launched is closed, the Pd process is also killed? That's what already happen with all jobs running on one particular terminal. If you open a text editor from terminal, you can't close that terminal until you save your text.. etc.. Note that when you press Ctrl+z in the Terminal and then say : bg; exit it closes the terminal while keeping all the same tasks running. same when launching an app from a Terminal by saying : pd whatever.pd exit ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd crashed
On Fri, 17 Jun 2011, Cody Loyd wrote: pd crashed while I was saving a large patch. now, when I open that patch, about a third of the objects are gone, and ALL of the connections. The objects are saved before the connections are. If you open a normal pd files, you will see that all #X connect lines are at the end, except for subpatches, each of which is a section starting with #N canvas and ending with #X restore and counting as one subpatch object. The top #N canvas line is different and represents the main patch of the file. what the heck happened.. and am I totally screwed or can I fix it. You really, really need a backup of that file. Any other way to fix it would require a filesystem expert AND a pd expert, and would only work IF your next-to-last saved version is nearly the same as the last version. Those might not be sufficient conditions, and it would be somewhat in the miracle category if it worked (technicians may apply for sainthood status, etcætera). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd crashed
2011/6/18 Cody Loyd codyl...@gmail.com The problem is not that is just didn't save... So dang. Pd has been crashing more often for me lately, with no more terminal output than Segmentation fault... Is there a log somewhere where I can try to see what's causing these? I also had this problem lately on Linux (when using dsp in some patches), vanilla version 0.43-0, and after going back to 0.42-5 the problem remained. After removing libraries to load one at a time I figured out that not loading zexy anymore solved the problem for me, although that is not the prettiest solution. Funs On Linux. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] (OT) is reading files from an NTFS filesystem in linux 30 times slower than ext4?
Hi, After a whole day spent trying to find the bottleneck that makes my patche so tremendosly slow to load in Pd under linux, I found out that if I load them from the native linux filesystem (an ext4 partition) they load about 30 times faster than when I load them from my NTFS partition which is where I usually keep all my data. Outside Pd I had never noticed an abnormal slowness in reading data from that disk, and though I did expect NTFS to be slower in linux I am surprised the difference can be so huge. Is it so, or may there be some issue specific to Pd? Thanks m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (OT) is reading files from an NTFS filesystem in linux 30 times slower than ext4?
On Sat, Jun 18, 2011 at 22:45, Matteo Sisti Sette matteosistise...@gmail.com wrote: Hi, After a whole day spent trying to find the bottleneck that makes my patche so tremendosly slow to load in Pd under linux, I found out that if I load them from the native linux filesystem (an ext4 partition) they load about 30 times faster than when I load them from my NTFS partition which is where I usually keep all my data. Outside Pd I had never noticed an abnormal slowness in reading data from that disk, and though I did expect NTFS to be slower in linux I am surprised the difference can be so huge. Is it so, or may there be some issue specific to Pd? Yes, ext4 is relatively new, modern, and benchmarks prove it to be fast. NTFS is not so slow when used with Windows (7) but the linux ntfs-3g driver is a lazy one. The ntfs (no 3g) driver is faster but it's read only. The other problem with ntfs-3g is that it seems to me that sometimes it corrupts the filesystem in a way that Windows (XP) has problems using it (Delayed write failed errors). Also, some filesystems are less, some are more CPU-intensive so they work slower when the CPU is busy with other things, but in this case, I think, it's not about the CPU. BTW, thanks for pulling my attention to this, now ext4 is mature enough that I migrate from xfs...! Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd performance at TED
I just wanted this performance by Onyx Ashanti as part of the TED Talks stuff. Its quite a nice performance using live sensor control of Pd: http://www.ted.com/talks/onyx_ashanti_this_is_beatjazz.html It looks like you can even see Pd on the screen behind him. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
