Re: [PD] KMI SoftStep foot controller?
On 09/03/14 02:58, Jonghyun Kim wrote: For OSC connection, you can also [netsend] with tcp, [netsend -u] with udp My experience was [netsend] is a little better than others. Ok ... for me [packOSC] didn't work with [netsend], I didn't investigate why but just used [udpsend] instead. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] KMI SoftStep foot controller?
On Son, 2014-03-09 at 22:52 +1100, Simon Wise wrote: On 09/03/14 02:58, Jonghyun Kim wrote: For OSC connection, you can also [netsend] with tcp, [netsend -u] with udp My experience was [netsend] is a little better than others. Ok ... for me [packOSC] didn't work with [netsend], I didn't investigate why but just used [udpsend] instead. [netsend] is different from [udpsend] and [tcpsend] in that it sends incoming Pd (list/any) messages as FUDI. The latter two expect lists of bytes (list of numbers between 0 and 255). [packOSC] outputs OSC packets represented as lists of bytes and thus is designed to transported by either [udpsend] or [tcpsend], but not [netsend]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] 100k lines of code (was libpd separating gui from core)
Hi Miller, I know you probably have more pressing problems but it would be nice to get something like [getdir] in vanilla before you hit those 100k lines of code OR 50 years are up :) I know you have been bugged in the past but I just wanted to throw it in again in case I could put some influence into you moving such functionality up the to do list... built to last 50 years. It's now about 17 ywars in (1/3 of its intended lifetime.) BTW I find this to be so cool. software minimalism at its finest. for me, there is no reason to go elsewhere... thanks for all the work! m On Wed, Feb 26, 2014 at 6:39 PM, Miller Puckette m...@ucsd.edu wrote: HI all - My figure was 100K lines, not 10K. PD's C code is at about 70K now, and the Tcl/TK code is 7K - so I am only adding expansions very carefully now. Another related idea with an absurdly arbitrary round number attached: the code is built to last 50 years. It's now about 17 ywars in (1/3 of its intended lifetime.) cheers Miller On Wed, Feb 26, 2014 at 06:26:43PM -0500, Ivica Bukvic wrote: What I have been doing is solidifying core features to get a better idea of what the source should look like. Separating anything beforehand will result in s lot of problems/busywork later. I would also not deceive myself that 10K lines is enough. Pd-extended is way above that when you include 3rs party externals. Ditto for pd-l2ork. On Feb 26, 2014 6:10 PM, Peter Brinkmann peter.brinkm...@googlemail.com wrote: On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic i...@vt.edu wrote: The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 1, it becomes unmaintainable and dies. That's why separating the GUI from the audio engine is so important. I sort of agree that 1 lines of irreducible GUI+audio code would probably be unmaintainable. On the other hand, 5000 lines of audio code plus 5000 lines of GUI code, communicating through a smallish, well-defined interface, wouldn't be a problem at all. ___ 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 -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ 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
[PD] udoo board sound issues
hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ 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] udoo board sound issues
H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) 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] udoo board sound issues
hi miller fantastic, thanks On 09 Mar 2014, at 22:07, Miller Puckette m...@ucsd.edu wrote: H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) 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] udoo board sound issues
I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ 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 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] Rewriting a unified phasor / metro object for reading tables
(I believe this might rather belong to pd-list instead of pd-dev) On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: Roman, wrapping points. The only drawback compared to [phasor~] is that the latter allows to control the frequency with a signal and the [metro]/[vline~] based phasor obviously doesn't. I never did quite figure it out but how do you do more advanced things with [vline~] such as updating/increasing ramp speed mid ramp? Frankly, I often find myself struggling with those kinds of problems. I'll be glad to help you build the [phasor~] replacement that has an additional bang outlet, if you need it. Are you saying this is possible with just metro/vline~ combo? I would be curious what that looks like if you did build it It wasn't as easy as I initially expected it to be. I already had a [metro]-like abstraction that can do intra-interval tempo changes. However, I figured it was buggy (it worked only for the first tempo change within an interval) and had to redo it. That was the most difficult part. Combining it with [vline~ ] to make a [vphasor~ ] with extra bangs at each wrapping point wasn't as hard (at least not with its current limitations). Check attachment. Roman vphasor~.tar.gz Description: application/compressed-tar ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] change array graph size
Hello, I wanted to change the graph canvas of an array, but I can't find the way of doing it. If I have an array called array1, to where should I send a coords message? Does it work like a normal GOP? Thanks, jmmmp ___ 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
Re: [PD] change array graph size
On 03/09/2014 08:15 PM, João Pais wrote: Hello, I wanted to change the graph canvas of an array, but I can't find the way of doing it. If I have an array called array1, to where should I send a coords message? Does it work like a normal GOP? The graph is named graph$n, where $n is incremented for each graph that exists in the Pd instance. So you'd send to pd-graph$n in order to do that. In Pd-l2ork you just move the mouse down to the bottom-right corner of the Put menu array, and you get a cursor that lets you click-drag the graph to change its size. -Jonathan Thanks, jmmmp ___ 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
