Re: [PD] pdp_rec
hola, the status for this is that it seems difficult to use theorin~ and theorout~at the same time in a patch, yes it crashes, surely for a reentrancy problem in libtheora that i don't have time to fix for now... volunteers are welcome. saludos, sevy Vincent Rioux wrote: hello Yves, thanks for the advice pdp_theorout~ is neat but i found pdp_theorin~ to be really difficult to handle (segfaults and such) so what i do now: - record videos with pdp_theorout~ - convert videos to ffmpg_mp4 (with ffmpeg) - play videos with pdp_yqt works great! best regards, vincent ydegoyon a écrit : ola, yes, i noticed that, only divx works now with this %!###%%!! libquicktime. it will not be fixed, not by me, record in ogg/theora ( pdp_theorout~ ), there you can set every parameters you like. saludos, sevy [EMAIL PROTECTED] wrote: hi, is there a way to set divx rate for pdp_rec object? i found that recording in jpeg format on pd-extended/hardy was not working unfortunately. vincent ___ 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] Scope of [block~] and [switch~]
Hi, I am trying to understand oversampling to eliminate foldover from my patches. In the help file for block~ we read: The block~ and switch~ objects set the block size, overlap, and up/down-sampling ratio for the window. (The overlap and resampling ratio are relative to the super-patch.) This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact? If not, do you have to include all of the audio rate objects at the same level in a patch without using sub-patches or abstractions? Thanks for reading. Cheers, David ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
Hi David, try putting [samplerate~] in each subpatch or abstraction to see if the changes by [block~] are passed down. I don't know offhand if they are, but I *think* that is correct. best, d. David F. Place wrote: This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact? -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 142: Shut the door and listen from outside ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'pure' pd DSP abstractions wanted!
Thanks, I'll take a look at the article. Mitch On Oct 20, 2008, at 1:22 AM, Hans-Christoph Steiner wrote: On Aug 31, 2008, at 10:08 AM, Mitchell Turner wrote: Jamie, Here are two abstractions that may be useful to people. The first allows easy communication between the ReMOTE ZERO SL by Novation and Pd. I've included the abstraction plus a file called PureData.syx which must be up loaded to the ReMOTE ZERO (the file tells the ReMOTE ZERO which CCs to assign to each button or dial). The other abstraction allows one to use the Roland GR-33 as a flexible MIDI foot pedal with Pd. The four pedals of the GR-33 normally send program changes only (at least as far as I could tell). I've simply remapped the program change messages to trigger bang objects.Similarly, the Expression Pedal sends CC1, CC4, or CC7. I've routed these CCs to a single number box. The CC-SA license seems to make the most sense for both of these abstractions. Actually any of the CC licenses are bad for software, and really in general, IMHO. They are not compatible with the Debian Free Software Guidelines, and every single one has an really vague attribution clause that should be avoided. If you want to know more, check out my essay Copyright Is For Copying in the new book: http://goto10.org/flossart/ I don't know if the digital version is up there yet. .hc MitchGR-33.pdRemoteSL_Module.pdPureData.syx On Aug 29, 2008, at 6:26 PM, Jamie Bullock wrote: Hi Mitch, To me GPLv* seems like a poor fit for a Pd patch or collection of patches. GPL is more appropriate for compiled code, or compiled byte code, where it is possible distribute 'the program' in binary form (which is not possible with Pd patches). If you want to place some restrictions on your patch like 'you can do what you like with this so long as you give me credit', or 'you can do what you like so long as you share your changes', perhaps try one of the creative commons licenses: http://creativecommons.org/ The CC-SA and CC-BSD seem quite appropriate for Pd work to me. HTH, Jamie On Fri, 2008-08-29 at 16:08 -0400, Mitchell Turner wrote: Jamie, Had not though about a license. Do you have a suggestion? GPLv3? Mitch On Aug 29, 2008, at 7:50 AM, Jamie Bullock wrote: On Fri, 2008-08-29 at 07:38 -0400, Mitchell Turner wrote: Jamie, I'm not sure this fits in with your project. I have an abstraction that allows easy interface between Pd and the REMOTE SL Zero (Novation). Let me know if you want to include it or take a look at it. That sounds really great! So long as it doesn't require any externals, or it could easily be adapted to not use externals, I am interested. BTW, although I asked for 'DSP' abstractions, I'm really looking for anything that provides a useful 'higher level' functionality, and this nicely fits the bill! Please feel free to send it either privately, on list, or via the web, and let me know what license you would consider it to be covered by. thanks, Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Patch licensing was Re: 'pure' pd DSP abstractions wanted!
On Mon, 2008-10-20 at 01:22 -0400, Hans-Christoph Steiner wrote: snip Actually any of the CC licenses are bad for software, and really in general, IMHO. They are not compatible with the Debian Free Software Guidelines, and every single one has an really vague attribution clause that should be avoided. OK, what software license would you recommend for someone who wants to place the 'share alike' restriction on their Pd patch? The GPL is really geared towards compiled languages, and a lot of the wording is irrelevant in the context of a Pd patch IMO. If you want to know more, check out my essay Copyright Is For Copying in the new book: http://goto10.org/flossart/ Great! I just added it to my Amazon wishlist. Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock Birmingham City University is the new name unveiled for the former University of Central England in Birmingham For more information about the name change go to http://www.bcu.ac.uk/namechange/official_announcement.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'pure' pd DSP abstractions wanted!
On Mon, 2008-10-20 at 03:19 +0800, Chris McCormick wrote: snip This has been sitting in my inbox for ages, sorry I never replied to it. My s-abstractions collection is just such a set of abstractions that you describe, with no external dependencies. Much of it was made by stealing Miller's help patches and turning them into nice little guis, and lots of other people's work too. I'm trying to bulk it up a bit at the moment with the great plate reverb that Anton Hornquist posted here a while back, and then I'm going to try and make a good, intuitive compressor after that. If you do a pitch shifter or harmonizer, please let me know so I can steal them for my collection, with your consent obviously! :) http://mccormick.cx/projects/s-abstractions After I get back to London next week I'm going to try and tidy the collection up a bit and get the latest version into pd-extended. I think the version that is in there at the moment is pretty outdated. Thanks Chris. I was already aware of s-abstractions, and I think they're fantastic. I didn't realise that they were pure Pd, so that's good to know. best, Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock Birmingham City University is the new name unveiled for the former University of Central England in Birmingham For more information about the name change go to http://www.bcu.ac.uk/namechange/official_announcement.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
Thanks again, Derek. I couldn't find any documentation for samplerate~, but I guessed that the output would be a number and that I should probably bang the input to get it. It shows that the up-sampled rate from block is passed down to abstractions. On Mon, 2008-10-20 at 14:57 +0200, Derek Holzer wrote: Hi David, try putting [samplerate~] in each subpatch or abstraction to see if the changes by [block~] are passed down. I don't know offhand if they are, but I *think* that is correct. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
David F. Place wrote: Hi, I am trying to understand oversampling to eliminate foldover from my patches. In the help file for block~ we read: The block~ and switch~ objects set the block size, overlap, and up/down-sampling ratio for the window. (The overlap and resampling ratio are relative to the super-patch.) This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact? yes, all subpatches share the same signal-properties with regard to the super-patch (unless further overriden of course). If not, do you have to include all of the audio rate objects at the same level in a patch without using sub-patches or abstractions? no mfgasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
Derek Holzer wrote: Hi David, try putting [samplerate~] in each subpatch or abstraction to see if the afair, [samplerate~] will always output the _system_ samplerate (the one locked to the soundcard); it is not affected by up/downsampling. fmgasd IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
On Mon, 2008-10-20 at 15:29 +0200, IOhannes m zmoelnig wrote: yes, all subpatches share the same signal-properties with regard to the super-patch (unless further overriden of course). So, I added [block~ 4096 1 16] to my next to top level abstraction and now I get the following errors: error: throw~ voiceSumLeft: vector size mismatch error: sigcatch voiceSumRight: unexpected vector size All my abstractions are within the scope of one block~, shouldn't they have the same vector size? I pass the final signal out through outlet~ objects to be downsampled before being passed to dac~. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
On Mon, 2008-10-20 at 15:50 +0200, IOhannes m zmoelnig wrote: the warning is misleading though: Pd simply refuses to [throw~]/[catch~] or [s~]/[r~] with anything other than the standard 64-sample, no-overlap, no-resampling signal. I see. I changed all of my throws and catches to direct connections and it now works, sort of. My patches are much uglier, though. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PD developper residency
Residency: wanted software developer For a new Artist in Residence project at [ars]numerica (Montbéliard Cedex, France; www.ars-numerica.net), media artist Sonia Cillari is looking for a software developer for a period of 5 weeks. The starting date is beginning of February 2009. Requested: fluidity in a wide range of languages and tools, understanding of both software and hardware sides of creative projects with digital media. C/C++, OpenGL, Ogre, 3D programming, PD, physics simulation, computer vision, sound integration. The timeframe of the project is in consultation with the artist. More information is available on request. If you're interested, please contact: Yasmina Demoly (chargée de production [ars]numerica): mina ( at ] ars-numerica.net or Sonia Cillari (www.soniacillari.net): sonia.cillari ( at ] gmail.com ---___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
David F. Place wrote: On Mon, 2008-10-20 at 15:29 +0200, IOhannes m zmoelnig wrote: yes, all subpatches share the same signal-properties with regard to the super-patch (unless further overriden of course). So, I added [block~ 4096 1 16] to my next to top level abstraction and now I get the following errors: error: throw~ voiceSumLeft: vector size mismatch error: sigcatch voiceSumRight: unexpected vector size All my abstractions are within the scope of one block~, shouldn't they have the same vector size? you are right. the warning is misleading though: Pd simply refuses to [throw~]/[catch~] or [s~]/[r~] with anything other than the standard 64-sample, no-overlap, no-resampling signal. gmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_contrast eats up cpu power
cyrille henry wrote: hello, i don't understand everything on your mail. i thought adjusting the contrast brightness needs to be done in the frag file - with the update help example its clear! my problem was by modifing the color argument in the frag file i also loose opacity of the whole image instead of contrast only. as roman mentioned it - now it works exactly the way we need! merci mille two doublescoops of gelato for this move! olsen with color = color * 0.1 , then every color component (R, G and B) will be 10 times smaller than the original texture color, so the images will be darker. color value are between 0 and 1, so you can try curve like this : color = pow(color,vec4(0.5)); i don't know exactly what curve to use for a good contrast / saturation, but you can have a look at pix_contrast source code... Cyrille olsen a écrit : hep cyrille thanks for this hint - though it's my first time using shader - i tweaked around a bit with the example. i changed color saturation towards muchocolore in the texture.frag file. although removing color to get a black white image i'm also loosing opacity f.e. with color = color* 0.1; the image gets almost black. where aside the green behind my ears can i find infos about how to handle the shader? thankssalutis olsen cyrille henry wrote: use shader! you'll have to make your own shader, but adjusting color saturation is quite easy. see gem documentation/10.glsl/01.simple_texture cyrille olsen a écrit : hi roman me are working on an videoinstallation using gem - only an additional [pix_contrast] in the gem chain hits the processing limit of our computer - is there a way to adjust color saturation in the gpu instead of the cpu in Gem? thanksgreets olsen -- Planet Pluto bleibt! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building Externals
That's the vague idea of the current makefiles there. But since many people didn't want to change the existing makefiles within each library folder, almost everything is stuck into externals/Makefile. I think if someone came up with a better system, then there wouldn't be objections to replacing the makefiles within each lib directory. Ideally, it should follow all of the GNU standards, like using 'prefix', DESTDIR, etc. .hc On Oct 15, 2008, at 11:42 AM, Alex wrote: I'm willing to work on the externals. I'm rather busy at the moment but am willing to slowly work on writing makefiles for various externals that need their own. I figure we should start with some generic makefile that maybe tests for environment variables for the INSTALL_PREFIX, location of m_pd.h, .. what else..? so that it could be called from a higher up makefile with that info setup already. -Alex On Mon, Oct 13, 2008 at 4:20 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: carmen r wrote: 'externals' cannot be self-sufficient since it will always depend on the headers in 'pd'. the existing scripts were smart enough to find m_pd.h (and the other headers) alonside externals/, or its parent directory see miXed/ it still works that way the issue is you introduced dependencies on several new toplevel dirs for no good reason and broke up the modularity of the makefiles this has basically been my arguing for ages. i would very much like to revamp the entire build-system, but haven't had the time to do it. if several people are interested in doing so we could form a taskforce and just do it. oh well, unsubscribing. have fun in your broken paradise oh well, your zeal was shortlived then let me know if you are still interested in making a better world. fgmasdr IOhannes ___ 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 There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
One small warning - the output of samplerate~ is confusing if there is overlap - samplerate~ output goes up by the overlap factor, which is arguably incorrect. It needs replacing by a more comprehensive solution. Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it correct' or just leave it wrong. The throw~/catch~ 64-sample restriction is fixable. It would be a much bigger project to make them work across arbitrary changes of sample rate, block size, and overlap. cheers Miller On Mon, Oct 20, 2008 at 02:57:57PM +0200, Derek Holzer wrote: Hi David, try putting [samplerate~] in each subpatch or abstraction to see if the changes by [block~] are passed down. I don't know offhand if they are, but I *think* that is correct. best, d. David F. Place wrote: This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact? -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 142: Shut the door and listen from outside ___ 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] Scope of [block~] and [switch~]
Miller Puckette wrote: One small warning - the output of samplerate~ is confusing if there is overlap - samplerate~ output goes up by the overlap factor, which is arguably incorrect. It needs replacing by a more comprehensive solution. Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it correct' or just leave it wrong. personally i would just change it. if somebody relies on a certain upsampling algorithm, they should explicitely specify so in the creation arguments. (or even better, use a separate object that fills the gaps in the zero-padded signal with something more sophisticated) fgmsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] create typewriter for gem
hi philippe, i played a little bit around: see the attached. g. philippe boisnard schrieb: Hello I have an other question Since 2 years, I create typewriter for my creations, but I think, that it's ver artisanal = metro + moses + sel (cf. example). Somebody have idea to create a nice typewriter ? thx phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 792 44 872 739 10; #X msg 203 503 32; #X obj 203 529 makefilename %c; #X obj 170 568 symbol; #X obj 169 600 list prepend; #X obj 8 365 sel 1; #X obj 169 624 list-l2s; #X obj 170 480 spigot 0; #X msg 215 411 1; #X msg 245 411 0; #X obj 78 471 spigot 0; #X msg 158 411 1; #X msg 187 411 0; #X msg 78 493 symbol; #X obj 537 146 any2string; #X obj 537 170 list split 1; #X obj 471 200 t b; #X obj 471 222 delay 100; #X obj 537 250 list append; #X obj 359 94 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 568 343 makefilename %c; #X obj 568 364 symbol; #X obj 613 363 string2any; #X obj 568 300 t b; #X msg 568 321 32; #X text 15 222 Enter your text with the keyboard and clear it with 'Return'.; #X text 382 92 reset; #X msg 553 196 100; #X msg 591 196 1000; #X text 630 195 speed; #X obj 568 277 route 32; #X obj 8 262 keyname; #X obj 158 370 sel Return Space; #X obj 8 335 spigot; #X msg 47 307 0; #X msg 79 307 1; #X obj 359 364 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 382 362 reset; #X symbolatom 62 263 10 0 0 0 - - -; #X obj 47 285 sel Shift_L Shift_R; #X text 171 285 disabled keys; #X msg 537 96 this is the text; #X msg 58 68 lighting \$1; #X obj 58 46 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #N canvas 855 130 450 300 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 256 112 destroy; #X obj 322 45 inlet; #X msg 132 112 create \, 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 8 0; #X connect 3 1 5 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 0 0; #X restore -10 99 pd gemwin; #X msg -10 77 destroy; #X obj 410 580 gemhead; #X obj 410 600 translateXYZ; #X obj 409 654 colorRGB; #X obj 412 677 alpha; #X obj 412 698 textextruded; #X msg 493 681 depth 9; #X msg 544 681 9; #X obj 520 664 loadbang; #X floatatom 522 607 5 0 0 0 - - -; #X obj 408 624 rotateXYZ 0 0 0; #X text 464 94 click here; #X obj 608 550 gemhead; #X obj 608 711 light; #X msg 695 689 1 1 1; #X obj 622 644 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X msg 622 665 debug \$1; #X floatatom 688 554 5 0 0 0 - - -; #X obj 608 615 translateXYZ 2 0 0; #X obj 608 572 rotateXYZ 0 -120 0; #X floatatom 648 597 5 1 4 0 - - -; #X msg 638 689 1 1 0; #X connect 0 0 1 0; #X connect 1 0 2 1; #X connect 2 0 3 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 3 1; #X connect 5 0 49 0; #X connect 6 0 2 0; #X connect 7 0 6 1; #X connect 8 0 9 1; #X connect 9 0 12 0; #X connect 10 0 9 1; #X connect 11 0 6 1; #X connect 12 0 3 1; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 14 0 29 0; #X connect 14 1 17 1; #X connect 15 0 16 0; #X connect 16 0 17 0; #X connect 17 0 14 0; #X connect 18 0 35 0; #X connect 19 0 20 0; #X connect 20 0 3 0; #X connect 21 0 3 0; #X connect 22 0 23 0; #X connect 23 0 19 0; #X connect 26 0 16 1; #X connect 27 0 16 1; #X connect 29 0 22 0; #X connect 29 1 21 0; #X connect 30 0 32 0; #X connect 30 1 37 0; #X connect 30 1 38 0; #X connect 31 0 9 0; #X connect 31 0 10 0; #X connect 31 0 11 0; #X connect 31 1 0 0; #X connect 31 1 7 0; #X connect 31 1 8 0; #X connect 31 2 7 0; #X connect 31 2 8 0; #X connect 31 2 2 1; #X connect 32 0 4 0; #X connect 33 0 32 1; #X connect 34 0 32 1; #X connect 35 0 10 0; #X connect 35 0 11 0; #X connect 35 0 9 0; #X connect 38 0 33 0; #X connect 38 2 34 0; #X connect 38 2 31 0; #X connect 40 0 13 0; #X connect 41 0 43 1; #X connect 42 0 41 0; #X connect 43 0 44 0; #X connect 44 0 43 0; #X connect 45 0 46 0; #X connect 46 0 54 0; #X connect 47 0 48 0; #X connect 48 0 49 0; #X connect 50 0 49 0; #X connect 51 0 49 1; #X connect 52 0 50 0; #X connect 52 0 51 0; #X connect 53 0 54 2; #X connect 54 0 47 0; #X connect 56 0 63 0; #X connect 58 0 57 1; #X connect 59 0 60 0; #X connect 60 0 57 0; #X connect 61 0 63 2; #X connect 62 0 57 0; #X connect 63 0 62 0; #X connect 64 0 62 1; #X connect 65 0 57 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] block~ vs. freeverb~
Hi, Now that I have upsampling working, I hear that the output of freeverb~ is completely different when it is computed in an upsampled environment. There's hardly any reverb effect at all. Any ideas? Cheers, David ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd -nogui, connecting/disconnecting from soundcards
In Ubuntu ... When running pd with -nogui as a daemon, can I send messages to connect to and disconnect from a soundcard? I want to be able to hot plug my usb soundcard without having to stop and start pd each time, if possible. --- Dan Wilcox robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] block~ vs. freeverb~
On Mon, 2008-10-20 at 20:08 +0200, Derek Holzer wrote: Multiply the decay time by the same factor that you are upsampling? There isn't a parameter that corresponds directly to decay time? Fooling with the parameters doesn't make much difference. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] block~ vs. freeverb~
Try sending very large values to roomsize, which would make longer reverb tails, and very small or 0 value to damping, which increases decay time. My guess is that [freeverb~] calculates the decay time in samples somehow, thus the very short reverb times at very fast sampling rates. Alternately, move [freeverb~] out of the upsampled subptach, it's probably eating tons of CPU by being there anyways. Try to concentrate only the objects which might produce aliasing in you upsampled section... oscillators, pretty much, although I don't know exactly what you are doing with waveshaping so I can't tell if that could produce aliasing as well. But anything else getting upsampled besides the potentially aliasing objects and the filters used to anti-alias them is really a huge waste of CPU. best! d. David F. Place wrote: On Mon, 2008-10-20 at 20:08 +0200, Derek Holzer wrote: Multiply the decay time by the same factor that you are upsampling? There isn't a parameter that corresponds directly to decay time? Fooling with the parameters doesn't make much difference. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 204: What do you do? Now, what do you do best?' ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scope of [block~] and [switch~]
Putting [samplerate~] in the subpatch of Miller's upsampling help patch gives the correct upsampled rate. But I guess Miller's warning about the overlap could factor in here as well. d. IOhannes m zmoelnig wrote: Derek Holzer wrote: Hi David, try putting [samplerate~] in each subpatch or abstraction to see if the afair, [samplerate~] will always output the _system_ samplerate (the one locked to the soundcard); it is not affected by up/downsampling. fmgasd IOhannes -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 99: Is there something missing? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] block~ vs. freeverb~
On Mon, 2008-10-20 at 20:52 +0200, Derek Holzer wrote: My guess is that [freeverb~] calculates the decay time in samples somehow, thus the very short reverb times at very fast sampling rates. Alternately, move [freeverb~] out of the upsampled subptach, it's probably eating tons of CPU by being there anyways. Looking at the source code for freeverb~.c, it seems the comb filters are hand tuned assuming a 44.1kHz sample rate. So...freeverb and upsampling don't mix. Cheers, David ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] create typewriter for gem
hi, same here, have fun Le lundi 20 octobre 2008 à 18:02 +0200, Georg Werner a écrit : hi philippe, i played a little bit around: see the attached. g. philippe boisnard schrieb: Hello I have an other question Since 2 years, I create typewriter for my creations, but I think, that it's ver artisanal = metro + moses + sel (cf. example). Somebody have idea to create a nice typewriter ? thx phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list pièce jointe document texte brut (GEMtypewriter.pd) #N canvas 792 44 872 739 10; #X msg 203 503 32; #X obj 203 529 makefilename %c; #X obj 170 568 symbol; #X obj 169 600 list prepend; #X obj 8 365 sel 1; #X obj 169 624 list-l2s; #X obj 170 480 spigot 0; #X msg 215 411 1; #X msg 245 411 0; #X obj 78 471 spigot 0; #X msg 158 411 1; #X msg 187 411 0; #X msg 78 493 symbol; #X obj 537 146 any2string; #X obj 537 170 list split 1; #X obj 471 200 t b; #X obj 471 222 delay 100; #X obj 537 250 list append; #X obj 359 94 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 568 343 makefilename %c; #X obj 568 364 symbol; #X obj 613 363 string2any; #X obj 568 300 t b; #X msg 568 321 32; #X text 15 222 Enter your text with the keyboard and clear it with 'Return'.; #X text 382 92 reset; #X msg 553 196 100; #X msg 591 196 1000; #X text 630 195 speed; #X obj 568 277 route 32; #X obj 8 262 keyname; #X obj 158 370 sel Return Space; #X obj 8 335 spigot; #X msg 47 307 0; #X msg 79 307 1; #X obj 359 364 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 382 362 reset; #X symbolatom 62 263 10 0 0 0 - - -; #X obj 47 285 sel Shift_L Shift_R; #X text 171 285 disabled keys; #X msg 537 96 this is the text; #X msg 58 68 lighting \$1; #X obj 58 46 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #N canvas 855 130 450 300 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 256 112 destroy; #X obj 322 45 inlet; #X msg 132 112 create \, 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 8 0; #X connect 3 1 5 0; #X connect 3 1 6 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 0 0; #X restore -10 99 pd gemwin; #X msg -10 77 destroy; #X obj 410 580 gemhead; #X obj 410 600 translateXYZ; #X obj 409 654 colorRGB; #X obj 412 677 alpha; #X obj 412 698 textextruded; #X msg 493 681 depth 9; #X msg 544 681 9; #X obj 520 664 loadbang; #X floatatom 522 607 5 0 0 0 - - -; #X obj 408 624 rotateXYZ 0 0 0; #X text 464 94 click here; #X obj 608 550 gemhead; #X obj 608 711 light; #X msg 695 689 1 1 1; #X obj 622 644 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X msg 622 665 debug \$1; #X floatatom 688 554 5 0 0 0 - - -; #X obj 608 615 translateXYZ 2 0 0; #X obj 608 572 rotateXYZ 0 -120 0; #X floatatom 648 597 5 1 4 0 - - -; #X msg 638 689 1 1 0; #X connect 0 0 1 0; #X connect 1 0 2 1; #X connect 2 0 3 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 3 1; #X connect 5 0 49 0; #X connect 6 0 2 0; #X connect 7 0 6 1; #X connect 8 0 9 1; #X connect 9 0 12 0; #X connect 10 0 9 1; #X connect 11 0 6 1; #X connect 12 0 3 1; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 14 0 29 0; #X connect 14 1 17 1; #X connect 15 0 16 0; #X connect 16 0 17 0; #X connect 17 0 14 0; #X connect 18 0 35 0; #X connect 19 0 20 0; #X connect 20 0 3 0; #X connect 21 0 3 0; #X connect 22 0 23 0; #X connect 23 0 19 0; #X connect 26 0 16 1; #X connect 27 0 16 1; #X connect 29 0 22 0; #X connect 29 1 21 0; #X connect 30 0 32 0; #X connect 30 1 37 0; #X connect 30 1 38 0; #X connect 31 0 9 0; #X connect 31 0 10 0; #X connect 31 0 11 0; #X connect 31 1 0 0; #X connect 31 1 7 0; #X connect 31 1 8 0; #X connect 31 2 7 0; #X connect 31 2 8 0; #X connect 31 2 2 1; #X connect 32 0 4 0; #X connect 33 0 32 1; #X connect 34 0 32 1; #X connect 35 0 10 0; #X connect 35 0 11 0; #X connect 35 0 9 0; #X connect 38 0 33 0; #X connect 38 2 34 0; #X connect 38 2 31 0; #X connect 40 0 13 0; #X connect 41 0 43 1; #X connect 42 0 41 0; #X connect 43 0 44 0; #X connect 44 0 43 0; #X connect 45 0 46 0; #X connect 46 0 54 0; #X connect 47 0 48 0; #X connect 48 0 49 0; #X connect 50 0 49 0; #X connect 51 0 49 1; #X connect 52 0 50 0; #X connect 52 0 51 0; #X connect 53 0 54 2; #X connect 54 0 47 0; #X connect 56 0 63 0; #X connect 58 0 57 1; #X connect 59 0 60 0; #X connect 60 0 57 0; #X connect 61 0 63 2; #X connect 62 0 57 0; #X connect 63 0 62 0; #X connect 64 0 62 1; #X connect 65 0 57 1;
Re: [PD] Scope of [block~] and [switch~]
On Mon, Oct 20, 2008 at 10:42 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: Miller Puckette wrote: Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it correct' or just leave it wrong. personally i would just change it. if somebody relies on a certain upsampling algorithm, they should explicitely specify so in the creation arguments. (or even better, use a separate object that fills the gaps in the zero-padded signal with something more sophisticated) only tricky part about it, is that the method to perform interpolation/extrapolation on the zero-padded signal depends on the upsampling ratio. A separate object would have to be passed (or query for) the upsampling ratio. There is a method by fft, that will perform extrapolation as well as interpolation during upsampling--it's limitation is that the points at the ends of the block may not have continuity between blocks (OTOH--this problem is always there). For an upsampling ratio of k and original size n: Take the fft of the signal at the original rate, multiply by k, pad the end with k*(n-1) zeros and take the ifft. O(kn*log(kn)) 4-point interpolation is nearly trivial--there's still the problem of what to do at the end points. However, given that it has a fixed rate, coefficients for interpolation can be calculated beforehand. Then, it takes 4 multiplies and 3 adds per zero. Total: 4*n*(k-1) multiplies and 3*n*(k-1) adds. Both methods could be optimally coded by omitting the zero-interleaving step. But it comes down to--what representation is most useful? Why go to all the trouble of interpolating, if what you really want is a zero-interleaved signal? Why zero-interleave first, and interpolate second? So, I would favor an optional creation argument for specifying an interpolation method in place of the zero-interleaving step. Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] live distro with pd extended
Hans-Christoph Steiner said : We did switch to this layout a while ago, indeed after some talks around this issue, the only difference is that we use Pd vanilla and we package externals separately and we make everything possible to have 100% conform Debian packages. We start to have a pretty good collection now. Wow, that's great news! That is quite a collection. It would be great to build upon this work to make official Debian packages for all this. Well that's the plan :) If all goes well, sometimes in 2009 we'll be able to start moving what is packaged in p:d from the GOTO10 repos to Debian. (we'll be doing the same for our supercollider packages and all the stuff that is in p:d but not in Debian yet). a. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] live distro with pd extended
ola, If all goes well, sometimes in 2009 we'll be able to start moving what is packaged in p:d you say p:d because it's pure:debian and debian is from DEBorah and IAN ? sorry you know, i think of doing stand-up comedy now ciao, sevy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
