Re: [PD] optimizing big patches
wow, I always felt message passing was unnecessarily expensive but I didnt realise message passing was that expensive! I seriously think it would be good to have a pd front end for gcc, a few of us should take the time to learn GIMPLE and implement a compile menu item to compile patches/subpatches. 2011/1/10 Mathieu Bouchard ma...@artengine.ca: On Sun, 9 Jan 2011, Pedro Lopes wrote: i Guess the question could go a bit further, how can we devise a profiling system for a dataflow programming environment? I made two or three of those... GridFlow had several incarnations of such a thing but it only worked for GridFlow's own objects. Then I made one for the whole of Pd, and it's somewhere in the DesireData branch, but it caused occasional crashes for mysterious reasons, and no-one else looked at the code. Here's a screenshot of the latter : http://artengine.ca/desiredata/gallery/simple-benchmark.png You see that [cos] is over twice slower than [*] but [t f f] minus those two is also a lot, but that's the cost of message-passing, because [t f f] doesn't do any processing. And so on... the top number is the total time for the first message to return (every message-passing down a wire is accompanied later by an opposite movement once the job is done... that's the stack). GridFlow's profiler instead had a menu in Pd's main window which had a reset and a dump and the latter would print non-cumulative measurements (i.e. it doesn't include time in objects sent to) in the console (or in the terminal back when there wasn't a console) sorted by decreasing importance. Ideally we would have both cumulative and non-cumulative figures, because neither is nearly as useful as both together. ___ | 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] change in compression detection
On Sun, 2011-01-09 at 20:26 -0500, Mathieu Bouchard wrote: On Mon, 10 Jan 2011, ~E. wrote: I'm searching how i can detect the change in the compression of an audio signal. The purpose is to detect (and quantified) the compression changes between the music and the ads in a radioshow. Have any ideas ? If you don't have the original uncompressed recordings, I don't see how you could be doing that. You'd have to guess how complex sounds are supposed to fade out normally, to find out how much the fade out has been messed with. And then, in the compressor, you have both a measurement of input volume and a formula for turning that input volume into a gain to be applied, and both of those parts are subject to a lot of variation and tweaking. Assuming that the more compression is applied, the more the RMS amplitude [1] approaches the Peak amplitude [2] of an audio signal, you could measure the two and probably get a raw grasp how much compression was applied. This is simply an idea for which I don't have any reference that it is really working. I could imagine that recordings of certain sets of natural instruments show always a similar relation between peak and RMS amplitude for that set. However, usually there is already some compression applied when releasing the recording which makes it hard to distinct compression applied in the radio station from the compression shipped with the recording. I also could imagine, that it's much harder to find applicable rules for synthesized sounds. Roman [1] http://en.wikipedia.org/wiki/Amplitude#Root_mean_square_amplitude [2] http://en.wikipedia.org/wiki/Amplitude#Peak_amplitude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] change in compression detection
Or more generally, watch the histogram of samples On 10 January 2011 11:09, Roman Haefeli reduz...@gmail.com wrote: On Sun, 2011-01-09 at 20:26 -0500, Mathieu Bouchard wrote: On Mon, 10 Jan 2011, ~E. wrote: I'm searching how i can detect the change in the compression of an audio signal. The purpose is to detect (and quantified) the compression changes between the music and the ads in a radioshow. Have any ideas ? If you don't have the original uncompressed recordings, I don't see how you could be doing that. You'd have to guess how complex sounds are supposed to fade out normally, to find out how much the fade out has been messed with. And then, in the compressor, you have both a measurement of input volume and a formula for turning that input volume into a gain to be applied, and both of those parts are subject to a lot of variation and tweaking. Assuming that the more compression is applied, the more the RMS amplitude [1] approaches the Peak amplitude [2] of an audio signal, you could measure the two and probably get a raw grasp how much compression was applied. This is simply an idea for which I don't have any reference that it is really working. I could imagine that recordings of certain sets of natural instruments show always a similar relation between peak and RMS amplitude for that set. However, usually there is already some compression applied when releasing the recording which makes it hard to distinct compression applied in the radio station from the compression shipped with the recording. I also could imagine, that it's much harder to find applicable rules for synthesized sounds. Roman [1] http://en.wikipedia.org/wiki/Amplitude#Root_mean_square_amplitude [2] http://en.wikipedia.org/wiki/Amplitude#Peak_amplitude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] flocons (fwd)
That for me they are not as beautiful :) hehe. On Sun, Jan 9, 2011 at 3:06 AM, Mathieu Bouchard ma...@artengine.ca wrote: On Sat, 8 Jan 2011, Pedro Lopes wrote: http://gridflow.ca/gallery/flocon_256_114_14.png This one is beautiful. What does that imply about the other ones ? ;) ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -- Pedro Lopes (MSc) contact: pedro.lo...@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] exquisite caos audio theory
but I like it On Sat, Jan 8, 2011 at 2:53 PM, oskoff lovich noi...@gmail.com wrote: its only a gif and audio player embed but .. http://nuevocalipso.tumblr.com/caosTheory -- http://noconventions.mobi/noish ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ 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] question about csound and pd
Hello , i been using csound inside pd lately , I use csoundapi only for synthesis inside pd and then i control everything with pd. For doing this i edit the csound code and add this line: gk1 invalue variable_name, then i replace gk1 in the csound code wherever i want to use that values, then i can send values to that variable from pd. This works fine in most all cases, but not always. My question is why in this specific case it does not work? I using the example code of the Partikkel opcode, and i would like to control this parameters from pd: Osc2Dev and MaxSync Do anybody have an idea why this is not working? ; Select audio/midi flags here according to platform ; Audio out -odac ;;;RT audio ; For Non-realtime ouput leave only the line below: ; -o partikkel_softsync.wav -W ;;; for file output any platform sr = 44100 ksmps = 20 nchnls = 2 ; Example by Oeyvind Brandtsegg 2007, revised 2008 giSine ftgen 0, 0, 65537, 10, 1 giCosine ftgen 0, 0, 8193, 9, 1, 1, 90 giSigmoRise ftgen 0, 0, 8193, 19, 0.5, 1, 270, 1 ; rising sigmoid giSigmoFall ftgen 0, 0, 8193, 19, 0.5, 1, 90, 1 ; falling sigmoid ; * ; example of soft synchronization of two partikkel instances ; * instr 1 gk1 invalue igrainrate gk2 invalue igrainsize gk3 invalue igrainFreq gk4 invalue iosc2Dev gk5 invalue iMaxSync gk6 invalue mask gk7 invalue fm /*score parameters*/ igrainrate = p4 ; grain rate igrainsize = p5 ; grain size in ms igrainFreq = p6 ; fundamental frequency of source waveform iosc2Dev = p7 ; partikkel instance 2 grain rate deviation factor iMaxSync = p8 ; max soft sync amount (increasing to this value during length of note) awavfm = p9 /*overall envelope*/ iattack = 0.001 idecay = 0.2 isustain = 0.7 irelease = 0.2 amp linsegr 0, iattack, 1, idecay, isustain, 1, isustain, irelease, 0 kgrainfreq = gk1 ; grains per second kdistribution = 0 ; periodic grain distribution idisttab = -1 ; (default) flat distribution used ; for grain distribution async = 0 ; no sync input kenv2amt = 1 ; no secondary enveloping ienv2tab = -1 ; default secondary envelope (flat) ienv_attack = giSigmoRise ; default attack envelope (flat) ienv_decay = giSigmoFall ; default decay envelope (flat) ksustain_amount = 0.3 ; time (in fraction of grain dur) at ; sustain level for each grain ka_d_ratio = 0.2 ; balance between attack and decay time kduration = igrainsize ; set grain duration in ms kamp = 0.2*0dbfs ; amp igainmasks = -1 ; (default) no gain masking kwavfreq = gk3 ; fundamental frequency of source waveform ksweepshape = 1 ; shape of frequency sweep (0=no sweep) iwavfreqstarttab = -1 ; default frequency sweep start ; (value in table = 1, which give ; no frequency modification) iwavfreqendtab = -1 ; default frequency sweep end ; (value in table = 1, which give ; no frequency modification) awavfm = 7 ; no FM input ifmamptab = -1 ; default FM scaling (=1) kfmenv = -1 ; default FM envelope (flat) icosine = giCosine ; cosine ftable kTrainCps = kgrainfreq ; set trainlet cps equal to grain ; rate for single-cycle trainlet in ; each grain knumpartials = 3 ; number of partials in trainlet kchroma = 1 ; balance of partials in trainlet ichannelmasks = -1 ; (default) no channel masking, ; all grains to output 1 krandommask = 0 ; no random grain masking kwaveform1 = giSine ; source waveforms kwaveform2 = giSine ; kwaveform3 = giSine ; kwaveform4 = giSine ; iwaveamptab = -1 ; mix of 4 source waveforms and ; trainlets (set to default) asamplepos1 = 0 ; phase offset for reading source waveform asamplepos2 = 0 ; asamplepos3 = 0 ; asamplepos4 = 0 ; kwavekey1 = 1 ; original key for source waveform kwavekey2 = 1 ; kwavekey3 = 1 ; kwavekey4 = 1 ; imax_grains = 200 ; max grains per k period iopcode_id = 1 ; id of opcode, linking partikkel ; to partikkelsync a1 partikkel kgrainfreq, kdistribution, idisttab, async, kenv2amt, \ ienv2tab,ienv_attack, ienv_decay, ksustain_amount, ka_d_ratio, \ gk2, kamp, igainmasks, kwavfreq, ksweepshape, \ iwavfreqstarttab, iwavfreqendtab, awavfm, ifmamptab, kfmenv, \ icosine, kTrainCps, knumpartials, kchroma, ichannelmasks, \ gk6, kwaveform1, kwaveform2, kwaveform3, kwaveform4, \ iwaveamptab, asamplepos1, asamplepos2, asamplepos3, asamplepos4, \ kwavekey1, kwavekey2, kwavekey3, kwavekey4, imax_grains, iopcode_id async1 partikkelsync iopcode_id ; clock pulse output of the ; partikkel instance above ksyncGravity line 0, p3, gk5 ; strength of synchronization aphase2 init 0 asyncPolarity limit (int(aphase2*2)*2)-1, -1, 1 ; use the phase of partikkelsync instance 2 to find sync ; polarity for partikkel instance 2. ; If the phase of instance 2 is less than 0.5, we want to ; nudge it down when synchronizing, ; and if the phase is 0.5 we want to nudge it upwards. async1 = async1*ksyncGravity*asyncPolarity ; prepare sync signal ; with polarity and strength kgrainfreq2 = igrainrate * gk4 ; grains per second for second partikkel instance iopcode_id2 =
[PD] partikkel and pd
hi again , I was wondering if somebody have used the partikkel opcode inside pd using csoundapi? Maybe somebody have used it and theres some example patch ? Im having problems trying to control all parameters from partikkel from pd, maybe somebody did this before and theres and example patch? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [cos~] broken for moderately large inputs
Hi, Seems [cos~] only gives expected results between -1024 and 1024. Above 1024 the frequency halves, halving again at 5120, etc. Below -1024 the frequency doubles, until chaos at -3072. http://claudiusmaximus.goto10.org/g/tech/cos~-test.pd.png http://claudiusmaximus.goto10.org/g/tech/cos~-test-2.pd.png http://claudiusmaximus.goto10.org/g/tech/cos~-test-3.pd.png Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] readPartial
I started jack with the dummy driver. I started pd from a terminal and connected to jack. In the terminal there was a reoccurring message: readPartial. Anyone know what that is about? -- ailo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
