Re: [PD] Peak Level detect in Vanilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-03-11 01:31, Alexandre Torres Porres wrote: well, I assume they can be more efficient, but my only point here is what I said already and that you agree with - peak level should be available, do you mean that Pd should come with a set of abstractions for standard tasks? because peak-level now *is* available thanks to roman's patch. fgasd,r IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTHskPAAoJELZQGcR/ejb40cIP/1Kxv//ZD8dCEUMyQ9jgFgPx 0d1EklZpO3ZiwijiWwfwnTixTS+7i61Gp5BMRJx9ZXBO9KQ8XrHHg+2FlD4XHYVU bWkgtVxqpoCvYt+oKfb3Jh0CTXNFEErP3y17rls9kxK9VIQk8wCRZRU3EPIFBnPO jcAUZxG55lilxyb7N4JYlGVIBhVLL3YSo1snl8bMcV2SiUVZlvH81gwCJCLWZ1fS V1laBXxxTVzzxACF+GhYTuykGQ879pMS0TBfn9aq3vMbXPuEPm82RZIDR31XGYmy ZpQauXmje8b2skS/wYpwP/nmgwOUgmlKm8fPDBrO4BZ1BJbusFHCJXGu9v2XcuTA VG+6jm8PQMzwsRS+E4p7/juo5/QcoSvosjv4jOpA1+LEVkQd1nrTptI8+ZUAwGj+ oSmfY/Xajrvc/RS+NadInku6KSvbHxwx+jcMT2C7+1twdRNa9KHWESzx/Qpae2Yl qK8hv0TVekhAM8RyDcIGDsbwmypfHyvGQgri/+HRW5Bec6/Ym31bYfXPF+mrOGCH kQiVwbt28hdrwWN3TDtNyBxE5+szXOGyIQXs+/lxabNmXY1UX3LtWUoZcienA74r eFdL9IGRl2vRTtMoY691pJyBDNPSch8R6Eh3AKOIiJxM7C/+t5X6AnWfyLAFZQ89 r3cJRawoBwPQ3uLsvjKh =kaRE -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
On Mon, 2014-03-10 at 21:31 -0300, Alexandre Torres Porres wrote: What is the difference between using an abstraction or a compiled class? well, I assume they can be more efficient, but my only point here is what I said already and that you agree with - peak level should be available, seems like lots of trouble to need to make an abstraction for it. So, basically you are saying it is less trouble to make an external than an abstraction? The fact that neither I nor you made an external indicates otherwise. I know there's an external around, I give you an abstraction and you say you're still looking for the external? Why are abstractions second class citizens in your opinion? but I mean it deserves to be in vanilla. Agreed, but I still have difficulties in understanding why you desperately need it to be a compiled class (I am certainly not against it, though). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
well, lets see if we can get this to a closure So, basically you are saying it is less trouble to make an external than an abstraction? Nope, never said it. Not sure why you took it that way. Maybe because I mentioned efficiency. But that was supposed to mean computer efficiency, and as a response to what I thought was a general question about compiled classes vs abstractions. Not that the discussion was really about that, and, more importantly, not that is was my point at all, as I clearly stated and then shifted to my point after that... I didn't even feel like moving the discussion that way, that's why I tried not to do it and stick to my point, by the way. I give you an abstraction and you say you're still looking for the external? No no no. I'm not looking for no external. I already know about the external, and I even mentioned about it in my sencond message on this thread, when I said I was hoping there'd be a [peakenv~] like object in Vanilla. And then I pointed it could come as a feature in a probable update of [env~]. I've been using [peakenv~] and mostly [prvu~], I think they're great. Agreed, but I still have difficulties in understanding why you desperately need it to be a compiled class (I am certainly not against it, though). I wouldn't say I'm desperate... so you don't need to keep having trouble trying to figure me out. Also, I never even said I need this to be a compiled class, cause I actually do not. I'm happy to share my point yet again, but please don't misinterpret/misjudge my words. Once more, my only point is that I *think* this is an important feature that *should* come in vanilla objects, it deserves to! Maybe as an extension to [env~], like in a second outlet... that wouldn't hurt... and wouldn't even require a new object. Anyway, that's all there's to it. Nothing more... I think I'm being very clear and straightforward. Not anyone here thought this was a bad idea too (so it seems), now I'm wondering what is all the commotion about... or does anyone think this is actually a bad idea? I mean, I seriously wonder what's the deal. Pd Vanilla comes with a very limited set of objects, we all know that. I can get by with that with no problem. I'm just pointing how one little thingy could come into the set, and suddenly things get off track to turn into such a debate. I don't know, I suspect there can be something to it... :) Why are abstractions second class citizens in your opinion? Maybe if I had ever stated that, I could answer you to that question. What you could ask me without putting words in my mouth is: why do I think Peak Level detection should come as a function in a compiled class in Pd Vanilla, when you can do it as an abstraction or when there's a couple of objects in Pd-Extended that'll do it for you. Well, I think it is such a basic feature that deserves to be out of the box from Pd Vanilla in an object like [env~], and I guess I'm repeating myself... Thing is I have very little knowledge in C and compiling objects, so doing abstractions is All I do... I think it's great people like me can get by with them... but you know, eventually some stuff will get you thinking hmm, this could have already been made available out of Vanilla objects... Moreover, I mentioned [vu] (a vanilla GUI) in my first message and how it receives peak level, but no vanilla object does that job. That looks like something missing or incomplete in Vanilla. I really hope to see [env~] handling that issue soon. That'll make my day and think the world is a better place. Cheers 2014-03-11 6:40 GMT-03:00 Roman Haefeli reduz...@gmail.com: On Mon, 2014-03-10 at 21:31 -0300, Alexandre Torres Porres wrote: What is the difference between using an abstraction or a compiled class? well, I assume they can be more efficient, but my only point here is what I said already and that you agree with - peak level should be available, seems like lots of trouble to need to make an abstraction for it. So, basically you are saying it is less trouble to make an external than an abstraction? The fact that neither I nor you made an external indicates otherwise. I know there's an external around, I give you an abstraction and you say you're still looking for the external? Why are abstractions second class citizens in your opinion? but I mean it deserves to be in vanilla. Agreed, but I still have difficulties in understanding why you desperately need it to be a compiled class (I am certainly not against it, though). Roman ___ 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] Peak Level detect in Vanilla
On Sun, 2014-03-09 at 22:32 -0300, Alexandre Torres Porres wrote: Why not an abstraction in my point of view? Well, looks kinda cumbersome for that particular goal. I am with you in that I think it makes sense to extend [env~]. Regarding abstractions, I don't see what is cumbersome. What is the difference between using an abstraction or a compiled class? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
What is the difference between using an abstraction or a compiled class? well, I assume they can be more efficient, but my only point here is what I said already and that you agree with - peak level should be available, seems like lots of trouble to need to make an abstraction for it. I know there's an external around, but I mean it deserves to be in vanilla. cheers 2014-03-10 4:32 GMT-03:00 Roman Haefeli reduz...@gmail.com: On Sun, 2014-03-09 at 22:32 -0300, Alexandre Torres Porres wrote: Why not an abstraction in my point of view? Well, looks kinda cumbersome for that particular goal. I am with you in that I think it makes sense to extend [env~]. Regarding abstractions, I don't see what is cumbersome. What is the difference between using an abstraction or a compiled class? Roman ___ 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] Peak Level detect in Vanilla
As far as Vanilla goes it does seem like a great solution. Thanks a lot for that, seems to do the trick! But was really hoping for or even asking for a [peakenv~] like object. I didn't find anything and I thought I wouldn't be missing it if there was, but came here to ask anyway. Maybe an update to the [env~] object where it could have a second outlet for peaks. How feasible is that Miller? Seems there's a bit of a whole here where we can't easily send the peak values to [vu]. I think it'd be nice to have a way. Cheers 2014-03-08 21:11 GMT-03:00 peiman khosravi peimankhosr...@gmail.com: This may not be the best solution but I did this by reading the DSP block into an array, on every block, and calculating the absolute peak value stored in the array on each iteration. I've attached the abstract. P *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed http://peimankhosravi.co.uk/miscposts.rss || Concert News http://spectralkimia.wordpress.com/* On 8 March 2014 23:43, Alexandre Torres Porres por...@gmail.com wrote: Hi there, since [vu] accepts a value for Peak Amplitude, is there a way to measure it with Vanilla objects? Cheers ___ 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] Peak Level detect in Vanilla
Hi all - I've been wanting to add this as an option to env~. Unfortunately the last time I thought carefully about it I ended up geting stuck in design decisions I don't know how to make. But I'll get back to it someday! cheers Miller On Sun, Mar 09, 2014 at 12:23:15PM -0300, Alexandre Torres Porres wrote: As far as Vanilla goes it does seem like a great solution. Thanks a lot for that, seems to do the trick! But was really hoping for or even asking for a [peakenv~] like object. I didn't find anything and I thought I wouldn't be missing it if there was, but came here to ask anyway. Maybe an update to the [env~] object where it could have a second outlet for peaks. How feasible is that Miller? Seems there's a bit of a whole here where we can't easily send the peak values to [vu]. I think it'd be nice to have a way. Cheers 2014-03-08 21:11 GMT-03:00 peiman khosravi peimankhosr...@gmail.com: This may not be the best solution but I did this by reading the DSP block into an array, on every block, and calculating the absolute peak value stored in the array on each iteration. I've attached the abstract. P *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed http://peimankhosravi.co.uk/miscposts.rss || Concert News http://spectralkimia.wordpress.com/* On 8 March 2014 23:43, Alexandre Torres Porres por...@gmail.com wrote: Hi there, since [vu] accepts a value for Peak Amplitude, is there a way to measure it with Vanilla objects? Cheers ___ 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] Peak Level detect in Vanilla
On Son, 2014-03-09 at 12:23 -0300, Alexandre Torres Porres wrote: As far as Vanilla goes it does seem like a great solution. Thanks a lot for that, seems to do the trick! But was really hoping for or even asking for a [peakenv~] like object. Why does it have to be an extra class and why not an abstraction? I consider abstractions more accessible as you can adapt them on the fly. Personally, I'd prefer abstractions (where the performance penalty isn't too huge). Yo, I attached an abstraction that extracts both, rms and peak level from the incoming signal. The peak output tries to emulate the behavior of VU meters of analogue mixing desks that have some kind of a fall back delay. Roman #N canvas 486 155 295 293 10; #X obj 17 12 inlet~; #N canvas 1064 100 194 249 peak_of_32 0; #X obj 14 70 f; #X obj 63 78 + 1; #X obj 14 44 t b a; #X obj 14 114 sel 0; #X obj 71 122 moses; #X obj 121 124 t a; #X obj 14 150 t b b; #X msg 118 146 0; #X obj 14 175 f; #X obj 14 197 outlet; #X obj 14 16 inlet; #X obj 14 92 mod 32; #X connect 0 0 11 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 2 1 4 0; #X connect 3 0 6 0; #X connect 4 1 5 0; #X connect 4 1 8 1; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 6 1 7 0; #X connect 7 0 4 1; #X connect 8 0 9 0; #X connect 10 0 2 0; #X connect 11 0 1 0; #X connect 11 0 3 0; #X restore 93 77 pd peak_of_32; #X obj 93 120 rmstodb; #N canvas 1064 380 198 399 inertia 0; #X msg 96 111 0; #X obj 15 140 f; #X obj 55 141 + 1; #X obj 69 85 t a b; #X obj 15 248 f; #X obj 49 249 * 0.5; #X obj 15 12 inlet; #X obj 15 313 outlet; #X obj 15 37 t b a; #X obj 42 61 moses; #X obj 15 270 t a a; #X obj 139 196 t a; #X obj 15 175 t b a; #N canvas 590 409 162 222 magic 0; #X obj 26 17 inlet; #X obj 26 179 outlet; #X msg 26 112 1 \$1; #X obj 26 134 -; #X obj 26 158 max 0.9; #X obj 26 62 max 0; #X obj 26 41 - 15; #X obj 26 88 * 0.002; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 7 0; #X connect 6 0 5 0; #X connect 7 0 2 0; #X restore 54 205 pd magic; #X connect 0 0 1 1; #X connect 1 0 2 0; #X connect 1 0 12 0; #X connect 2 0 1 1; #X connect 3 0 4 1; #X connect 3 1 0 0; #X connect 4 0 5 0; #X connect 4 0 10 0; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 8 0 1 0; #X connect 8 1 9 0; #X connect 9 1 3 0; #X connect 10 0 7 0; #X connect 10 1 11 0; #X connect 11 0 9 1; #X connect 12 0 4 0; #X connect 12 1 13 0; #X connect 13 0 5 1; #X restore 93 98 pd inertia; #N canvas 603 218 325 344 peak_per_block 0; #X obj 204 15 table \$0.peak 64; #X obj 17 32 tabsend~ \$0.peak; #X obj 17 63 bang~; #X msg 49 139 64; #X obj 49 117 t b b; #X msg 89 148 0; #X obj 49 161 until; #X obj 49 184 f; #X obj 106 185 + 1; #X obj 49 206 tabread \$0.peak; #X obj 49 257 moses; #X obj 107 258 t a; #X obj 17 292 f; #X obj 49 231 abs; #X obj 17 87 t b b; #X obj 17 313 outlet; #X obj 17 10 inlet~; #X connect 2 0 14 0; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 4 1 5 0; #X connect 5 0 7 1; #X connect 5 0 10 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 0 9 0; #X connect 8 0 7 1; #X connect 9 0 13 0; #X connect 10 1 11 0; #X connect 10 1 12 1; #X connect 11 0 10 1; #X connect 12 0 15 0; #X connect 13 0 10 0; #X connect 14 0 12 0; #X connect 14 1 4 0; #X connect 16 0 1 0; #X restore 93 56 pd peak_per_block; #X obj 16 244 outlet; #X obj 16 84 - 100; #X obj 16 62 env~ 4096; #X obj 16 106 t b a; #X obj 93 142 - 100; #X obj 16 181 pack f f; #X obj 16 152 f; #X obj 16 128 del 0; #N canvas 690 175 211 142 NETPD 0; #X msg 9 15 version 0 1 0; #X restore 161 16 pd NETPD 2 0; #N canvas 154 288 158 285 overdrive 0; #X obj 15 43 1; #X obj 15 65 sel 1; #X msg 43 109 0; #X msg 15 100 1; #X obj 15 132 change; #X obj 15 154 sel 1 0; #X msg 75 176 64 64 64; #X msg 15 228 color \$1 -1; #X obj 15 202 netpd-rgb2iem; #X msg 15 176 200 0 0; #X obj 43 89 del 300; #X obj 15 16 inlet; #X obj 15 250 outlet; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 0 10 0; #X connect 2 0 4 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 9 0; #X connect 5 1 6 0; #X connect 6 0 8 0; #X connect 7 0 12 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 2 0; #X connect 11 0 0 0; #X restore 171 163 pd overdrive; #X connect 0 0 4 0; #X connect 0 0 7 0; #X connect 1 0 3 0; #X connect 1 0 14 0; #X connect 2 0 9 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 6 0 8 0; #X connect 7 0 6 0; #X connect 8 0 12 0; #X connect 8 1 11 1; #X connect 9 0 10 1; #X connect 10 0 5 0; #X connect 11 0 10 0; #X connect 12 0 11 0; #X connect 14 0 5 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
By the way - I just looked, and you can save a great deal of trouble using the array max object (new in Pd 0.25) - no need for 'until' horror. (just put the abs~ of the signal into the table). But env~ seems incomplete to me if it's only going to compute RMS. cheers M On Sun, Mar 09, 2014 at 09:36:31PM +0100, Roman Haefeli wrote: On Son, 2014-03-09 at 12:23 -0300, Alexandre Torres Porres wrote: As far as Vanilla goes it does seem like a great solution. Thanks a lot for that, seems to do the trick! But was really hoping for or even asking for a [peakenv~] like object. Why does it have to be an extra class and why not an abstraction? I consider abstractions more accessible as you can adapt them on the fly. Personally, I'd prefer abstractions (where the performance penalty isn't too huge). Yo, I attached an abstraction that extracts both, rms and peak level from the incoming signal. The peak output tries to emulate the behavior of VU meters of analogue mixing desks that have some kind of a fall back delay. Roman #N canvas 486 155 295 293 10; #X obj 17 12 inlet~; #N canvas 1064 100 194 249 peak_of_32 0; #X obj 14 70 f; #X obj 63 78 + 1; #X obj 14 44 t b a; #X obj 14 114 sel 0; #X obj 71 122 moses; #X obj 121 124 t a; #X obj 14 150 t b b; #X msg 118 146 0; #X obj 14 175 f; #X obj 14 197 outlet; #X obj 14 16 inlet; #X obj 14 92 mod 32; #X connect 0 0 11 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 2 1 4 0; #X connect 3 0 6 0; #X connect 4 1 5 0; #X connect 4 1 8 1; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 6 1 7 0; #X connect 7 0 4 1; #X connect 8 0 9 0; #X connect 10 0 2 0; #X connect 11 0 1 0; #X connect 11 0 3 0; #X restore 93 77 pd peak_of_32; #X obj 93 120 rmstodb; #N canvas 1064 380 198 399 inertia 0; #X msg 96 111 0; #X obj 15 140 f; #X obj 55 141 + 1; #X obj 69 85 t a b; #X obj 15 248 f; #X obj 49 249 * 0.5; #X obj 15 12 inlet; #X obj 15 313 outlet; #X obj 15 37 t b a; #X obj 42 61 moses; #X obj 15 270 t a a; #X obj 139 196 t a; #X obj 15 175 t b a; #N canvas 590 409 162 222 magic 0; #X obj 26 17 inlet; #X obj 26 179 outlet; #X msg 26 112 1 \$1; #X obj 26 134 -; #X obj 26 158 max 0.9; #X obj 26 62 max 0; #X obj 26 41 - 15; #X obj 26 88 * 0.002; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 7 0; #X connect 6 0 5 0; #X connect 7 0 2 0; #X restore 54 205 pd magic; #X connect 0 0 1 1; #X connect 1 0 2 0; #X connect 1 0 12 0; #X connect 2 0 1 1; #X connect 3 0 4 1; #X connect 3 1 0 0; #X connect 4 0 5 0; #X connect 4 0 10 0; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 8 0 1 0; #X connect 8 1 9 0; #X connect 9 1 3 0; #X connect 10 0 7 0; #X connect 10 1 11 0; #X connect 11 0 9 1; #X connect 12 0 4 0; #X connect 12 1 13 0; #X connect 13 0 5 1; #X restore 93 98 pd inertia; #N canvas 603 218 325 344 peak_per_block 0; #X obj 204 15 table \$0.peak 64; #X obj 17 32 tabsend~ \$0.peak; #X obj 17 63 bang~; #X msg 49 139 64; #X obj 49 117 t b b; #X msg 89 148 0; #X obj 49 161 until; #X obj 49 184 f; #X obj 106 185 + 1; #X obj 49 206 tabread \$0.peak; #X obj 49 257 moses; #X obj 107 258 t a; #X obj 17 292 f; #X obj 49 231 abs; #X obj 17 87 t b b; #X obj 17 313 outlet; #X obj 17 10 inlet~; #X connect 2 0 14 0; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 4 1 5 0; #X connect 5 0 7 1; #X connect 5 0 10 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 0 9 0; #X connect 8 0 7 1; #X connect 9 0 13 0; #X connect 10 1 11 0; #X connect 10 1 12 1; #X connect 11 0 10 1; #X connect 12 0 15 0; #X connect 13 0 10 0; #X connect 14 0 12 0; #X connect 14 1 4 0; #X connect 16 0 1 0; #X restore 93 56 pd peak_per_block; #X obj 16 244 outlet; #X obj 16 84 - 100; #X obj 16 62 env~ 4096; #X obj 16 106 t b a; #X obj 93 142 - 100; #X obj 16 181 pack f f; #X obj 16 152 f; #X obj 16 128 del 0; #N canvas 690 175 211 142 NETPD 0; #X msg 9 15 version 0 1 0; #X restore 161 16 pd NETPD 2 0; #N canvas 154 288 158 285 overdrive 0; #X obj 15 43 1; #X obj 15 65 sel 1; #X msg 43 109 0; #X msg 15 100 1; #X obj 15 132 change; #X obj 15 154 sel 1 0; #X msg 75 176 64 64 64; #X msg 15 228 color \$1 -1; #X obj 15 202 netpd-rgb2iem; #X msg 15 176 200 0 0; #X obj 43 89 del 300; #X obj 15 16 inlet; #X obj 15 250 outlet; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 0 10 0; #X connect 2 0 4 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 9 0; #X connect 5 1 6 0; #X connect 6 0 8 0; #X connect 7 0 12 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 2 0; #X connect 11 0 0 0; #X restore 171 163 pd overdrive; #X connect 0 0 4 0; #X connect 0 0 7 0; #X connect 1 0 3 0; #X connect 1 0 14 0; #X connect 2 0 9 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 6 0 8 0; #X connect 7 0 6 0; #X connect 8 0 12 0; #X connect 8 1 11 1; #X connect 9 0 10
Re: [PD] Peak Level detect in Vanilla
On Son, 2014-03-09 at 14:05 -0700, Miller Puckette wrote: By the way - I just looked, and you can save a great deal of trouble using the array max object (new in Pd 0.25) You mean 0.45, I guess(?) - no need for 'until' horror. Oh, that is great! Thanks for the reminder, I haven't looked at [array] yet. But env~ seems incomplete to me if it's only going to compute RMS. Yeah, I see your and Alexandre's point: Why not extending [env~]? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
env~ seems incomplete to me if it's only going to compute RMS. Glad you feel how I do :) But wondering where you'd be stuck at, seems like something not too complicated. Anyway, waiting for it someday ;) Why not an abstraction in my point of view? Well, looks kinda cumbersome for that particular goal. Cheers 2014-03-09 18:30 GMT-03:00 Roman Haefeli reduz...@gmail.com: On Son, 2014-03-09 at 14:05 -0700, Miller Puckette wrote: By the way - I just looked, and you can save a great deal of trouble using the array max object (new in Pd 0.25) You mean 0.45, I guess(?) - no need for 'until' horror. Oh, that is great! Thanks for the reminder, I haven't looked at [array] yet. But env~ seems incomplete to me if it's only going to compute RMS. Yeah, I see your and Alexandre's point: Why not extending [env~]? Roman ___ 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] Peak Level detect in Vanilla
On Sun, Mar 9, 2014 at 5:05 PM, Miller Puckette m...@ucsd.edu wrote: But env~ seems incomplete to me if it's only going to compute RMS. Can we get the values in dBFS, please? Chris ___ 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] Peak Level detect in Vanilla
hmm, that's an idea for another built-in option, so it's completely compatible to [vu] right out of the box :) 2014-03-09 23:35 GMT-03:00 Chris Clepper cgclep...@gmail.com: On Sun, Mar 9, 2014 at 5:05 PM, Miller Puckette m...@ucsd.edu wrote: But env~ seems incomplete to me if it's only going to compute RMS. Can we get the values in dBFS, please? Chris ___ 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
