[PD] Connecting VLC-Player with pd under Windows
Carlo, Does VLC support ASIO? If it does, the windows version of jackdmp can help you stream audio to and from VLC to other ASIO-applications such as Pd: http://www.grame.fr/~letz/jackdmp.html /Anton ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Csound opcode Moogladder to Pd
I now made a version where cutoff and resonance are signals. This version is a bit more CPU intensive now, as some computations had to move into the DSP loop to react to the changes in center frequency. Awesome! To my ears it sounds great - very close to the Csound-version. I played a bit with a rational tanh approximation from the music-dsp list but it didn't sound good anymore. If someone wants to play with other approximations e.g. table lookup: Just change the function mytanh. Some optimizations are needed for reducing cpu load, true, I'll look into it. The filter response gets nasty and loud if the center frequency is near or above the sampling rate. Maybe it should be restricted as well. But then, resonance at 1 will make everyone jump, too... Yeah I noticed that aswell. I think the Csound-version has cutoff restricted to 0...1, which is 0...11050 in hertz. Thanks again. /Anton ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Csound opcode Moogladder to Pd?
Frank - that was fast! Thanks! I haven't had time to try it out yet but will report back when I get home. The csound opcode I've used myself is a modification of the original with signal input for cutoff (please find it attached). Signal input for both cutoff and resonance would of course be awesome. If anyone could compile a windows binary of this I would be very grateful. I use both winxp and ubuntu. /Anton ml_aak-csound.csd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Csound opcode Moogladder to Pd?
I've used the Csound opcode Moogladder (based on an algorithm by Antti Huovilainen) in Pd using csoundapi~. It uses a lot of cpu cycles but it sounds really good. The csoundapi~ external is useful but it only allows one instance per patch on windows so ideally I would like to have this opcode as a Pd abstraction or external and get rid of the csoundapi~ external. Is it possible to convert the Moogladder opcode to a Pd abstraction? Csound code: http://www.csounds.com/udo/displayOpcode.php?opcode_id=32 /Anton ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] 'pure' pd DSP abstractions wanted!
Hi, I'm looking self-contained DSP abstractions that only use Pd - no externals. Things like reverbs, different types of filters, delays, a pitch shifter, harmonizer -- a kind of basic 'FX' toolbox. The jon~ reverb abstraction I posted to the list does not require any externals: http://lists.puredata.info/pipermail/pd-list/2008-05/061959.html http://www.hornquist.se/pd/jon Thoughts I've had so far: - Pull stuff out of the Pd help patches I like rev1~, rev2~, rev3~ from pd vanilla. the H15.phaser.pd patch is also quite nice.. There are lots of stuff in there. But, maybe someone has a nice 'set' of such abstractions sitting on their hard drive, that they wouldn't mind releasing into the public domain -- or under some permissive license. In my view jon~ is open source so feel free to use it in any way. I'm not sure how to... well.. document this. What's the best and simplest way? Should I write something about it in the help patch? What license should I use - GPL? Any hints about this are appreciated. :) /Anton ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] jon~ (was: Dattorro plate)
On Wed, May 7, 2008 at 5:20 AM, Chris McCormick [EMAIL PROTECTED] wrote: Wow, great reverb! 0% CPU and it sounds sweet. Do you mind if I package it up into a GOP abstraction and include it in my s-abstractions collection (with appropriate credit to yourself of course)? Thanks. Sure, use it anyway you want - I like the s-abstractions! If I rememeber correctly jon~-help.pd uses 7-8 % on my aging Thinkpad T43. I've tried to be as close to the article (page 3-4 of the pdf) as possible with jon~. I'm working on jone~ (jon~ extended) which has more modulation points in the reverberation network and additional parameters, such as bandwidth high pass. I have a GOP'ified versions of jon~ and jone~ on the way as well. I'll post them soon. Note that the diffusion parameters can be a bit confusing in my jon~-help.pd patch. I think Dattorro discusses this in the article. In my help patch the range of the diffusion parameters is 0 to 1.0. The ideal range for decay diffusion seems to be decay + 0.15, floor = 0.25, ceiling = 0.50 according to the article. But this, of course, is open to experimentation. /Anton ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] jon~ (was: Dattorro plate)
actually, i was looking for a pd-based reverb for my current project and the rev~* trilogy didn't quite fit my needs (i didn't find a way to create smaller rooms, even with short decays those sound like a big hall). your reverb sounds great (also the rev~* do, of course) and it is also quite what i was looking for in terms of roomsize. thanks for sharing it. Thanks! I think I can get even smaller room sounds by experimenting with the output tap structure. if you don't mind, i'll put it into pdmtl collection, as soon as i find time (when finished with the current project). I dont mind at all! :) a note on the implementation: some values seem to be hardcoded for a sampling rate of 44100. probably it would make sense to use [samplerate~] instead, so that the reverb sounds similar at different rates. Thanks. I'll look into this - I havent tried the patch in any other samplerates. There's some text in the patch that may be confusing, though, cause it's only a reference to the figure in page 3 of the PDF article. For example [pd z^-4453] is not a sample-wise delay of 4453 as one would expect. It's a subpatcher with delwrite and delread 149.625 milliseconds. I got this by dividing 4453 by sample rate 29761 Hz (4453 / 29761 = ~0.149625) as stated in the table on page 4. I hope this is correct, I'm not sure. :) I think I'll change the pd z^-4453 text to avoid confusion anyways. /Anton ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] jon~ (was: Dattorro plate)
Hello list! Here's jon~, a reverb abstraction based on the algorithm in this article by Jon Dattorro: http://www.stanford.edu/~dattorro/EffectDesignPart1.pdf The allpass bit was taken from pd-list and the help file is copied from Millers rev3~-help and then modified a bit. Any feedback is appreciated. /Anton http://www.hornquist.se/pd/jon #N canvas 229 105 390 422 12; #X obj 24 32 inlet~; #X obj 27 282 outlet~; #X obj 135 282 outlet~; #N canvas 0 166 634 506 input_diffusion 0; #X obj 30 60 inlet~; #X obj 29 295 outlet~; #X obj 337 79 r \$0-input_diffusion1; #X obj 336 170 r \$0-input_diffusion2; #N canvas 393 17 574 578 allpass 0; #X obj 56 127 inlet~; #X obj 56 400 +~; #X obj 427 232 loadbang; #X obj 417 286 t f f; #X obj 417 310 *; #X obj 417 334 expr 1-$f1; #X obj 253 364 *~; #X obj 232 394 +~; #X obj 114 177 * -1; #X obj 88 207 *~; #X obj 232 426 outlet~; #X obj 417 129 inlet; #X obj 114 117 loadbang; #X obj 75 365 *~ -1; #X obj 201 364 *~ -1; #X obj 114 149 f 0.75; #X obj 417 262 f 0.75; #X obj 56 491 delwrite~ \$0-tap_13_14 200; #X obj 252 262 *~ 0.75; #X obj 252 53 delread~ \$0-tap_13_14 4.77134; #X connect 0 0 1 0; #X connect 0 0 9 0; #X connect 1 0 17 0; #X connect 2 0 16 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 5 0; #X connect 5 0 6 1; #X connect 6 0 7 1; #X connect 7 0 10 0; #X connect 8 0 9 1; #X connect 9 0 14 0; #X connect 11 0 15 0; #X connect 11 0 16 0; #X connect 11 0 18 1; #X connect 12 0 15 0; #X connect 13 0 1 1; #X connect 14 0 7 0; #X connect 15 0 8 0; #X connect 16 0 3 0; #X connect 18 0 6 0; #X connect 18 0 13 0; #X connect 19 0 18 0; #X restore 30 99 pd allpass tap_13_14; #N canvas 314 10 579 582 allpass 0; #X obj 56 127 inlet~; #X obj 56 400 +~; #X obj 427 232 loadbang; #X obj 417 286 t f f; #X obj 417 310 *; #X obj 417 334 expr 1-$f1; #X obj 253 364 *~; #X obj 232 394 +~; #X obj 114 177 * -1; #X obj 88 207 *~; #X obj 232 426 outlet~; #X obj 417 129 inlet; #X obj 114 117 loadbang; #X obj 75 365 *~ -1; #X obj 201 364 *~ -1; #X obj 114 149 f 0.75; #X obj 417 262 f 0.75; #X obj 252 262 *~ 0.75; #X obj 56 491 delwrite~ \$0-tap_19_20 200; #X obj 252 53 delread~ \$0-tap_19_20 3.5953; #X connect 0 0 1 0; #X connect 0 0 9 0; #X connect 1 0 18 0; #X connect 2 0 16 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 5 0; #X connect 5 0 6 1; #X connect 6 0 7 1; #X connect 7 0 10 0; #X connect 8 0 9 1; #X connect 9 0 14 0; #X connect 11 0 15 0; #X connect 11 0 16 0; #X connect 11 0 17 1; #X connect 12 0 15 0; #X connect 13 0 1 1; #X connect 14 0 7 0; #X connect 15 0 8 0; #X connect 16 0 3 0; #X connect 17 0 6 0; #X connect 17 0 13 0; #X connect 19 0 17 0; #X restore 30 135 pd allpass tap_19_20; #N canvas 238 0 570 590 allpass 0; #X obj 56 127 inlet~; #X obj 56 400 +~; #X obj 427 232 loadbang; #X obj 417 286 t f f; #X obj 417 310 *; #X obj 417 334 expr 1-$f1; #X obj 253 364 *~; #X obj 232 394 +~; #X obj 114 177 * -1; #X obj 88 207 *~; #X obj 232 426 outlet~; #X obj 417 129 inlet; #X obj 114 117 loadbang; #X obj 75 365 *~ -1; #X obj 201 364 *~ -1; #X obj 114 149 f 0.625; #X obj 252 262 *~ 0.625; #X obj 417 262 f 0.625; #X obj 56 491 delwrite~ \$0-tap_15_16 200; #X obj 252 53 delread~ \$0-tap_15_16 12.7348; #X connect 0 0 1 0; #X connect 0 0 9 0; #X connect 1 0 18 0; #X connect 2 0 17 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 5 0; #X connect 5 0 6 1; #X connect 6 0 7 1; #X connect 7 0 10 0; #X connect 8 0 9 1; #X connect 9 0 14 0; #X connect 11 0 15 0; #X connect 11 0 16 1; #X connect 11 0 17 0; #X connect 12 0 15 0; #X connect 13 0 1 1; #X connect 14 0 7 0; #X connect 15 0 8 0; #X connect 16 0 6 0; #X connect 16 0 13 0; #X connect 17 0 3 0; #X connect 19 0 16 0; #X restore 30 190 pd allpass tap_15_16; #N canvas 238 0 566 586 allpass 0; #X obj 56 127 inlet~; #X obj 56 400 +~; #X obj 427 232 loadbang; #X obj 417 286 t f f; #X obj 417 310 *; #X obj 417 334 expr 1-$f1; #X obj 253 364 *~; #X obj 232 394 +~; #X obj 114 177 * -1; #X obj 88 207 *~; #X obj 232 426 outlet~; #X obj 417 129 inlet; #X obj 114 117 loadbang; #X obj 75 365 *~ -1; #X obj 201 364 *~ -1; #X obj 114 149 f 0.625; #X obj 252 262 *~ 0.625; #X obj 417 262 f 0.625; #X obj 56 491 delwrite~ \$0-tap_21_22 200; #X obj 252 53 delread~ \$0-tap_21_22 9.30748; #X connect 0 0 1 0; #X connect 0 0 9 0; #X connect 1 0 18 0; #X connect 2 0 17 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 5 0; #X connect 5 0 6 1; #X connect 6 0 7 1; #X connect 7 0 10 0; #X connect 8 0 9 1; #X connect 9 0 14 0; #X connect 11 0 15 0; #X connect 11 0 16 1; #X connect 11 0 17 0; #X connect 12 0 15 0; #X connect 13 0 1 1; #X connect 14 0 7 0; #X connect 15 0 8 0; #X connect 16 0 6 0; #X connect 16 0 13 0; #X connect 17 0 3 0; #X connect 19 0 16 0; #X restore 30 230 pd allpass tap_21_22; #X connect 0 0 4 0; #X connect 2 0 4 1; #X connect 2 0 5 1; #X connect 3 0 6 1; #X connect 3 0 7 1; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 1 0; #X restore 25 168 pd input_diffusion; #N canvas 38
[PD] Dattorro plate
Has anyone tried to implement Jon Dattorro's plate algorithm in Pd? I guess it is a bit similar to Miller's Rev3~, constructed of all-pass filters? http://www.stanford.edu/~dattorro/EffectDesignPart1.pdf cheers, Anton ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Dattorro plate
Nice paper! Looks like everything's there you need to implement it. Yep *scratches head* I'm a bit of a dsp newbie but I thought I'd give it a go. I think the CAPS ladspa plate is loosely based around this algo. But plugin~ is a bit unstable on my machine so I'd like to try to make it an abstraction. Where can I get a copy of Millers Rev3~ btw ? In Pd vanilla, 0.40-2, I think. The rev3~ abstraction in the extra folder. Cheers Anton ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI on Win XP
Thanks for the help. Using ASIO4ALL with Firewire 410 (instead of the official ones) seemed to solve the midi problem. I've used ASIO4ALL with my internal laptop card some time but wasn't aware it would work for firewire devices aswell. The official Firewire 410 drivers work fine with all other audio software I use though, so there's something strange about Pd with these particular drivers. Cheers, Anton On Jan 4, 2008 10:09 PM, jeremaja niko [EMAIL PROTECTED] wrote: hi i think i remember a similar problem in my case i have 2 soundcard: via-integrated and m-audio-delta1010 similar (or same) latency problem ocured when i was using midi from m-audio and audio engine on my via. so im using always my m-audio card for everything (anyway better;) i think that it may be the problem of cheap soundcard, or the drivers for it. maybe you can try some stuff like asio4all and try to run it with this driver, maybe try with a better quality soundcard... my only recommendation is to try all possibilities with your audio-midi connections :) hope this brings u somwhere greets nikola Anton Hörnquist wrote: On Jan 4, 2008 6:16 PM, Patrice Colet [EMAIL PROTECTED] wrote: with Pd (Win XP) but I'm running into problems. When I move a knob on the midi controller there is a delay of at least one second until the controller data show up in the Pd window (I simply output controllers using the [ctlin] object). This delay makes it pretty much unusable. I did you try MIDI controllers with another software? Yes - the controller works perfectly with the other software I've tested it with (Ableton Live, Max/MSP, MIDI-OX) tried different command line arguments to find something that could speed things up and I managed to get quick midi input through the [ctlin] object, if I used -noaudio. But I'd like to use the audio system, so that's not really an option for me. Is MIDI on Win XP Pd really this bad? There is a warning message showing up in the Pd window when using MIDI on windows. What is this error message? In the Pd window: Warning: midi input is dangerous in Microsoft Windows\; see Pd manual) MIDI on XP is bad indeed, and I have to run my midi application under linux to get a latency lower than human sound perception, without artefacts, and with a cheap soundcard. If you know a bit about development you might be interested about this: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargame/html/msdn_mlatency.asp Anyway, I suggest to have a deep look into your computer configuration, you might have a problem with the system. Thanks for the link, I'll look into it! But this is not a general Win XP problem for me, it's a Pd problem. As I wrote, other programs work fine, no latency at all. When I only use the midi system of Pd it works fine. But when I use both the audio and midi system in Pd, there is delay in incoming midi. Cheers Anton ___ 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] MIDI on Win XP
On Jan 4, 2008 6:16 PM, Patrice Colet [EMAIL PROTECTED] wrote: with Pd (Win XP) but I'm running into problems. When I move a knob on the midi controller there is a delay of at least one second until the controller data show up in the Pd window (I simply output controllers using the [ctlin] object). This delay makes it pretty much unusable. I did you try MIDI controllers with another software? Yes - the controller works perfectly with the other software I've tested it with (Ableton Live, Max/MSP, MIDI-OX) tried different command line arguments to find something that could speed things up and I managed to get quick midi input through the [ctlin] object, if I used -noaudio. But I'd like to use the audio system, so that's not really an option for me. Is MIDI on Win XP Pd really this bad? There is a warning message showing up in the Pd window when using MIDI on windows. What is this error message? In the Pd window: Warning: midi input is dangerous in Microsoft Windows\; see Pd manual) MIDI on XP is bad indeed, and I have to run my midi application under linux to get a latency lower than human sound perception, without artefacts, and with a cheap soundcard. If you know a bit about development you might be interested about this: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargame/html/msdn_mlatency.asp Anyway, I suggest to have a deep look into your computer configuration, you might have a problem with the system. Thanks for the link, I'll look into it! But this is not a general Win XP problem for me, it's a Pd problem. As I wrote, other programs work fine, no latency at all. When I only use the midi system of Pd it works fine. But when I use both the audio and midi system in Pd, there is delay in incoming midi. Cheers Anton ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
