from:"simon"

Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass 
Filtering? I tried to upsample with a Block object but the biquad object 
stopped outputting Pulses. If you don't mind doing a Version with upsampling 
that would be fantastic.

Well i just copied from the Gr300 schematic, so no credits for me :)

Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com:

 Hi Simon,
 
 So your method counts samples per (zero-crossing) cycle, is what I
 learned from studying the patch. Very nice how you do this with tilde
 objects. It seems possible to get equivalent result with only one
 [rpole~], when using the positive pulse as trigger for [samphold~] and
 with two samples delay for [rpole~]. You get the integrator's maximum
 everytime. See attached patch.
 
 Of course it still counts integer number of samples. Upsampling would
 indeed improve accuracy. An upsampled signal needs filtering to remove
 spectral images, did you try that?
 
 Katja
 
 On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote:
 nice changes with expr~ ! but i think you missed the point of the beginning
 of the patch. read in my first e-mail for an explanation of what this patch
 does exactly. it is an gr300 analog guitar synthesizer clone (well one voice
 of it). it is intended for real-life signals so there needs to be an
 adaptive filter in the beginning (with the pitch info we get from the two
 rpole~
 objects) and the signal needs to be squared to get the longest possible
 sustain (envelope is re added later obviously). also i think response is
 faster when squared, or not?
 
 thanks for the changes, greatly appreciated!
 
 simon
 
 Well i know exactly what the Patch does... I just dont know why the two
 numbers before the Addition Need to be -1 And -2 :-)
 
 Will Look at your Version asap.
 
 Cheers
 
 Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com:
 
 I have no idea what the patch is doing either, but I was able to clean it a
 lot.
 
 many things that didn't need to be there
 
 cheers
 
 
 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com:
 
 roman, thanks for your inputs.
 
 i tried both fexpr and expr and sticked to fexpr at some point, don’t know
 why though. will change it back!  (i remember reading that fexpr was more
 expensive but also more precise)
 
 to make the whole thing work with real world signals (bass guitar in my
 case) you have to add an adaptive filter in the beginning of the chain
 (which is very easy because you get the frequency information hehe…) this
 will filter out overtones and prevent octave jumping.
 
 thanks
 
 simon
 
 On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote:
 
 That works very well. Good job and thanks for sharing!
 
 One minor thing jumped to my eye: Your patch uses some instances of
 [fexpr~] and all of them actually don't need [fexpr~] functionality. I
 experienced that [fexpr~] is quite expensive, which seems apparent
 considering it is designed for feedback algorithms. I don't know if
 [fexpr~] is also expensive when you use it not for feedbacks as your
 patch does. Anyway, you could replace them by likely less expensive
 [expr~] instances:
 
 [fexpr~ $x1=0] - [expr~ $v1=0]
 
 Roman
 
 
 
 On Mon, 2014-04-28 at 00:59 +0200, simon wrote:
 hey miller and list,
 
 
 find attached a version that works beautifully. it's a dirty hack
 without upsampling but it works extremly well. don't ask me why, i have no
 idea.
 
 thanks for all the help miller, really appreciate it! and thanks for pd
 in general :-)
 
 cheers,
 
 simon
 
 On Apr 27, 2014, at 8:59 PM, Simon Iten wrote:
 
 sorry this one went off-list :-)
 
 
 On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote:
 
 sure,
 
 here is the version with biquad in a subpatch with a block opject to
 upsample. probably i'm doing something wrong, i just copied from the 
 block
 help-patch.
 
 sinetosawtoothupsample.pd
 
 On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote:
 
 Drat, I don't have any explanation for this...  can you send me the
 patch
 again?
 cheers
 M
 
 On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote:
 hmm, changing change to biquad does also not work. i mean it does
 as long as i don't upsample in the subpatch. as soon as i change the 
 block
 object i get square instead of pulses...
 
 On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote:
 
 Actually I don't know where the change~ object is from - I've nver
 seen t
 before.  I would just use biquad~ 0 0 1 -1 0 (assuming that
 change~ simply
 ubtracts the previous sample from teh current one as I guessed
 from the patch :)
 
 M
 
 On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote:
 ok tried to upsample the whole thing (after the osc~) and now
 change~ does nothing anymore… it just spits out the same square 
 wave i feed
 in…clues?
 
 
 On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote:
 
 crosspost! sorry about the noise. thanks for the inputs i will
 try

Re: [PD] ALSA broken pipe on pd-extended on Beaglebone?

Alsa is only supposed to work with One application at a Time.

Am 29.04.2014 um 17:15 schrieb David Welch nicederangem...@gmail.com:

 Hi all, 
 I am currently working on an embedded device made up of some hardware, 
 Arduino, Beaglebone running Debian white with audio cape. I am attaching a pd 
 file that works on a laptop. For the beaglebone, basically I change the 
 serial port argument to 4 for [comport] but get a Broken Pipe error
 
 ALSA input error (restart failed): Broken pipe
 restarting input device from state 2
 ALSA output error (restart failed): Broken pipe
 
 
 But ALSA seems to be working okay as long as only 1  application tries to use 
 it. I followed most of the directions here to get it working 
 (http://www.csounds.com/journal/issue18/beagle_pi.html and 
 http://puredata.info/docs/embedded/bbb/) I installed pd-extended by adding 
 the repository to /etc/apt/sources.list with directions from here 
 (http://puredata.info/docs/faq/debian). I know sound is okay: speaker-test 
 works ok. pd-extended works including sound, at least for a simple patch 
 (also attached).  Jack is not installed (doesn't seem necessary for single 
 headless instance of pd-extended). 
 
 Hmm...any help would be greatly appreciated! 
 
 David Welch
 musicalquilt_28Apr14.pd
 simple_PD_test.pd
 ___
 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] SOLVED!!! Re: pitch to voltage SOLVED!!!

katja,

exactly! i filter the input based on the output of the pitch detection. i used 
this for quite some time with my doublebass (but with a pickup per string) and 
it works perfectly. i get no octave jumps or glitches at all. the version i 
shared here is planned to be used for vocals, i have to see if it works as good…

the trick is not to filter too much in order to “let through” new notes but 
enough to filter out strong overtones (mainly octaves). it also helps to have 
filters in parallel. and of course you cut the range before that in order to 
fit your input. 
on a bass string this is very easy since on a double-bass you have a 3 octave 
range per string you can cut many frequencies before even starting filtering.

this is how i did it and it worked.

i adapted this system from the gr300 also. there it’s even easier. just two 
filters per string. one in the lower section (0-7th fret and one from 7-22 
fret) they get switched via transistors based on the output voltage of the p/v 
circuit. they are 2nd order bandpass filters.

cheers, simon



On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote:

 Hi Simon,
 
 See attachment for an upsampled version. I used a 6th order lo pass
 filter with cut off at 1/4 of the original sampling rate. This seems
 to work with max. 8 times upsampling. Period length error is then
 limited to 1/8 sample.
 
 You mentioned adaptive filtering of a real life input signal. Are you
 planning to control filter cut off frequency with the pitch detection
 result? Did you already try that? I wonder how that could work at all,
 because the pitch result comes only after the adaptive filter.
 
 Katja
 
 On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote:
 Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass 
 Filtering? I tried to upsample with a Block object but the biquad object 
 stopped outputting Pulses. If you don't mind doing a Version with upsampling 
 that would be fantastic.
 
 Well i just copied from the Gr300 schematic, so no credits for me :)
 
 Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com:
 
 Hi Simon,
 
 So your method counts samples per (zero-crossing) cycle, is what I
 learned from studying the patch. Very nice how you do this with tilde
 objects. It seems possible to get equivalent result with only one
 [rpole~], when using the positive pulse as trigger for [samphold~] and
 with two samples delay for [rpole~]. You get the integrator's maximum
 everytime. See attached patch.
 
 Of course it still counts integer number of samples. Upsampling would
 indeed improve accuracy. An upsampled signal needs filtering to remove
 spectral images, did you try that?
 
 Katja
 
 On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote:
 nice changes with expr~ ! but i think you missed the point of the beginning
 of the patch. read in my first e-mail for an explanation of what this patch
 does exactly. it is an gr300 analog guitar synthesizer clone (well one 
 voice
 of it). it is intended for real-life signals so there needs to be an
 adaptive filter in the beginning (with the pitch info we get from the two
 rpole~
 objects) and the signal needs to be squared to get the longest possible
 sustain (envelope is re added later obviously). also i think response is
 faster when squared, or not?
 
 thanks for the changes, greatly appreciated!
 
 simon
 
 Well i know exactly what the Patch does... I just dont know why the two
 numbers before the Addition Need to be -1 And -2 :-)
 
 Will Look at your Version asap.
 
 Cheers
 
 Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com:
 
 I have no idea what the patch is doing either, but I was able to clean it a
 lot.
 
 many things that didn't need to be there
 
 cheers
 
 
 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com:
 
 roman, thanks for your inputs.
 
 i tried both fexpr and expr and sticked to fexpr at some point, don’t know
 why though. will change it back!  (i remember reading that fexpr was more
 expensive but also more precise)
 
 to make the whole thing work with real world signals (bass guitar in my
 case) you have to add an adaptive filter in the beginning of the chain
 (which is very easy because you get the frequency information hehe…) this
 will filter out overtones and prevent octave jumping.
 
 thanks
 
 simon
 
 On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote:
 
 That works very well. Good job and thanks for sharing!
 
 One minor thing jumped to my eye: Your patch uses some instances of
 [fexpr~] and all of them actually don't need [fexpr~] functionality. I
 experienced that [fexpr~] is quite expensive, which seems apparent
 considering it is designed for feedback algorithms. I don't know if
 [fexpr~] is also expensive when you use it not for feedbacks as your
 patch does. Anyway, you could replace them by likely less expensive
 [expr~] instances:
 
 [fexpr~ $x1=0] - [expr~ $v1=0]
 
 Roman

Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!

hi katja,

i tried your patch and had a look at it. it’s beautifully programmed :-) so 
skilled.
thanks for taking the time and it’s very interesting to see a different style 
and different thinking to get to the “same” outcome.

i tried (with a different version of the patch) just to replace osc~ with adc~ 
and sang into my macbook microphone. there is no octave jumping exept for the 
very low notes i can sing :-)
attached is a simple version with a little filtering. it’s not tested at all 
but this is how i did it for bass. (with other values for hip and lop of course)

note that there is a lot of noise when you don’t sing or sing to quietly, this 
is because you amplify the shit out of the signal. so to use this you will need 
to add envelope following and a gate.

when i tried this simple solution with your upsampled patch i got nothing :-) 
the signal just freezes at some high value. but i’m probably missing something 
very basic.

cheers,

simon


On 29 Apr 2014, at 21:10, katja katjavet...@gmail.com wrote:

 Hi Simon,
 
 I'd be curious to see this adaptive filtering work in practice. Could
 you share a patch, once you have that working? Vocals mostly don't
 exceed a 3 octave range either. Only thing is, in vocals the strongest
 component is sometimes not the first harmonic but the second, when
 speaking or singing the lowest notes in the range.
 
 Katja
 
 On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote:
 katja,
 
 exactly! i filter the input based on the output of the pitch detection. i 
 used this for quite some time with my doublebass (but with a pickup per 
 string) and it works perfectly. i get no octave jumps or glitches at all. 
 the version i shared here is planned to be used for vocals, i have to see if 
 it works as good…
 
 the trick is not to filter too much in order to “let through” new notes but 
 enough to filter out strong overtones (mainly octaves). it also helps to 
 have filters in parallel. and of course you cut the range before that in 
 order to fit your input.
 on a bass string this is very easy since on a double-bass you have a 3 
 octave range per string you can cut many frequencies before even starting 
 filtering.
 
 this is how i did it and it worked.
 
 i adapted this system from the gr300 also. there it’s even easier. just two 
 filters per string. one in the lower section (0-7th fret and one from 7-22 
 fret) they get switched via transistors based on the output voltage of the 
 p/v circuit. they are 2nd order bandpass filters.
 
 cheers, simon
 
 
 
 On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote:
 
 Hi Simon,
 
 See attachment for an upsampled version. I used a 6th order lo pass
 filter with cut off at 1/4 of the original sampling rate. This seems
 to work with max. 8 times upsampling. Period length error is then
 limited to 1/8 sample.
 
 You mentioned adaptive filtering of a real life input signal. Are you
 planning to control filter cut off frequency with the pitch detection
 result? Did you already try that? I wonder how that could work at all,
 because the pitch result comes only after the adaptive filter.
 
 Katja
 
 On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote:
 Katja thanks for your Inputs! Will Look at the Patch tonight. Simple 
 lowpass Filtering? I tried to upsample with a Block object but the biquad 
 object stopped outputting Pulses. If you don't mind doing a Version with 
 upsampling that would be fantastic.
 
 Well i just copied from the Gr300 schematic, so no credits for me :)
 
 Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com:
 
 Hi Simon,
 
 So your method counts samples per (zero-crossing) cycle, is what I
 learned from studying the patch. Very nice how you do this with tilde
 objects. It seems possible to get equivalent result with only one
 [rpole~], when using the positive pulse as trigger for [samphold~] and
 with two samples delay for [rpole~]. You get the integrator's maximum
 everytime. See attached patch.
 
 Of course it still counts integer number of samples. Upsampling would
 indeed improve accuracy. An upsampled signal needs filtering to remove
 spectral images, did you try that?
 
 Katja
 
 On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote:
 nice changes with expr~ ! but i think you missed the point of the 
 beginning
 of the patch. read in my first e-mail for an explanation of what this 
 patch
 does exactly. it is an gr300 analog guitar synthesizer clone (well one 
 voice
 of it). it is intended for real-life signals so there needs to be an
 adaptive filter in the beginning (with the pitch info we get from the two
 rpole~
 objects) and the signal needs to be squared to get the longest possible
 sustain (envelope is re added later obviously). also i think response is
 faster when squared, or not?
 
 thanks for the changes, greatly appreciated!
 
 simon
 
 Well i know exactly what the Patch does... I just dont know why the two
 numbers before

Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!

2014-04-28 Thread Simon Iten

roman, thanks for your inputs.

i tried both fexpr and expr and sticked to fexpr at some point, don’t know why 
though. will change it back!  (i remember reading that fexpr was more expensive 
but also more precise)

to make the whole thing work with real world signals (bass guitar in my case) 
you have to add an adaptive filter in the beginning of the chain (which is very 
easy because you get the frequency information hehe…) this will filter out 
overtones and prevent octave jumping.

thanks

simon

On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote:

 That works very well. Good job and thanks for sharing!
 
 One minor thing jumped to my eye: Your patch uses some instances of
 [fexpr~] and all of them actually don't need [fexpr~] functionality. I
 experienced that [fexpr~] is quite expensive, which seems apparent
 considering it is designed for feedback algorithms. I don't know if
 [fexpr~] is also expensive when you use it not for feedbacks as your
 patch does. Anyway, you could replace them by likely less expensive
 [expr~] instances:
 
 [fexpr~ $x1=0] - [expr~ $v1=0]
 
 Roman
 
 
 
 On Mon, 2014-04-28 at 00:59 +0200, simon wrote:
 hey miller and list,
 
 
 find attached a version that works beautifully. it's a dirty hack without 
 upsampling but it works extremly well. don't ask me why, i have no idea.
 
 thanks for all the help miller, really appreciate it! and thanks for pd in 
 general :-)
 
 cheers,
 
 simon
 
 On Apr 27, 2014, at 8:59 PM, Simon Iten wrote:
 
 sorry this one went off-list :-)
 
 
 On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote:
 
 sure,
 
 here is the version with biquad in a subpatch with a block opject to 
 upsample. probably i'm doing something wrong, i just copied from the block 
 help-patch.
 
 sinetosawtoothupsample.pd
 
 On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote:
 
 Drat, I don't have any explanation for this...  can you send me the patch
 again?
 cheers
 M
 
 On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote:
 hmm, changing change to biquad does also not work. i mean it does as 
 long as i don't upsample in the subpatch. as soon as i change the block 
 object i get square instead of pulses...
 
 On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote:
 
 Actually I don't know where the change~ object is from - I've nver seen 
 t
 before.  I would just use biquad~ 0 0 1 -1 0 (assuming that change~ 
 simply
 ubtracts the previous sample from teh current one as I guessed from the 
 patch :)
 
 M
 
 On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote:
 ok tried to upsample the whole thing (after the osc~) and now change~ 
 does nothing anymore… it just spits out the same square wave i feed 
 in…clues?
 
 
 On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote:
 
 crosspost! sorry about the noise. thanks for the inputs i will try to 
 to this. not sure if i can. otherwise i will ask back if that’s ok!
 On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote:
 
 so if i would measure at the peak of the sawtooth and would upsample 
 inside the pd patch, i would get higher resolution, right?
 
 any ideas how i can measure at the peak? (using the rpole output on 
 both samphold inputs does not work and delaying one of them is also 
 not working)
 
 which 
 
 i would highly recommend you try this method with your gk-3 equipped 
 guitar (one for each string) since you only have to cover a two 
 octave range per string the error is tolerable. (you can add an 
 offset to make it fit)
 On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:
 
 That is an excellent, witty way to measure pulse withs using
 only tilde obects - my hat's off to you.
 
 The methond only has limited accuracy since its measurement is in
 samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz 
 is
 only 50 samples, so there's only 2% accuracy.  That's about 1/3 of a
 half tone (30-ish cents) which would sound horribly out of tune.
 
 There's an alternative sine-to-sawtooth recipe described here:
 
 http://msp.ucsd.edu/Publications/icmc10.pdf
 
 This is the basis of my guitar processing patch, smeck, but should 
 be more
 broadly useful.  But it has its own limitations: the sawtooth you 
 get out
 is wiggly if the input sn't a pure sinusoid.
 
 There's also the possibility of simply pitch tracking with 
 sigmund~.  Use
 a maximum frequency around 6000 and a maximum of 6 partals (default 
 50!)
 for best results.
 
 cheers
 M
 
 On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
 dear list,
 
 i have a strange problem with my “sinetosawtooth” patch.
 
 it is basically a version of the pitch to voltage conversion used 
 in the old gr300 guitar synths from roland.
 
 i cut out all the clutter to make it easier to look at and 
 understand. (cut out the adaptive filtering at the input since i 
 use a sine wave for this example and not a guitar string)
 
 here is how it works (or should):
 
 -an input signal gets amplified by a large

Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!

2014-04-28 Thread Simon Iten

Well i know exactly what the Patch does... I just dont know why the two numbers 
before the Addition Need to be -1 And -2 :-)

Will Look at your Version asap. 

Cheers

Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com:

 I have no idea what the patch is doing either, but I was able to clean it a 
 lot.
 
 many things that didn't need to be there
 
 cheers
 
 
 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com:
 roman, thanks for your inputs.
 
 i tried both fexpr and expr and sticked to fexpr at some point, don’t know 
 why though. will change it back!  (i remember reading that fexpr was more 
 expensive but also more precise)
 
 to make the whole thing work with real world signals (bass guitar in my 
 case) you have to add an adaptive filter in the beginning of the chain 
 (which is very easy because you get the frequency information hehe…) this 
 will filter out overtones and prevent octave jumping.
 
 thanks
 
 simon
 
 On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote:
 
  That works very well. Good job and thanks for sharing!
 
  One minor thing jumped to my eye: Your patch uses some instances of
  [fexpr~] and all of them actually don't need [fexpr~] functionality. I
  experienced that [fexpr~] is quite expensive, which seems apparent
  considering it is designed for feedback algorithms. I don't know if
  [fexpr~] is also expensive when you use it not for feedbacks as your
  patch does. Anyway, you could replace them by likely less expensive
  [expr~] instances:
 
  [fexpr~ $x1=0] - [expr~ $v1=0]
 
  Roman
 
 
 
  On Mon, 2014-04-28 at 00:59 +0200, simon wrote:
  hey miller and list,
 
 
  find attached a version that works beautifully. it's a dirty hack without 
  upsampling but it works extremly well. don't ask me why, i have no idea.
 
  thanks for all the help miller, really appreciate it! and thanks for pd 
  in general :-)
 
  cheers,
 
  simon
 
  On Apr 27, 2014, at 8:59 PM, Simon Iten wrote:
 
  sorry this one went off-list :-)
 
 
  On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote:
 
  sure,
 
  here is the version with biquad in a subpatch with a block opject to 
  upsample. probably i'm doing something wrong, i just copied from the 
  block help-patch.
 
  sinetosawtoothupsample.pd
 
  On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote:
 
  Drat, I don't have any explanation for this...  can you send me the 
  patch
  again?
  cheers
  M
 
  On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote:
  hmm, changing change to biquad does also not work. i mean it does as 
  long as i don't upsample in the subpatch. as soon as i change the 
  block object i get square instead of pulses...
 
  On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote:
 
  Actually I don't know where the change~ object is from - I've nver 
  seen t
  before.  I would just use biquad~ 0 0 1 -1 0 (assuming that change~ 
  simply
  ubtracts the previous sample from teh current one as I guessed from 
  the patch :)
 
  M
 
  On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote:
  ok tried to upsample the whole thing (after the osc~) and now 
  change~ does nothing anymore… it just spits out the same square 
  wave i feed in…clues?
 
 
  On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote:
 
  crosspost! sorry about the noise. thanks for the inputs i will try 
  to to this. not sure if i can. otherwise i will ask back if that’s 
  ok!
  On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote:
 
  so if i would measure at the peak of the sawtooth and would 
  upsample inside the pd patch, i would get higher resolution, 
  right?
 
  any ideas how i can measure at the peak? (using the rpole output 
  on both samphold inputs does not work and delaying one of them is 
  also not working)
 
  which
 
  i would highly recommend you try this method with your gk-3 
  equipped guitar (one for each string) since you only have to 
  cover a two octave range per string the error is tolerable. (you 
  can add an offset to make it fit)
  On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:
 
  That is an excellent, witty way to measure pulse withs using
  only tilde obects - my hat's off to you.
 
  The methond only has limited accuracy since its measurement is in
  samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 
  kHz is
  only 50 samples, so there's only 2% accuracy.  That's about 1/3 
  of a
  half tone (30-ish cents) which would sound horribly out of tune.
 
  There's an alternative sine-to-sawtooth recipe described here:
 
  http://msp.ucsd.edu/Publications/icmc10.pdf
 
  This is the basis of my guitar processing patch, smeck, but 
  should be more
  broadly useful.  But it has its own limitations: the sawtooth 
  you get out
  is wiggly if the input sn't a pure sinusoid.
 
  There's also the possibility of simply pitch tracking with 
  sigmund~.  Use
  a maximum frequency around 6000 and a maximum of 6 partals 
  (default 50

[PD] pitch to voltage

dear list,

i have a strange problem with my “sinetosawtooth” patch.

it is basically a version of the pitch to voltage conversion used in the old 
gr300 guitar synths from roland.

i cut out all the clutter to make it easier to look at and understand. (cut out 
the adaptive filtering at the input since i use a sine wave for this example 
and not a guitar string)

here is how it works (or should):

-an input signal gets amplified by a large factor and clipped. this squares the 
input.

-the square wave is converted to pulses. 

-the pulses from the rising of the square wave are used to set and reset an 
accumulating filter (rpole~)

this results in a sawtooth wave that varies in amplitude depending on the 
frequency of the input.

-a sample and hold samples the peak of the sawtooth and holds it until the next 
peak occurs. this, after a conversion gives us the input frequency. yeah!

in the example patch i used the falling edges of the square wave to 
trigger the sample and hold. this samples the sawtooth amplitude after half the 
rising. (this is also why i have  22050 in fexpr~ and not 44100) i could not 
figure out how to sample the peak of the sawtooth, so suggestions here are very 
welcome.

now to the problem:

the extracted frequency does not exactly correspond to the input frequency. it 
is pretty close at low frequencies but gets worse at higher frequencies. the 
factor is not constant. at even higher frequencies (around 5000 hertz) the 
reported frequency gets totally out of control.

i first thought this is because the samphold~ object is inaccurate. but i then 
saw that the sawtooth wave from the rpole~ object has no constant amplitude 
even with the input frequency not changing. so it seems that either rpole~ or 
change~ is not accurate.

or the problem is that i sample in the middle of the rising and not at the top 
( as described earlier)

attached the sinetosawtooth patch. set your sound card to 44100 or change the 
22050 in fexpr~ to half the sampling frequency.

i would really appreciate if somebody could have a look at this,

thanks, simon



sinetosawtooth.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] UDOO Quad and Generic Guitar to USB link issues

do you use the hardware or the plugin tab in the pd preferences? i found that i 
had to use the plugin and not the hardware to get results without distortion. 
also you should use debian hard float image and not linaro, it works better 
with puredata. and, i would not use jack but alsa directly with puredata.

On 11 Apr 2014, at 01:54, Carlos Sanchez csanchez...@gmail.com wrote:

 Neat project sir!
 
 I have tried what you mentioned Brian and I cant get the system to even play 
 sounds with the right device. Using aplay file.wav works with the default 
 output but when i try to specify the output like so aplay -D hwplug;2,0 
 file.wav nothing comes up. I got these commands somewhere on the net, can 
 you vouch for them? Also, when listing the devices with alsamixer, my 
 soundcard lists a mic input which is odd since it has a mono in and stereo 
 out...
 
 If this is of any use, here is the output of aplay -l:
 
  List of PLAYBACK Hardware Devices 
 card 0: vt1613audio [vt1613-audio], device 0: HiFi vt1613-0 []
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 card 1: imxhdmisoc [imx-hdmi-soc], device 0: IMX HDMI TX mxc-hdmi-soc-0 []
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 card 2: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 
 My soundcard is the card 2 and I can not get any sound out of it via aplay!
 
 
 
 On Tue, Apr 8, 2014 at 5:26 PM, Brian Fay ovaltinevor...@gmail.com wrote:
 The reason I suggested trying arecord | aplay is because it would be 
 running input and output simultaneously. In Audacity, you're doing one after 
 the other.
 
 Unfortunately, I'm not sure exactly what is going wrong here. Does your 
 soundcard work as expected on other computers? Was it fine on the BeagleBone 
 Black?
 
 On the Raspberry Pi, I'm running a multi-effects pedal, all built in Pd. 
 There's two parallel chains of processes, (each can run up to eight effects). 
 The effects I'm using are a looper, delay, waveshaper distortion, flanger, 
 granular synthesis (sort of limited implementation), reverb, and EQ. I'm 
 controlling things with a QuNeo MIDI controller and a push button attached to 
 the GPIO pins on the Pi.
 
 By default, each of the eight effects in each chain are set to bypass, 
 which simply passes the signal onto the next effect. However, you can adjust 
 this on the fly for the effects to be whatever you want, so I can set up 
 something like:
 Chain A: looper - distortion - flanger - delay - granular - reverb - EQ 
 - bypass - output
 Chain B: delay - bypass - bypass - bypass - bypass - bypass - bypass - 
 bypass - output
 
 I can independently control volume of each chain, so I could use Chain A to 
 build up some sort of droning ambience, and then solo over it using Chain B.
 
 In practice, there is definitely a limit to the ability of the Raspberry Pi. 
 I think the example I just mentioned would probably run, but if I try 
 throwing too many effects on at once, (flanger, reverb, distortion, and 
 granular are all pretty intensive), I will start getting glitches - huge 
 crackles and jitters in audio. Turning off a few effects will stop the 
 glitches, but I all I can do to prevent them is to be conservative about how 
 many effects I turn on.
 
 Just uploaded a little demo to Soundcloud of a recording I made with a 
 somewhat similar FX setup to what I mentioned. It was recorded with my 
 cell-phone, so it's a bit awful sound quality-wise (also really really quiet, 
 whoops...).
 https://soundcloud.com/ovaltine-vortex/raspberry-improv
 
 If you're curious about the patches and stuff, it's all here, but it's 
 hard-coded to MIDI values on the QuNeo and might be a bit confusing:
 https://github.com/YottaSecond/thesisRepo
 
 
 On Sun, Apr 6, 2014 at 2:37 PM, Carlos Sanchez csanchez...@gmail.com wrote:
 Hey list,
 
 Thanks for your prompt replies and helpfulness!
 
 I could not get qjackctl to work, the audio will not go through and the PD 
 CPU load gets abnormally high at around 67%...
 I had already played with the sample rate and I had noticed that augmenting 
 the frequency yields better results but the noise was still very present. 
 The sound card itself works correctly with Audacity so I am sure it would 
 work with the arecord and aplay commands Brian suggested. Weirdly, it is only 
 with PD that it is struggling...
 
 On a more encouraging note, as Brian suggested, it seems that the problem (or 
 one possibility) is the duplex audio. I haven't thought about using the card 
 as an output only device before and it did work! But afterwards, I was not 
 able to change the settings back and use the noisy duplex audio any more, I 
 was only able to switch the output devices...
 
 @Brian: What type of software are you using for the signal processing with 
 the Raspberry Pi? I am very curious because I had first attempted to build 
 this project on a BeagleBone Black but the heavy PD patches made it unstable 
 or

Re: [PD] pitch to voltage

so if i would measure at the peak of the sawtooth and would upsample inside the 
pd patch, i would get higher resolution, right?

any ideas how i can measure at the peak? (using the rpole output on both 
samphold inputs does not work and delaying one of them is also not working)

which 

i would highly recommend you try this method with your gk-3 equipped guitar 
(one for each string) since you only have to cover a two octave range per 
string the error is tolerable. (you can add an offset to make it fit)
On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:

 That is an excellent, witty way to measure pulse withs using
 only tilde obects - my hat's off to you.
 
 The methond only has limited accuracy since its measurement is in
 samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is
 only 50 samples, so there's only 2% accuracy.  That's about 1/3 of a
 half tone (30-ish cents) which would sound horribly out of tune.
 
 There's an alternative sine-to-sawtooth recipe described here:
 
 http://msp.ucsd.edu/Publications/icmc10.pdf
 
 This is the basis of my guitar processing patch, smeck, but should be more
 broadly useful.  But it has its own limitations: the sawtooth you get out
 is wiggly if the input sn't a pure sinusoid.
 
 There's also the possibility of simply pitch tracking with sigmund~.  Use
 a maximum frequency around 6000 and a maximum of 6 partals (default 50!)
 for best results.
 
 cheers
 M
 
 On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
 dear list,
 
 i have a strange problem with my “sinetosawtooth” patch.
 
 it is basically a version of the pitch to voltage conversion used in the old 
 gr300 guitar synths from roland.
 
 i cut out all the clutter to make it easier to look at and understand. (cut 
 out the adaptive filtering at the input since i use a sine wave for this 
 example and not a guitar string)
 
 here is how it works (or should):
 
 -an input signal gets amplified by a large factor and clipped. this squares 
 the input.
 
 -the square wave is converted to pulses. 
 
 -the pulses from the rising of the square wave are used to set and reset an 
 accumulating filter (rpole~)
 
 this results in a sawtooth wave that varies in amplitude depending on the 
 frequency of the input.
 
 -a sample and hold samples the peak of the sawtooth and holds it until the 
 next peak occurs. this, after a conversion gives us the input frequency. 
 yeah!
 
  in the example patch i used the falling edges of the square wave to 
 trigger the sample and hold. this samples the sawtooth amplitude after half 
 the rising. (this is also why i have  22050 in fexpr~ and not 44100) i could 
 not figure out how to sample the peak of the sawtooth, so suggestions here 
 are very welcome.
 
 now to the problem:
 
 the extracted frequency does not exactly correspond to the input frequency. 
 it is pretty close at low frequencies but gets worse at higher frequencies. 
 the factor is not constant. at even higher frequencies (around 5000 hertz) 
 the reported frequency gets totally out of control.
 
 i first thought this is because the samphold~ object is inaccurate. but i 
 then saw that the sawtooth wave from the rpole~ object has no constant 
 amplitude even with the input frequency not changing. so it seems that 
 either rpole~ or change~ is not accurate.
 
 or the problem is that i sample in the middle of the rising and not at the 
 top ( as described earlier)
 
 attached the sinetosawtooth patch. set your sound card to 44100 or change 
 the 22050 in fexpr~ to half the sampling frequency.
 
 i would really appreciate if somebody could have a look at this,
 
 thanks, simon
 
 
 
 ___
 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] pitch to voltage

crosspost! sorry about the noise. thanks for the inputs i will try to to this. 
not sure if i can. otherwise i will ask back if that’s ok!
On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote:

 so if i would measure at the peak of the sawtooth and would upsample inside 
 the pd patch, i would get higher resolution, right?
 
 any ideas how i can measure at the peak? (using the rpole output on both 
 samphold inputs does not work and delaying one of them is also not working)
 
 which 
 
 i would highly recommend you try this method with your gk-3 equipped guitar 
 (one for each string) since you only have to cover a two octave range per 
 string the error is tolerable. (you can add an offset to make it fit)
 On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:
 
 That is an excellent, witty way to measure pulse withs using
 only tilde obects - my hat's off to you.
 
 The methond only has limited accuracy since its measurement is in
 samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is
 only 50 samples, so there's only 2% accuracy.  That's about 1/3 of a
 half tone (30-ish cents) which would sound horribly out of tune.
 
 There's an alternative sine-to-sawtooth recipe described here:
 
 http://msp.ucsd.edu/Publications/icmc10.pdf
 
 This is the basis of my guitar processing patch, smeck, but should be more
 broadly useful.  But it has its own limitations: the sawtooth you get out
 is wiggly if the input sn't a pure sinusoid.
 
 There's also the possibility of simply pitch tracking with sigmund~.  Use
 a maximum frequency around 6000 and a maximum of 6 partals (default 50!)
 for best results.
 
 cheers
 M
 
 On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
 dear list,
 
 i have a strange problem with my “sinetosawtooth” patch.
 
 it is basically a version of the pitch to voltage conversion used in the 
 old gr300 guitar synths from roland.
 
 i cut out all the clutter to make it easier to look at and understand. (cut 
 out the adaptive filtering at the input since i use a sine wave for this 
 example and not a guitar string)
 
 here is how it works (or should):
 
 -an input signal gets amplified by a large factor and clipped. this squares 
 the input.
 
 -the square wave is converted to pulses. 
 
 -the pulses from the rising of the square wave are used to set and reset an 
 accumulating filter (rpole~)
 
 this results in a sawtooth wave that varies in amplitude depending on the 
 frequency of the input.
 
 -a sample and hold samples the peak of the sawtooth and holds it until the 
 next peak occurs. this, after a conversion gives us the input frequency. 
 yeah!
 
 in the example patch i used the falling edges of the square wave to 
 trigger the sample and hold. this samples the sawtooth amplitude after half 
 the rising. (this is also why i have  22050 in fexpr~ and not 44100) i 
 could not figure out how to sample the peak of the sawtooth, so suggestions 
 here are very welcome.
 
 now to the problem:
 
 the extracted frequency does not exactly correspond to the input frequency. 
 it is pretty close at low frequencies but gets worse at higher frequencies. 
 the factor is not constant. at even higher frequencies (around 5000 hertz) 
 the reported frequency gets totally out of control.
 
 i first thought this is because the samphold~ object is inaccurate. but i 
 then saw that the sawtooth wave from the rpole~ object has no constant 
 amplitude even with the input frequency not changing. so it seems that 
 either rpole~ or change~ is not accurate.
 
 or the problem is that i sample in the middle of the rising and not at the 
 top ( as described earlier)
 
 attached the sinetosawtooth patch. set your sound card to 44100 or change 
 the 22050 in fexpr~ to half the sampling frequency.
 
 i would really appreciate if somebody could have a look at this,
 
 thanks, simon
 
 
 
 ___
 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] pitch to voltage

ok tried to upsample the whole thing (after the osc~) and now change~ does 
nothing anymore… it just spits out the same square wave i feed in…clues?


On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote:

 crosspost! sorry about the noise. thanks for the inputs i will try to to 
 this. not sure if i can. otherwise i will ask back if that’s ok!
 On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote:
 
 so if i would measure at the peak of the sawtooth and would upsample inside 
 the pd patch, i would get higher resolution, right?
 
 any ideas how i can measure at the peak? (using the rpole output on both 
 samphold inputs does not work and delaying one of them is also not working)
 
 which 
 
 i would highly recommend you try this method with your gk-3 equipped guitar 
 (one for each string) since you only have to cover a two octave range per 
 string the error is tolerable. (you can add an offset to make it fit)
 On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:
 
 That is an excellent, witty way to measure pulse withs using
 only tilde obects - my hat's off to you.
 
 The methond only has limited accuracy since its measurement is in
 samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is
 only 50 samples, so there's only 2% accuracy.  That's about 1/3 of a
 half tone (30-ish cents) which would sound horribly out of tune.
 
 There's an alternative sine-to-sawtooth recipe described here:
 
 http://msp.ucsd.edu/Publications/icmc10.pdf
 
 This is the basis of my guitar processing patch, smeck, but should be more
 broadly useful.  But it has its own limitations: the sawtooth you get out
 is wiggly if the input sn't a pure sinusoid.
 
 There's also the possibility of simply pitch tracking with sigmund~.  Use
 a maximum frequency around 6000 and a maximum of 6 partals (default 50!)
 for best results.
 
 cheers
 M
 
 On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
 dear list,
 
 i have a strange problem with my “sinetosawtooth” patch.
 
 it is basically a version of the pitch to voltage conversion used in the 
 old gr300 guitar synths from roland.
 
 i cut out all the clutter to make it easier to look at and understand. 
 (cut out the adaptive filtering at the input since i use a sine wave for 
 this example and not a guitar string)
 
 here is how it works (or should):
 
 -an input signal gets amplified by a large factor and clipped. this 
 squares the input.
 
 -the square wave is converted to pulses. 
 
 -the pulses from the rising of the square wave are used to set and reset 
 an accumulating filter (rpole~)
 
 this results in a sawtooth wave that varies in amplitude depending on the 
 frequency of the input.
 
 -a sample and hold samples the peak of the sawtooth and holds it until the 
 next peak occurs. this, after a conversion gives us the input frequency. 
 yeah!
 
in the example patch i used the falling edges of the square wave to 
 trigger the sample and hold. this samples the sawtooth amplitude after 
 half the rising. (this is also why i have  22050 in fexpr~ and not 44100) 
 i could not figure out how to sample the peak of the sawtooth, so 
 suggestions here are very welcome.
 
 now to the problem:
 
 the extracted frequency does not exactly correspond to the input 
 frequency. it is pretty close at low frequencies but gets worse at higher 
 frequencies. the factor is not constant. at even higher frequencies 
 (around 5000 hertz) the reported frequency gets totally out of control.
 
 i first thought this is because the samphold~ object is inaccurate. but i 
 then saw that the sawtooth wave from the rpole~ object has no constant 
 amplitude even with the input frequency not changing. so it seems that 
 either rpole~ or change~ is not accurate.
 
 or the problem is that i sample in the middle of the rising and not at the 
 top ( as described earlier)
 
 attached the sinetosawtooth patch. set your sound card to 44100 or change 
 the 22050 in fexpr~ to half the sampling frequency.
 
 i would really appreciate if somebody could have a look at this,
 
 thanks, simon
 
 
 
 ___
 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] pitch to voltage

sorry this one went off-list :-)


On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote:

 sure,
 
 here is the version with biquad in a subpatch with a block opject to 
 upsample. probably i'm doing something wrong, i just copied from the block 
 help-patch.
 
 sinetosawtoothupsample.pd
 
 On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote:
 
 Drat, I don't have any explanation for this...  can you send me the patch
 again?
 cheers
 M
 
 On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote:
 hmm, changing change to biquad does also not work. i mean it does as long 
 as i don't upsample in the subpatch. as soon as i change the block object i 
 get square instead of pulses...
 
 On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote:
 
 Actually I don't know where the change~ object is from - I've nver seen t
 before.  I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply
 ubtracts the previous sample from teh current one as I guessed from the 
 patch :)
 
 M
 
 On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote:
 ok tried to upsample the whole thing (after the osc~) and now change~ 
 does nothing anymore… it just spits out the same square wave i feed 
 in…clues?
 
 
 On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote:
 
 crosspost! sorry about the noise. thanks for the inputs i will try to to 
 this. not sure if i can. otherwise i will ask back if that’s ok!
 On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote:
 
 so if i would measure at the peak of the sawtooth and would upsample 
 inside the pd patch, i would get higher resolution, right?
 
 any ideas how i can measure at the peak? (using the rpole output on 
 both samphold inputs does not work and delaying one of them is also not 
 working)
 
 which 
 
 i would highly recommend you try this method with your gk-3 equipped 
 guitar (one for each string) since you only have to cover a two octave 
 range per string the error is tolerable. (you can add an offset to make 
 it fit)
 On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:
 
 That is an excellent, witty way to measure pulse withs using
 only tilde obects - my hat's off to you.
 
 The methond only has limited accuracy since its measurement is in
 samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is
 only 50 samples, so there's only 2% accuracy.  That's about 1/3 of a
 half tone (30-ish cents) which would sound horribly out of tune.
 
 There's an alternative sine-to-sawtooth recipe described here:
 
 http://msp.ucsd.edu/Publications/icmc10.pdf
 
 This is the basis of my guitar processing patch, smeck, but should be 
 more
 broadly useful.  But it has its own limitations: the sawtooth you get 
 out
 is wiggly if the input sn't a pure sinusoid.
 
 There's also the possibility of simply pitch tracking with sigmund~.  
 Use
 a maximum frequency around 6000 and a maximum of 6 partals (default 
 50!)
 for best results.
 
 cheers
 M
 
 On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
 dear list,
 
 i have a strange problem with my “sinetosawtooth” patch.
 
 it is basically a version of the pitch to voltage conversion used in 
 the old gr300 guitar synths from roland.
 
 i cut out all the clutter to make it easier to look at and 
 understand. (cut out the adaptive filtering at the input since i use 
 a sine wave for this example and not a guitar string)
 
 here is how it works (or should):
 
 -an input signal gets amplified by a large factor and clipped. this 
 squares the input.
 
 -the square wave is converted to pulses. 
 
 -the pulses from the rising of the square wave are used to set and 
 reset an accumulating filter (rpole~)
 
 this results in a sawtooth wave that varies in amplitude depending on 
 the frequency of the input.
 
 -a sample and hold samples the peak of the sawtooth and holds it 
 until the next peak occurs. this, after a conversion gives us the 
 input frequency. yeah!
 
   in the example patch i used the falling edges of the square 
 wave to trigger the sample and hold. this samples the sawtooth 
 amplitude after half the rising. (this is also why i have  22050 in 
 fexpr~ and not 44100) i could not figure out how to sample the peak 
 of the sawtooth, so suggestions here are very welcome.
 
 now to the problem:
 
 the extracted frequency does not exactly correspond to the input 
 frequency. it is pretty close at low frequencies but gets worse at 
 higher frequencies. the factor is not constant. at even higher 
 frequencies (around 5000 hertz) the reported frequency gets totally 
 out of control.
 
 i first thought this is because the samphold~ object is inaccurate. 
 but i then saw that the sawtooth wave from the rpole~ object has no 
 constant amplitude even with the input frequency not changing. so it 
 seems that either rpole~ or change~ is not accurate.
 
 or the problem is that i sample in the middle of the rising and not 
 at the top ( as described earlier)
 
 attached the sinetosawtooth

[PD] SOLVED!!! Re: pitch to voltage SOLVED!!!

2014-04-27 Thread simon

hey miller and list,


find attached a version that works beautifully. it's a dirty hack without 
upsampling but it works extremly well. don't ask me why, i have no idea.

thanks for all the help miller, really appreciate it! and thanks for pd in 
general :-)

cheers,

simon



sinetosawtooth.pd
Description: Binary data

On Apr 27, 2014, at 8:59 PM, Simon Iten wrote:

 sorry this one went off-list :-)
 
 
 On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote:
 
 sure,
 
 here is the version with biquad in a subpatch with a block opject to 
 upsample. probably i'm doing something wrong, i just copied from the block 
 help-patch.
 
 sinetosawtoothupsample.pd
 
 On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote:
 
 Drat, I don't have any explanation for this...  can you send me the patch
 again?
 cheers
 M
 
 On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote:
 hmm, changing change to biquad does also not work. i mean it does as long 
 as i don't upsample in the subpatch. as soon as i change the block object 
 i get square instead of pulses...
 
 On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote:
 
 Actually I don't know where the change~ object is from - I've nver seen t
 before.  I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply
 ubtracts the previous sample from teh current one as I guessed from the 
 patch :)
 
 M
 
 On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote:
 ok tried to upsample the whole thing (after the osc~) and now change~ 
 does nothing anymore… it just spits out the same square wave i feed 
 in…clues?
 
 
 On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote:
 
 crosspost! sorry about the noise. thanks for the inputs i will try to 
 to this. not sure if i can. otherwise i will ask back if that’s ok!
 On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote:
 
 so if i would measure at the peak of the sawtooth and would upsample 
 inside the pd patch, i would get higher resolution, right?
 
 any ideas how i can measure at the peak? (using the rpole output on 
 both samphold inputs does not work and delaying one of them is also 
 not working)
 
 which 
 
 i would highly recommend you try this method with your gk-3 equipped 
 guitar (one for each string) since you only have to cover a two octave 
 range per string the error is tolerable. (you can add an offset to 
 make it fit)
 On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote:
 
 That is an excellent, witty way to measure pulse withs using
 only tilde obects - my hat's off to you.
 
 The methond only has limited accuracy since its measurement is in
 samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is
 only 50 samples, so there's only 2% accuracy.  That's about 1/3 of a
 half tone (30-ish cents) which would sound horribly out of tune.
 
 There's an alternative sine-to-sawtooth recipe described here:
 
 http://msp.ucsd.edu/Publications/icmc10.pdf
 
 This is the basis of my guitar processing patch, smeck, but should be 
 more
 broadly useful.  But it has its own limitations: the sawtooth you get 
 out
 is wiggly if the input sn't a pure sinusoid.
 
 There's also the possibility of simply pitch tracking with sigmund~.  
 Use
 a maximum frequency around 6000 and a maximum of 6 partals (default 
 50!)
 for best results.
 
 cheers
 M
 
 On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
 dear list,
 
 i have a strange problem with my “sinetosawtooth” patch.
 
 it is basically a version of the pitch to voltage conversion used in 
 the old gr300 guitar synths from roland.
 
 i cut out all the clutter to make it easier to look at and 
 understand. (cut out the adaptive filtering at the input since i use 
 a sine wave for this example and not a guitar string)
 
 here is how it works (or should):
 
 -an input signal gets amplified by a large factor and clipped. this 
 squares the input.
 
 -the square wave is converted to pulses. 
 
 -the pulses from the rising of the square wave are used to set and 
 reset an accumulating filter (rpole~)
 
 this results in a sawtooth wave that varies in amplitude depending 
 on the frequency of the input.
 
 -a sample and hold samples the peak of the sawtooth and holds it 
 until the next peak occurs. this, after a conversion gives us the 
 input frequency. yeah!
 
  in the example patch i used the falling edges of the square 
 wave to trigger the sample and hold. this samples the sawtooth 
 amplitude after half the rising. (this is also why i have  22050 in 
 fexpr~ and not 44100) i could not figure out how to sample the peak 
 of the sawtooth, so suggestions here are very welcome.
 
 now to the problem:
 
 the extracted frequency does not exactly correspond to the input 
 frequency. it is pretty close at low frequencies but gets worse at 
 higher frequencies. the factor is not constant. at even higher 
 frequencies (around 5000 hertz) the reported frequency gets totally 
 out of control.
 
 i first thought this is because

Re: [PD] Controlling amplitude with readsf~

2014-04-22 Thread Simon Wise


On 22/04/14 21:12, Claire O'Connor wrote:

I am still having a bit of trouble. I am using another line object to ramp
up the number box to fade in my .wav file but when I go to ramp it back
down, it jumps straight to zero. I have also tried to 'reset' the line
object but that involves sending a message '0' which makes the amplitude of
the .wav file jump down again. Any ideas as to how this issue might be
resolved? I have a line of .wav files that I want to fade in and fade out
as they each play.


sending a single number [0( will jump straight to that value,
a pair will ramp so [0 2000( goes from current value to 0 in 2 seconds
then [1 3000( goes to 1 in 3 seconds ... play around with the help patch.


Simon



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-dev] oggread~ not working on pd-extended or libpd on windows.

2014-04-04 Thread Simon Wise


On 05/04/14 14:21, Martin Peach wrote:

I think it's here:

http://sourceforge.net/p/pure-data/patches/


that seems to be for pd rather than externals???

maybe a patch to debian package pd-pdogg, which could then get upstream, since 
for some (especially older) externals this may be the most actively maintained 
repo? I don't know about [oggread~] in particular though ... but is this 
problem/patch only a windows one?



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Looking for some processing tools for audio mixing

2014-03-31 Thread Simon Wise


On 01/04/14 00:20, Christoph Kuhr wrote:

Hi everyone,

at the moment I am using some analog outboard equipment to assist me
with my audio mixing.


for audio mixing to replace an analogue mixer you are probably better off 
looking at ardour, or any other digital audio workstation.


You can of course mix audio in pd, there are many objects to help you, no need 
for extended ... the help menu of any pd will show you examples, the 
documentation (in the help menu) will explain more.


Simon


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT] Pd to play sounds simultaneously on 8 speakers with cheap computer

2014-03-29 Thread Simon Wise


On 29/03/14 22:56, Jack wrote:

Hello,

Is it possible to use BeagleBoard, Raspberry Pi, Udoo or others without
dropout with this configuration :

8 IR sensors
1 BeagleBoard (or Raspberry Pi, or Udoo or others) with Pd and linux
1 sound cards with 8 output
8 speakers

like this : 8 IR sensors -  Beagleboard -  sound card -  8 speakers (so
it is possible to play 8 sounds at 44100 Hz 16 bits *simultaneously*).

If yes, can you tell me which model of sound card works well with these
cards ?
Thanx.
++


The esi gigaport hd+ is said to give 8 outs cleanly on an Rpi, search the list 
for reports from several people, but I have not tried it myself.


With an Rpi you might then use the GPIO for your IR, but if the IR stuff is USB 
then you'd have to test, and may well be out of luck. A cheaper sound card and a 
more expensive computer may be just as sensible though.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd on debian hardfloat on udoo

2014-03-25 Thread Simon Iten

yeah, but that page is somewhat misleading, the 12.04 linaro (based on ubuntu) 
in the udoo download section is not hf. i used the debian hf image they provide.

here is the “sound card” i use:

http://www.dx.com/p/usb-3d-sound-adapter-color-assorted-5831#.UzHt6Nzoah0


On 25 Mar 2014, at 10:56, Alexandros Drymonitis adr...@gmail.com wrote:

 
 
 
 On Tue, Mar 25, 2014 at 11:51 AM, Alexandros Drymonitis adr...@gmail.com 
 wrote:
 
 
 
 On Tue, Mar 25, 2014 at 12:00 AM, Simon Iten itensi...@gmail.com wrote:
 just a quick update:
 
 pd runs definitely smoother on the udoo with the debian hard float image.
 Also, it might be obvious to some, but which one is the debian hard float 
 image? Is it in Udoo's website? 
 Sorry to bother the whole list, just found this page which mentions the hard 
 float flavors: Debian Wheezy, Ubunt Studio  and Ubuntu 12.04 
 
 
 
 ___
 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

2014-03-24 Thread Simon Iten

hey dan and list,

i gave pd on the debian hardfloat image a try and can not run it. it
compiles just fine. this is what i get on the console...

debian@udoo-debian-hfp:~$ pd -verbose
Pd-0.45.4 () compiled 14:17:43 Mar 24 2014
port 5400
TCL_LIBRARY=/usr/local/lib/pd/lib/tcl/library
TK_LIBRARY=/usr/local/lib/pd/lib/tk/library   wish
/usr/local/lib/pd/tcl//pd-gui.tcl 5400
Waiting for connection request...
/usr/local/lib/pd/bin/pd-watchdog
watchdog: signaling pd...
watchdog: signaling pd...
watchdog: signaling pd...
watchdog: signaling pd...
watchdog: signaling pd...



then a watchdog-signaling loop...

this also happens with the version installed via synaptic.

any thoughts?

cheers


On Sat, Mar 15, 2014 at 4:50 PM, Dan Wilcox danomat...@gmail.com wrote:

 Yeah, I wanted to use the hard float image but I was under time pressure
 and more things seemed to work out of the box with the Linaro one. I'll
 have more time to revisit it later.

 On Mar 15, 2014, at 12:46 PM, Simon Iten itensi...@gmail.com wrote:

 hmm,

 well to me 12ms is way to much. but then again i play a lot of fast attack
 notes in up-tempo pieces :-)

 thanks for your notes anyway, they helped a lot! and write back when you
 tried with the debian hardfloat image. i tried it for a short time and it
 was not very stable with pd. but then again i did not try a lot of things
 to fix this.

 cheers
 On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote:

 Check this page:
 http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable

 I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms.

 The accumulation of a monitors and an effect or two gets you to 8ms.
 Acceptable latency is 12 ms.

 Again, I haven't measured my rig or the latency of my old wearable rig,
 both both were responsive to me, so they must e at least around 12 ms.

 Sorry for being unscientific about it.

 enohp ym morf tnes
 --
 Dan Wilcox
 danomatika.com
 robotcowboy.com

 On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote:

 dan, no 15 ms is in no way tolerable for live use (if you have effects
 that should react in realtime) it is of course ok for delay and reverb
 stuff. the latency from an amp because of cable length and stuff is totally
 different, since your ear actually hears where the sound comes from and can
 adapt.
 but for studio use for example, 15 ms on a headphone is really two attacks
 for evey attack. heck even 10ms is evil :-) of course your/anyones mileage
 may vary. but i only wanted the box to output delay and reverb soundscape
 stuff away, so i might be good. i will add analog circuitry that mixes the
 dry and effect part of the signal, so i get no (very very little) latency
 on the unaffected part of the signal.

 no worries as far as the script goes. i had no problems at all to follow
 it. but i worked with linux a lot before. i was just suggesting, that the
 typical ubuntu user would not get some of the steps in between your steps
 :-)


 On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote:

 I haven't run any latency tests, so that might be what I'm getting. If so,
 it's acceptable for what I do. From what I've read, guitar - effects -
 amp latencies are already closer to 20ms.

 Sorry I haven't gotten back to the UDOO and pulled the relevant scripts
 etc off of it yet. I'm trying to get a few things done before I head out of
 town for work the next 2 weeks. I might be abel to get to it Sunday, but no
 promises.

 On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote:

 hi dan,

 tried your setup/instructions. thanks, it now works down to 15ms. at 12ms
 i start to get clicks here and there...

 your script has some errors (missing instructions a novice would not
 understand how to deal with). do you want me to post them, or do you overdo
 it anyway?

 thanks again

 simon

 On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote:

 Thanks. I was just waiting to redo my website, edit the video, put the
 pics together, etc etc but life and freelance work get in the way. Man, I
 could use a clone right about now :P

 On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote:

 Also interested in the UDOO setup instructions so thank you. A bit OT but,
 Dan, love your work (that onward to mars patch is awesome) thanks for the
 links. I think people should post more of this sort of thing to the list,
 celebrate what we make. =)


 On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote:

 FWIW: here's a picture of my UDOO setup inside my Mars space suit
 backpack: http://www.flickr.com/photos/danomatika/13115604285/

 Media of the backpack in use
 https://twitter.com/danomatika/status/433273394122207232/photo/1 
 https://vimeo.com/86670103 (not my video, I'll put out a different edit
 soon)

 On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote:

 I will do that later tonight when I boot the udoo and pull my run scripts

Re: [PD] udoo board sound issues

2014-03-24 Thread Simon Iten

nevermind, found the solution. here it is..

http://lists.puredata.info/pipermail/pd-list/2012-09/097892.html

cheers


On Mon, Mar 24, 2014 at 2:43 PM, Simon Iten itensi...@gmail.com wrote:

 hey dan and list,

 i gave pd on the debian hardfloat image a try and can not run it. it
 compiles just fine. this is what i get on the console...

 debian@udoo-debian-hfp:~$ pd -verbose
 Pd-0.45.4 () compiled 14:17:43 Mar 24 2014
 port 5400
 TCL_LIBRARY=/usr/local/lib/pd/lib/tcl/library
 TK_LIBRARY=/usr/local/lib/pd/lib/tk/library   wish
 /usr/local/lib/pd/tcl//pd-gui.tcl 5400
 Waiting for connection request...
 /usr/local/lib/pd/bin/pd-watchdog
 watchdog: signaling pd...
 watchdog: signaling pd...
 watchdog: signaling pd...
 watchdog: signaling pd...
 watchdog: signaling pd...



 then a watchdog-signaling loop...

 this also happens with the version installed via synaptic.

 any thoughts?

 cheers


 On Sat, Mar 15, 2014 at 4:50 PM, Dan Wilcox danomat...@gmail.com wrote:

 Yeah, I wanted to use the hard float image but I was under time pressure
 and more things seemed to work out of the box with the Linaro one. I'll
 have more time to revisit it later.

 On Mar 15, 2014, at 12:46 PM, Simon Iten itensi...@gmail.com wrote:

 hmm,

 well to me 12ms is way to much. but then again i play a lot of fast
 attack notes in up-tempo pieces :-)

 thanks for your notes anyway, they helped a lot! and write back when you
 tried with the debian hardfloat image. i tried it for a short time and it
 was not very stable with pd. but then again i did not try a lot of things
 to fix this.

 cheers
 On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote:

 Check this page:
 http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable

 I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms.

 The accumulation of a monitors and an effect or two gets you to 8ms.
 Acceptable latency is 12 ms.

 Again, I haven't measured my rig or the latency of my old wearable rig,
 both both were responsive to me, so they must e at least around 12 ms.

 Sorry for being unscientific about it.

 enohp ym morf tnes
 --
 Dan Wilcox
 danomatika.com
 robotcowboy.com

 On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote:

 dan, no 15 ms is in no way tolerable for live use (if you have effects
 that should react in realtime) it is of course ok for delay and reverb
 stuff. the latency from an amp because of cable length and stuff is totally
 different, since your ear actually hears where the sound comes from and can
 adapt.
 but for studio use for example, 15 ms on a headphone is really two
 attacks for evey attack. heck even 10ms is evil :-) of course your/anyones
 mileage may vary. but i only wanted the box to output delay and reverb
 soundscape stuff away, so i might be good. i will add analog circuitry that
 mixes the dry and effect part of the signal, so i get no (very very little)
 latency on the unaffected part of the signal.

 no worries as far as the script goes. i had no problems at all to follow
 it. but i worked with linux a lot before. i was just suggesting, that the
 typical ubuntu user would not get some of the steps in between your steps
 :-)


 On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote:

 I haven't run any latency tests, so that might be what I'm getting. If
 so, it's acceptable for what I do. From what I've read, guitar - effects
 - amp latencies are already closer to 20ms.

 Sorry I haven't gotten back to the UDOO and pulled the relevant scripts
 etc off of it yet. I'm trying to get a few things done before I head out of
 town for work the next 2 weeks. I might be abel to get to it Sunday, but no
 promises.

 On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote:

 hi dan,

 tried your setup/instructions. thanks, it now works down to 15ms. at 12ms
 i start to get clicks here and there...

 your script has some errors (missing instructions a novice would not
 understand how to deal with). do you want me to post them, or do you overdo
 it anyway?

 thanks again

 simon

 On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote:

 Thanks. I was just waiting to redo my website, edit the video, put the
 pics together, etc etc but life and freelance work get in the way. Man, I
 could use a clone right about now :P

 On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote:

 Also interested in the UDOO setup instructions so thank you. A bit OT
 but, Dan, love your work (that onward to mars patch is awesome) thanks
 for the links. I think people should post more of this sort of thing to the
 list, celebrate what we make. =)


 On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com
 wrote:

 FWIW: here's a picture of my UDOO setup inside my Mars space suit
 backpack: http://www.flickr.com/photos/danomatika/13115604285/

 Media of the backpack in use
 https://twitter.com/danomatika/status/433273394122207232/photo/1 
 https

[PD] pd on debian hardfloat on udoo

2014-03-24 Thread Simon Iten

just a quick update:

pd runs definitely smoother on the udoo with the debian hard float image. i am 
now down to 10ms with no problems  (and a very cheap usb-soundcard dongle)

8ms gives some crackles but still works…

this is with the usual rtprio and memlock stuff and -rt and for now with a gui.



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT] Raspberry Pi Wolfson Audio Card

2014-03-21 Thread Simon Iten

hi, nice! one question:

On 18 Mar 2014, at 12:02, Winfried Ritsch rit...@iem.at wrote:

 Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega:
 Anyone wants to share their experience with the BeagleBoneBlack?
 
 Yes.
 
 Since autumn, i am trying to set up an kit hardware+software with BBB for 
 computer-musicians as stomp box, works quite well, after successfully 
 installed it in a long term sound installation (headless):
 
 some points short:
 
 system:
 + BBB moved to Debian since this year (good)
 + USB Audio works fine und better now with kernel = 3.12
 + Network performance works better with kernel = 3.12
 - IO support doenst use device-tree overlays anymore on kernel  3.8
 + an iio-backend for Jack2 to use the internal AD's 
   in jack for processing sensor data in PD ;-)))  but tricky

does this mean, we get a “sound” i.e adc~ in from the internal ad’s? 
 
 sound:
 
 + down to 10ms with PD and cheap 8 channel out, 2 in 
   USB soundcard Logilink 7.1(EUR 19.90) 
 +  5ms with Logilink stereo USB (EUR 3,90) 
 + success with audio-cape (stereo, but too expensive for the quality)
 - sound quality is normally as bad as on most notebooks, tablets and so on 
 + but with a trick: filtered 5V supply for the USB-card not the USB power
   it seems to get reasonable quality 
   (They have all the same chips like expensive USB cards: C-Media)
 
 I just made a blog on this, but it is not public only for intern usage, if 
 anyone is interested in the IEM-embedded-Sound-Kit (doing some audio over 
 ethernet stuff) i can make it open (after some polishing, especially the 
 english) and release the PD-lib (GPIO,AD,I2C,... interfacing) for these 
 devices.
 
 This dev's should also work for Cubie-boards, Wand-boards, UDOO and other arm 
 based boards.
 
 mfg 
 winfried
 
 PS: Maybe we can start an own thread on this.
 
 
 
 On Thu, Mar 13, 2014 at 3:11 PM, Brian Fay ovaltinevor...@gmail.com wrote:
 While I'm sure that Dan is right that the UDOO is the better choice for
 USB audio, I do have to say that I've had decent success using my
 Raspberry
 Pi as a guitar effects processor, with the Behringer UCG102 interface.
 
 There's definitely a lot of quirkiness to getting it running... for
 example ALSA gets in an infinite restart loop when attempting low latency
 on pd-extended, but vanilla starts up fine under the same settings. And
 then there's the fact that an issue in the kernel screws up USB audio on
 major distros like Raspbian.
 
 I'm using the Satellite CCRMA distro right now with much better success.
 So far I've got various delays, a looper, and a waveshaper distortion
 running within the same patch, at 20ms latency with very few noticeable
 dropouts. Parameters are adjustable with a QuNeo MIDI controller and with
 a
 button attached to the GPIO pins.
 
 The Pi is a bit more affordable than the UDOO boards, but then again I had
 to buy a powered USB hub. Ultimately for one audio input the Raspberry Pi
 could probably serve most purposes, while the UDOO is more likely to scale
 to bigger installations.
 
 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -
 http://lists.puredata.info/listinfo/pd-list
 
 -- 
 ---
 Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing.
   Institut 17 Elektronische Musik und Akustik
   8010 Graz, Inffeldgasse 10/III
 E-Mailrit...@iem.at
 Homepage  http://iem.at/ritsch
 Mobil ++436642439369
 ---
 
 
 ___
 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] [OT] Raspberry Pi Wolfson Audio Card

2014-03-21 Thread Simon Iten

nifty!

On 21 Mar 2014, at 14:31, Winfried Ritsch rit...@iem.at wrote:

 Am Freitag, 21. März 2014, 09:04:00 schrieb Simon Iten:
 hi, nice! one question:
 
 On 18 Mar 2014, at 12:02, Winfried Ritsch rit...@iem.at wrote:
 Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega:
 Anyone wants to share their experience with the BeagleBoneBlack?
 
 Yes.
 
 Since autumn, i am trying to set up an kit hardware+software with BBB for
 computer-musicians as stomp box, works quite well, after successfully
 installed it in a long term sound installation (headless):
 
 some points short:
 
 system:
 + BBB moved to Debian since this year (good)
 + USB Audio works fine und better now with kernel = 3.12
 + Network performance works better with kernel = 3.12
 - IO support doenst use device-tree overlays anymore on kernel  3.8
 + an iio-backend for Jack2 to use the internal AD's
 
  in jack for processing sensor data in PD ;-)))  but tricky
 
 does this mean, we get a “sound” i.e adc~ in from the internal ad’s?
 
 yes, so we use PD dsp-objects to process the data. but samplerate can be 
 different.
 
 mfg
 winfried
 
 
 -- 
 ---
 Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing.
   Institut 17 Elektronische Musik und Akustik
   8010 Graz, Inffeldgasse 10/III
 E-Mail  rit...@iem.at
 Homepagehttp://iem.at/ritsch
 Mobil   ++436642439369
 ---
 
 ___
 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] [OT] Raspberry Pi Wolfson Audio Card

2014-03-19 Thread Simon Wise


On 19/03/14 23:27, Winfried Ritsch wrote:



Am Mittwoch, 19. März 2014, 00:24:25 schrieb Simon Wise:

On 18/03/14 22:02, Winfried Ritsch wrote:

Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega:

Anyone wants to share their experience with the BeagleBoneBlack?


Yes.

Since autumn, i am trying to set up an kit hardware+software with BBB for
computer-musicians as stomp box, works quite well, after successfully
installed it in a long term sound installation (headless):

some points short:

system:
   + BBB moved to Debian since this year (good)


that is very good to hear!

and the rest means they seem a good choice for embedded, the USB
implementation on the Pis really is a pain,and means you need to be
very selective about what you try to do.


it is also not very clean on others, but improved.

I have never tested a Pi, which kernel version does you use, since there have
been updates on USB since 3.12


a couple of projects last year used usb, but trying several different dongles 
found ones that worked well enough, so we left it at that. My current project is 
HDMI only (plus ethernet for setting up only), so I'm not so worried ... they 
are not here at the moment so can't check, but notes suggest 3.13 probably, I've 
not updated since last year. I'll upgrade tolatest raspbian when they are back.


Simon.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD on Raspbian

2014-03-19 Thread Simon Wise


On 19/03/14 23:29, Christian Fischer wrote:


- When opening a new Pd window (ctrl+n), it pops up so high in the bottom
left corner of the screen, that you can not see the menu anymore. Therefore
the window is not moveable or usable. Used Pd already on various PCs and OS
but this I have never experienced. What can be done?


As mentioned already openbox (the default desktop for the Pi) does the usual 
thing and Alt-drag anywhere on the window should move it where you want.


If you are using linux (or Apple) I find connecting to the Pi with ethernet and:

  ssh -X pi@192.168.1.20
replacing the IP with the actual one of course, it is usually announced on the 
console at the end of the boot process, then set your laptop ethernet to a 
compatible manual IP you are set to go.


is a very comfortable way to work, the pd windows are then on my laptop and the 
Pi does not need to run a desktop at all.


 pcmanfm 

should get you a file browser window, so you can navigate and open things in the 
familiar GUI way, if that is what you prefer.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT] Raspberry Pi Wolfson Audio Card

2014-03-18 Thread Simon Wise


On 18/03/14 22:02, Winfried Ritsch wrote:

Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega:

Anyone wants to share their experience with the BeagleBoneBlack?


Yes.

Since autumn, i am trying to set up an kit hardware+software with BBB for
computer-musicians as stomp box, works quite well, after successfully
installed it in a long term sound installation (headless):

some points short:

system:
  + BBB moved to Debian since this year (good)


that is very good to hear!

and the rest means they seem a good choice for embedded, the USB
implementation on the Pis really is a pain,and means you need to be
very selective about what you try to do.

Simon


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Tannhauser Pure Data compiler

2014-03-17 Thread Simon Wise


On 17/03/14 23:26, Ingo wrote:

I just found out about the Tannhäuser Pure Data compiler.
Does anybody know who makes it or where to get this compiler?

Thanks!
Ingo


google took me here ...

https://www.hackerleague.org/hackathons/automatic-music-hackathon/hacks/tannhauser-a-c-compiler-for-pure-data

perhaps Martin Roth is your man

https://www.hackerleague.org/users/mhroth


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT] Raspberry Pi Wolfson Audio Card

2014-03-17 Thread Simon Iten

hey dan, do you have to tell pd to use it’s own core on udoo, or does it so
automagically? has this something to do with the cpu group from your script (it
did not exist on my system)

cheers

On 13 Mar 2014, at 15:46, Dan Wilcox danomat...@gmail.com wrote:

I don't know the latency. I can try testing that at let you know, but it's
definitely good enough for what I need. It is at least lower than 20ms.
Acceptable latency for guitar is 12ms, and I think I got around 16ms out of
my old setup running on the Pentium III 500Mhz wearable.

The main deal with the UDOO, is that it's multiple cores (2 or 4 depending on
the board you buy). This way, the kernel has a core, pd has a core, and there
are 2 cores left over for other things (my HID-OSC device daemon, etc).

On Thu, Mar 13, 2014 at 4:32 AM, Pierre Massat pimas...@gmail.com wrote:
Hey Dan,

Looks like the UDOO is much better indeed from what you recently posted here.
Could you tell us what latency you're achieving ? And which version you're
using (with or w/o wifi) ?

Cheers,

Pierre.

2014-03-13 0:49 GMT+01:00 Dan Wilcox danomat...@gmail.com:
Ok for small projects, but you're not going to interface a real stage mic or
guitar easily. Would be much better if the next pi version comes with an
onboard usb controller, which is the main problem for usb audio on the
current pi. For now, the UDOO is where it's at for that.

On Mar 12, 2014, at 7:10 PM, pd-list-requ...@iem.at wrote:

From: me.grimm megr...@gmail.com
Subject: [PD] [OT] Raspberry Pi Wolfson Audio Card
Date: March 12, 2014 at 6:38:43 PM EDT
To: pd_list Listserve pd-list@iem.at

You all see this?

http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi

what do you think?

Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list

--
Dan Wilcox
danomatika.com
robotcowboy.com
___
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

2014-03-16 Thread Simon Iten

well, i play a lot in an orchestra. (doublebass) and i can assure you it’s a 
problem you don’t get used to. (and that is not just me) sure you can adapt to 
the situation but it is not ideal. let a pipe organ player play with a 
conductor and orchestra and the fun begins :-) it works but it needs a lot of 
practice and constant forward-conducting” from the conductor. i also play a 
lot with an orchestra that focuses on film-music. basically the movie is going 
on a screen and we play the filmmusic live to it. the conductor (ludwig wicki) 
has a small screen with the movie and a click on his notestand, and it’s his 
job to get the orchestra in sync with the movie. he always has to conduct way 
before the click to even get close to the right spot. so you could say the 
latency is even worse for the conductor! also i yet have to find an orchestra 
that plays highly rhythmically fast stuff in sync :-) it’s just a different way 
of making music. my education is that of a jazz-bassplayer and i had to get 
into the orchestra “groove” (or the lack of it), before i could understand why 
they play so non-precise rhythms :-) but it is the only way to stay in sync 
with each-other and the orchestra.

try a symphonic orchestra with a rock-drummer :-) he will get crazy.

and to the latencies inherent in wooden instruments:

on the doublebass (which many consider as the wooden instrument with the 
largest latency) the situation is complex. as a player you feel the strings and 
you have immediate response when you bow or pluck them. so there is no latency 
for your body. the tone that you hear as a player by the instrument is also 
there very fast (mostly the attack) but the tone that people here in the 
audience comes in much later (mostly not the attack) and depends on frequency 
and volume and if the bass is plucked or bowed.

it’s a “problem” with digital instruments or effects when the body experience 
is non existant and you have to rely solely on your ears. imho this makes a 
huge difference.

cheers

simon

so i think we should try to make latencies as small as possible, since it helps 
a lot :-)
On 16 Mar 2014, at 02:36, Simon Wise simonzw...@gmail.com wrote:

 On 15/03/14 23:03, Dan Wilcox wrote:
 I guess I don't get that since I've been playing that relative latency for
 years. How is 10-15 ms not real time? It's not even really perceivable
 unless you're doing lots of high rate short attack  decay stuff. At least as
 far as I can tell. I must be slow. :D
 
 Then again, I might be wrong. I'll probably try the hard float Debian UDOO
 image next. That might give us some room.
 
 Musicians in orchestras have been playing with, dealing with, much longer 
 latencies for centuries. An orchestra cannot all be within a metre or so of 
 each other, they are 10s of metres apart, and that is on top of the different 
 set of differences in distance to the audience. In a pit in an opera or 
 ballet it gets much worse. Any modern PA adds substantial latencies to 
 achieve a good sound in the audience, and mostly use mics and foldback in 
 other kinds of performances, and make the musicians life easier by avoiding 
 the natural latency issues of an acoustic performance.
 
 Organ players have dealt with huge latencies for as long as there have been 
 big pipe organs. Percussionists using real instruments don't get the attack 
 from their instruments till well after they initiate the note by starting to 
 move their stick toward the cymbal.
 
 Wood and metal instruments all have considerable latencies, some much more 
 than others, it is all part of playing that particular instrument. Electric 
 guitar players rely on the latency between amp and pickup (this time only a 
 few milliseconds) for their sound.
 
 Any digital instrument also has latencies. Basically it is a matter of 
 playing the instrument you are using.
 
 
 Simon
 
 ___
 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

2014-03-16 Thread Simon Wise


Any digital instrument also has latencies. Basically it is a matter of
playing the instrument you are using.


How are you measuring the latency?


with a digital instrument, in this context, it has to be from the time the 
gesture is made that controls the effect, till the effect is heard by the 
listener, and separately till the effect is heard by the musician.


so the 15 or 20 ms of DSP processing latency is only one part of that... then 
add such things as input latency (say midi or the audio input circuitry, or the 
distance from source to microphone ...) output latency (say distance from the 
reproduced sound source to the ears).


then consider the response time involved in detecting the gestures, like in the 
recent thread here (or LAU?) talking about tracking following notes played on a 
guitar and using meta data based on that.


then consider the difference between judging the effect as heard by a listener 
compared to what is heard by the musician (re timing in this case, but generally 
these is a very substantially different sounds in any wood, flesh and metal 
instruments ... what a singer hears unless they are wearing headsets is very 
different indeed to what anyone else listening hears)


then consider the time between the start of a sound and its main attack, the 
time read as the timing of the note.


as pointed out earlier in the thread much western orchestral music is not 
tightly timed rhythmically, but there are many other very old musical traditions 
that are very percussive, with very intricate timings that deal with significant 
distances between players or with instruments like big gongs or bells that have 
huge latencies built in.


in very many circumstances, now and historically, 20 ms here or there is tiny, 
as long as it is consistent ... jitter (generally) is unplayable.


in the particular circumstance of a musician whose experience is limited to 
playing with headsets or close monitors getting fed a mix of the final sound 
sent to the listener ... most of those normal latencies have been bypassed and 
the digital world has made that kind of performance much, much easier for modern 
musicians (those playing with that kind of technological assistance) ... then 15 
ms can become very significant ... best for them to avoid big gongs, plus any 
digital effect that requires taking latency into account when playing.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] udoo board sound issues

2014-03-15 Thread Simon Iten

dan, no 15 ms is in no way tolerable for live use (if you have effects that
should react in realtime) it is of course ok for delay and reverb stuff. the
latency from an amp because of cable length and stuff is totally different,
since your ear actually hears where the sound comes from and can adapt.
but for studio use for example, 15 ms on a headphone is really two attacks for
evey attack. heck even 10ms is evil :-) of course your/anyones mileage may
vary. but i only wanted the box to output delay and reverb soundscape stuff
away, so i might be good. i will add analog circuitry that mixes the dry and
effect part of the signal, so i get no (very very little) latency on the
unaffected part of the signal.

no worries as far as the script goes. i had no problems at all to follow it.
but i worked with linux a lot before. i was just suggesting, that the typical
ubuntu user would not get some of the steps in between your steps :-)

On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote:

I haven't run any latency tests, so that might be what I'm getting. If so,
it's acceptable for what I do. From what I've read, guitar - effects - amp
latencies are already closer to 20ms.

Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc
off of it yet. I'm trying to get a few things done before I head out of town
for work the next 2 weeks. I might be abel to get to it Sunday, but no
promises.

On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote:

hi dan,

tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i
start to get clicks here and there…

your script has some “errors” (missing instructions a novice would not
understand how to deal with). do you want me to post them, or do you overdo
it anyway?

thanks again

simon

On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote:

Thanks. I was just waiting to redo my website, edit the video, put the pics
together, etc etc but life and freelance work get in the way. Man, I could
use a clone right about now :P

On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote:

Also interested in the UDOO setup instructions so thank you. A bit OT but,
Dan, love your work (that onward to mars patch is awesome) thanks for
the links. I think people should post more of this sort of thing to the
list, celebrate what we make. =)

On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote:
FWIW: here's a picture of my UDOO setup inside my Mars space suit
backpack: http://www.flickr.com/photos/danomatika/13115604285/

Media of the backpack in use
https://twitter.com/danomatika/status/433273394122207232/photo/1
https://vimeo.com/86670103 (not my video, I'll put out a different edit
soon)

On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote:

I will do that later tonight when I boot the udoo and pull my run scripts
off of it. I'll post everything to GitHub so we can share resources.

On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote:

Hi Dan,

Thanks for sharing these notes. They arrived in my inbox to coincide
nicely with the delivery of my quad Udoo this morning! It would be great
to see a full writeup of your Udoo setup at some point as I think many
people will want to be doing a similar thing.

All best,

Jamie

On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote:

Heres a trim of my notes:

Enable realtime audio priority (if you haven't done it already):

sudo su -c 'echo @audio - rtprio 99
/etc/security/limits.conf'
sudo su -c 'echo @audio - memlock 25
/etc/security/limits.conf'
sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf'

I disable pulseaudio. Make sure pulseaudio does not respawn itself
(from
http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio):

echo autospawn=no ~/.pulse/client.conf

Also add the following to ~/.bash_login to kill pulse audio if it's
running on login:

# kill pulse audio if it was spawned
pulseaudio -k

I'm not looking at the udoo run script, but I'm pretty sure I'm using
the following with the US-25EX USB soudcard:

pd -rt -nogui -alsa -audiodev 5

Use pd -listdev to get the device list from alsa. I chose 5 as the
first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI
audio hardware plugin). 5 is the USB hardware alsa dev.

On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote:

without jack i should add...
On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote:

hey dan,

unfortunately i’m in switzerland :-)

would be great if you could post your setup somewhere or send the
infos! i compiled pd from source as well. i start it from console
(with -rt) and it works without problems with the builtin sound card.
maybe the cheap

Re: [PD] udoo board sound issues

2014-03-15 Thread Simon Iten

hmm,

well to me 12ms is way to much. but then again i play a lot of fast attack 
notes in up-tempo pieces :-)

thanks for your notes anyway, they helped a lot! and write back when you tried 
with the debian hardfloat image. i tried it for a short time and it was not 
very stable with pd. but then again i did not try a lot of things to fix this.

cheers
On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote:

 Check this page: 
 http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable
 
 I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms.
 
 The accumulation of a monitors and an effect or two gets you to 8ms. 
 Acceptable latency is 12 ms.
 
 Again, I haven't measured my rig or the latency of my old wearable rig, both 
 both were responsive to me, so they must e at least around 12 ms.
 
 Sorry for being unscientific about it.
 
 enohp ym morf tnes
 --
 Dan Wilcox
 danomatika.com
 robotcowboy.com
 
 On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote:
 
 dan, no 15 ms is in no way tolerable for live use (if you have effects that 
 should react in realtime) it is of course ok for delay and reverb stuff. the 
 latency from an amp because of cable length and stuff is totally different, 
 since your ear actually hears where the sound comes from and can adapt.
 but for studio use for example, 15 ms on a headphone is really two attacks 
 for evey attack. heck even 10ms is evil :-) of course your/anyones mileage 
 may vary. but i only wanted the box to output delay and reverb soundscape 
 stuff away, so i might be good. i will add analog circuitry that mixes the 
 dry and effect part of the signal, so i get no (very very little) latency on 
 the unaffected part of the signal.
 
 no worries as far as the script goes. i had no problems at all to follow it. 
 but i worked with linux a lot before. i was just suggesting, that the 
 typical ubuntu user would not get some of the steps in between your steps :-)
 
 
 On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote:
 
 I haven't run any latency tests, so that might be what I'm getting. If so, 
 it's acceptable for what I do. From what I've read, guitar - effects - 
 amp latencies are already closer to 20ms.
 
 Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc 
 off of it yet. I'm trying to get a few things done before I head out of 
 town for work the next 2 weeks. I might be abel to get to it Sunday, but no 
 promises.
 
 On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote:
 
 hi dan,
 
 tried your setup/instructions. thanks, it now works down to 15ms. at 12ms 
 i start to get clicks here and there…
 
 your script has some “errors” (missing instructions a novice would not 
 understand how to deal with). do you want me to post them, or do you 
 overdo it anyway?
 
 thanks again
 
 simon
 
 On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote:
 
 Thanks. I was just waiting to redo my website, edit the video, put the 
 pics together, etc etc but life and freelance work get in the way. Man, I 
 could use a clone right about now :P
  
 On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote:
 
 Also interested in the UDOO setup instructions so thank you. A bit OT 
 but, Dan, love your work (that onward to mars patch is awesome) thanks 
 for the links. I think people should post more of this sort of thing to 
 the list, celebrate what we make. =)
 
 
 On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com 
 wrote:
 FWIW: here's a picture of my UDOO setup inside my Mars space suit 
 backpack: http://www.flickr.com/photos/danomatika/13115604285/
 
 Media of the backpack in use 
 https://twitter.com/danomatika/status/433273394122207232/photo/1  
 https://vimeo.com/86670103 (not my video, I'll put out a different edit 
 soon)
 
 On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote:
 
 I will do that later tonight when I boot the udoo and pull my run 
 scripts off of it. I'll post everything to GitHub so we can share 
 resources.
 
 On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com 
 wrote:
 
 
 Hi Dan,
 
 Thanks for sharing these notes. They arrived in my inbox to coincide 
 nicely with the delivery of my quad Udoo this morning! It would be 
 great to see a full writeup of your Udoo setup at some point as I 
 think many people will want to be doing a similar thing.
 
 All best,
 
 Jamie
 
 
 On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote:
 
 Heres a trim of my notes:
 
 Enable realtime audio priority (if you haven't done it already):
 
   sudo su -c 'echo @audio - rtprio 99  
 /etc/security/limits.conf'
   sudo su -c 'echo @audio - memlock 25  
 /etc/security/limits.conf'
   sudo su -c 'echo @audio - nice -10  /etc/security/limits.conf'
 
 I disable pulseaudio. Make sure pulseaudio does not respawn itself 
 (from 
 http://voices.canonical.com/david.henningsson

Re: [PD] udoo board sound issues

2014-03-15 Thread Simon Wise


On 15/03/14 23:03, Dan Wilcox wrote:

I guess I don't get that since I've been playing that relative latency for
years. How is 10-15 ms not real time? It's not even really perceivable
unless you're doing lots of high rate short attack  decay stuff. At least as
far as I can tell. I must be slow. :D

Then again, I might be wrong. I'll probably try the hard float Debian UDOO
image next. That might give us some room.


Musicians in orchestras have been playing with, dealing with, much longer 
latencies for centuries. An orchestra cannot all be within a metre or so of each 
other, they are 10s of metres apart, and that is on top of the different set of 
differences in distance to the audience. In a pit in an opera or ballet it gets 
much worse. Any modern PA adds substantial latencies to achieve a good sound in 
the audience, and mostly use mics and foldback in other kinds of performances, 
and make the musicians life easier by avoiding the natural latency issues of an 
acoustic performance.


Organ players have dealt with huge latencies for as long as there have been big 
pipe organs. Percussionists using real instruments don't get the attack from 
their instruments till well after they initiate the note by starting to move 
their stick toward the cymbal.


Wood and metal instruments all have considerable latencies, some much more than 
others, it is all part of playing that particular instrument. Electric guitar 
players rely on the latency between amp and pickup (this time only a few 
milliseconds) for their sound.


Any digital instrument also has latencies. Basically it is a matter of playing 
the instrument you are using.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] udoo board sound issues

2014-03-14 Thread Simon Iten

hi dan,

tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i
start to get clicks here and there…

your script has some “errors” (missing instructions a novice would not
understand how to deal with). do you want me to post them, or do you overdo it
anyway?

thanks again

simon

On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote:

Thanks. I was just waiting to redo my website, edit the video, put the pics
together, etc etc but life and freelance work get in the way. Man, I could
use a clone right about now :P

On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote:

Also interested in the UDOO setup instructions so thank you. A bit OT but,
Dan, love your work (that onward to mars patch is awesome) thanks for the
links. I think people should post more of this sort of thing to the list,
celebrate what we make. =)

On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote:
FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack:
http://www.flickr.com/photos/danomatika/13115604285/

Media of the backpack in use
https://twitter.com/danomatika/status/433273394122207232/photo/1
https://vimeo.com/86670103 (not my video, I'll put out a different edit soon)

On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote:

I will do that later tonight when I boot the udoo and pull my run scripts
off of it. I'll post everything to GitHub so we can share resources.

On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote:

Hi Dan,

All best,

Jamie

On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote:

Heres a trim of my notes:

Enable realtime audio priority (if you haven't done it already):

sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf'
sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf'
sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf'

I disable pulseaudio. Make sure pulseaudio does not respawn itself (from
http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio):

echo autospawn=no ~/.pulse/client.conf

Also add the following to ~/.bash_login to kill pulse audio if it's
running on login:

# kill pulse audio if it was spawned
pulseaudio -k

I'm not looking at the udoo run script, but I'm pretty sure I'm using the
following with the US-25EX USB soudcard:

pd -rt -nogui -alsa -audiodev 5

Use pd -listdev to get the device list from alsa. I chose 5 as the first
4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio
hardware plugin). 5 is the USB hardware alsa dev.

On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote:

without jack i should add...
On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote:

hey dan,

unfortunately i’m in switzerland :-)

would be great if you could post your setup somewhere or send the
infos! i compiled pd from source as well. i start it from console (with
-rt) and it works without problems with the builtin sound card. maybe
the cheap card from dx.com just does not work properly with udoo.
but please post your setup.

thanks

On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote:

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

Re: [PD] using pd live (sans computer/laptop/raspberry pi)

2014-03-14 Thread Simon Wise


On 15/03/14 09:56, Charles Z Henry wrote:

On Fri, Mar 14, 2014 at 4:29 PM, Jonathan Wilkesjancs...@yahoo.com  wrote:

On 03/14/2014 03:44 PM, Dan Wilcox wrote:


Without a computer, no. Without a desktop or laptop computer, yes.



Well, maybe we could design and manufacture an enormous ASIC that runs
libpd.

-Jonathan


I appreciate the spirit of that... but man, that would be one
intimidating project.

oh to have an infinite number of monkeys programming FPGAs


... hence the attraction of building on and adding to open source projects, or 
falling back on hardware that is at least open, programmable and accessible down 
to some level. These things are to big to do alone on most scales.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] udoo board sound issues

2014-03-11 Thread Simon Iten

hey dan,

unfortunately i’m in switzerland :-)

would be great if you could post your setup somewhere or send the infos! i 
compiled pd from source as well. i start it from console (with -rt) and it 
works without problems with the builtin sound card. maybe the cheap card from 
dx.com just does not work properly with udoo.
but please post your setup.

thanks

On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote:

 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] udoo board sound issues

2014-03-11 Thread Simon Iten

without jack i should add...
On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote:

 hey dan,
 
 unfortunately i’m in switzerland :-)
 
 would be great if you could post your setup somewhere or send the infos! i 
 compiled pd from source as well. i start it from console (with -rt) and it 
 works without problems with the builtin sound card. maybe the cheap card from 
 dx.com just does not work properly with udoo.
 but please post your setup.
 
 thanks
 
 On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote:
 
 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] KMI SoftStep foot controller?

2014-03-09 Thread Simon Wise


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

[PD] udoo board sound issues

2014-03-09 Thread Simon Iten

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] udoo board sound issues

2014-03-09 Thread Simon Iten

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] KMI SoftStep foot controller?

2014-03-08 Thread Simon Wise


On 08/03/14 21:13, Alexandros Drymonitis wrote:

On Sat, Mar 8, 2014 at 2:18 AM, Simon Wisesimonzw...@gmail.com  wrote:


On 08/03/14 06:24, Jonghyun Kim wrote:


Thanks Chris for the answer! I was worried about compatibility with Pd.

How about OSC function with Pd? It's OSC works with [netsend] or
[udpsend]?



[your OSC message(
|
[packOSC]
|
[udpsend]


You'll have to explicitly import the mrpeach library, use [import mrpeach]


you are right, or use [osc/packOSC] and [iemnet/udpsend] for these ones ..





pd-osc: /usr/lib/pd/extra/osc/packOSC.pd_linux
pd-iemnet: /usr/lib/pd/extra/iemnet/udpsend.pd_linux



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] mac os9 version

2014-03-08 Thread Simon Iten

i think there was…at least according to the wiki of tcl/tk

here for example: http://wiki.tcl.tk/12987

cheers

On 26 Feb 2014, at 17:29, Miller Puckette m...@ucsd.edu wrote:

 Hi al -
 
 As far as I know there was never any version of Pd for Mac OS9 - the stumbling
 block (as I recall perhaps imperfectly) was that Tcl/Tk wasn't available for
 it.
 
 cheers
 Miller
 
 On Wed, Feb 26, 2014 at 09:21:05AM +0100, Jean-Marie Adrien wrote:
 pd vintage edition
 the true pure root thing !
 :)
 
 
 
 Le 26 févr. 2014 à 08:40, Simon Iten a écrit :
 
 too bad, thanks.
 On 25 Feb 2014, at 16:19, Peter P. p8...@aol.com wrote:
 
 * Simon Iten itensi...@gmail.com [2014-02-25 14:31]:
 is there or better was there ever a version of pure data for mac os9?
 
 the bits i find on the net seem to indicate no. but maybe a call here 
 will reveal a version. (miller?)
 
 The only thing I have ever seen was GEM for Max under OS9.
 best, P
 
 
 ___
 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] KMI SoftStep foot controller?

2014-03-07 Thread Simon Wise


On 08/03/14 06:24, Jonghyun Kim wrote:

Thanks Chris for the answer! I was worried about compatibility with Pd.

How about OSC function with Pd? It's OSC works with [netsend] or [udpsend]?


[your OSC message(
|
[packOSC]
|
[udpsend]

pd-osc: /usr/lib/pd/extra/osc/packOSC.pd_linux
pd-iemnet: /usr/lib/pd/extra/iemnet/udpsend.pd_linux


Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

[PD] mac os9 version

2014-02-25 Thread Simon Iten

is there or better was there ever a version of pure data for mac os9?

the bits i find on the net seem to indicate no. but maybe a call here will 
reveal a version. (miller?)

thanks
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] mac os9 version

2014-02-25 Thread Simon Iten

too bad, thanks.
On 25 Feb 2014, at 16:19, Peter P. p8...@aol.com wrote:

 * Simon Iten itensi...@gmail.com [2014-02-25 14:31]:
 is there or better was there ever a version of pure data for mac os9?
 
 the bits i find on the net seem to indicate no. but maybe a call here will 
 reveal a version. (miller?)
 
 The only thing I have ever seen was GEM for Max under OS9.
 best, P


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Myo armband and Pd?

2014-02-24 Thread Simon Wise


On 25/02/14 02:28, Dan Wilcox wrote:

They have an SDK, so I imagine you can get the data out and send it over
OSC. At least thats my plan when I get my dev Myo … :D


then they aren't saying go away after all ... some data is available, presumably 
already analysed which would be quick and easy to use, at least for the 
pre-defined gestures. What is the pricing?





From: Richie Cynglerglitch...@gmail.com


Ha! Excellent point, I guess it's the pirate me interested in their tech
but refusing to accept their terms. The original Kinect was packaged
similarly and cracked within what weeks if not days? Although granted that
was I think unique technology at the time.


On Sun, Feb 23, 2014 at 4:05 PM, Simon Wisesimonzw...@gmail.com  wrote:


On 23/02/14 10:47, Richie Cyngler wrote:


https://www.thalmic.com/en/myo/

Is anyone working with this? Unfortunately it's closed source and their
locking down the data stream from what I've read. I actually can't find
what sort of data it does put out other than a set of predetermined
gestures.

Anyone else curious or have more info about this device?



if they are saying go away! that loudly why would you be interested?


Simon





___
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] threads in pd, dataflow

2014-02-22 Thread Simon Wise


On 23/02/14 08:16, Jonathan Wilkes wrote:

On 02/21/2014 10:04 PM, Simon Wise wrote:

On 22/02/14 06:28, Jonathan Wilkes wrote:

On 02/21/2014 06:41 AM, Simon Wise wrote:



Something to really make pd parallel would involve treating fan-outs as
opportunities for the interpreter to launch each branch in a new thread,
implementing the inherent parallelism in the dataflow paradigm (e.g. in
the pd definition of fan-outs as being executed in undefined order). Here
the trigger object is used to force sequential execution where required,
just as it is now.


Practically speaking, it's completely different for control than for signal
domain. For signal domain fanouts there's an understanding that Pd gets
stuff done when it needs to get done. In the control domain, there's even a
philosophy of _never_ having fanouts at all. I don't know what the effect
would be of trying to auto-parallellize a signal diagram, but I'm pretty
sure trying to auto-parallellize a control diagram wouldn't make much of a
dent.


I was referring to parallelising using control fanouts only, but didn't make
that clear. 'No fanouts, always use triggers' is a very sensible policy to
avoid easily overlooked bugs when, as in pd, fanouts are just an implied
trigger with an undefined order.



[...]


Even the dsp-gui problem would be addressed by a proper dataflow
implementation if it was done well. Keeping all the gui stuff in branches
which don't have ~ objects should result in these branches being separate
threads, and well implemented these would not be allowed to block ~ branches.


To know whether a control branch interacts with the signal domain is to solve
the halting problem, no?


especially not if you allow a little syntactical help from the programmer .. as 
you note here. And note the point of this is that generally the interaction with 
the dsp does not have to be in zero logical time after it is initiated, although 
often discrete sequences of interactions must be applied together in a single 
dsp timeslice.


But also consider we are already making several simplifying assumptions and 
arbitrary (sometimes confusing) decisions as we turn the graph drawn as the pd 
patch into trees in the dsp and the message domains so that we can traverse them 
separately. If we allow fan-outs as parallel branches we change one of those 
arbitrary decisions. Instead of assigning an arbitrary order and re-writing the 
fan-out as a trigger we create new independent trees which we execute via a 
scheduler that runs in a similar way to any very basic OS scheduler ... when 
data is received for that tree it is put on a queue and executed the next time 
one of the cpu threads that pd has running is free. The usual priority queue 
stuff could be implemented regarding dsp interaction, scheduling on a basic 
level is very mundane stuff ... optimisations of all sorts at this point have 
been very well studied and can get as complex as you want. Note that we already 
break cycles in the graph, so we can indeed take each branch as a separate tree. 
There are obviously interesting complications and decisions regarding cold 
inlets, however the point of this is that by using a fan out the programmer is 
indicating that the branches may be run in parallel so cold inlets with data 
coming from outside should simply be updated whenever that data arrives ... use 
a trigger to ensure it is all part of the same tree if that is not good.




But you could have some kind of seal object that verifies the user thinks a
subpatch or canvas is 100% pure control domain. And then Pd could take that to
mean throw it in its own thread (and throw warnings/errors if it finds a message
going to a signal object, or fudging with dsp in any way).

It could look like a wax seal and always be at the top-left of the patch.


that's somewhat like the notion in functional languages of 'pure' functions 
compared to ones with side effects, in this context the dsp could be considered 
as a side effect, in the same way any output from a functional program is 
ultimately a side effect.


Each functional language deals with this differently, and they are useful in 
different contexts. Unless you get into seriously strange constructs like monads 
for output and remain a strictly pure language (lambda calculus is 
turing-complete after all) there is some syntactical way (like your wax seal) to 
flag non-pure objects. In pd the ~ naming convention already does this, and 
could be enforced by the interpreter.


In pd the dsp and message passing domains are dealt with quite separately, and 
if we wanted to treat the message passing domain as a parallelisable dataflow 
graph with its effect on the dsp as one of its outputs (a side effect in 
functional languages jargon) then there is a wealth of research and 
implementations in the functional area to look into as a comparison.


A very crucial point here is that separating gui from dsp so that gui 
calculations do not block dsp means allowing

Re: [PD] threads in pd, dataflow

2014-02-22 Thread Simon Wise


On 23/02/14 15:13, Simon Wise wrote:


Note that we already
break cycles in the graph, so we can indeed take each branch as a separate tree.


... but it is more an unroll than a break, or rather an exploration of the graph 
as a tree which may revisit the same nodes ... programmer beware of infinite 
loops, We can still create separate branches easily enough, if they overlap that 
is fine, the overlapping parts are simply included in each tree separately ... 
again programmer beware of the consequences and benefits of choosing a dataflow 
fanout rather than a trigger.


It is in the dsp domain we make choices and break cycles in the graph by passing 
the data to the next block instead to allow loops to work as expected.


Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Myo armband and Pd?

2014-02-22 Thread Simon Wise


On 23/02/14 10:47, Richie Cyngler wrote:

https://www.thalmic.com/en/myo/

Is anyone working with this? Unfortunately it's closed source and their
locking down the data stream from what I've read. I actually can't find
what sort of data it does put out other than a set of predetermined
gestures.

Anyone else curious or have more info about this device?


if they are saying go away! that loudly why would you be interested?


Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

2014-02-21 Thread Simon Wise


On 21/02/14 20:41, Charles Goyard wrote:

Hi,

just to give some example of single vs multi-threaded, and some
comparison points.

- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded
programming, even on multi-core computers. BUT they handle a much
reduced number of use cases.

- graphics chipsets are massively parallel. They handle huge amounts of
data. BUT they are hard to build, they also handle a much recuced number
of use cases, CUDA and OpenCL being a generalization.

-  (on windows) has its core single-threaded, and a lot of objects
are multi-threaded, just like pd. It suffers the same than pd: when
you get interactive with the GUI, the framerate slows down dramatically.

- whitecat (a DMX software) has its GUI that runs on OpenGL, and it's
not that efficient.

In the case of PD, maybe just a good mix of libpd and a generalization
of pd~ can improve things much.


[pd~] deals with the particular case of creating an extra dsp thread, it incurs 
overhead to do so and does not isolate the dsp from a busy patch. It is quite 
orthogonal to creating separate gui, video, audio or whatever threads.


What I guess you mean is very different .. an object to launch a distinct pd 
process within (and isolated from) the rest of a pd patch. But I am not sure how 
that would be any better or more human-readable than 2 pd instances with 
[netsend]s and a suitable script to launch them together.



Something to really make pd parallel would involve treating fan-outs as 
opportunities for the interpreter to launch each branch in a new thread, 
implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd 
definition of fan-outs as being executed in undefined order). Here the trigger 
object is used to force sequential execution where required, just as it is now.


Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

[PD] threads in pd, dataflow

2014-02-21 Thread Simon Wise


On 22/02/14 06:28, Jonathan Wilkes wrote:

On 02/21/2014 06:41 AM, Simon Wise wrote:



Something to really make pd parallel would involve treating fan-outs as
opportunities for the interpreter to launch each branch in a new thread,
implementing the inherent parallelism in the dataflow paradigm (e.g. in
the pd definition of fan-outs as being executed in undefined order). Here
the trigger object is used to force sequential execution where required,
just as it is now.


Practically speaking, it's completely different for control than for signal
domain. For signal domain fanouts there's an understanding that Pd gets
stuff done when it needs to get done. In the control domain, there's even a
philosophy of _never_ having fanouts at all. I don't know what the effect
would be of trying to auto-parallellize a signal diagram, but I'm pretty
sure trying to auto-parallellize a control diagram wouldn't make much of a
dent.


I was referring to parallelising using control fanouts only, but didn't make 
that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid 
easily overlooked bugs when, as in pd, fanouts are just an implied trigger with 
an undefined order.


Certainly in many audio patches the messaging load is small compared to the dsp,
except when you add lots of gui elements to the patch. For them parallelising
the messaging like this would indeed be pointless since a 2 thread solution with 
all the control interface in one instance of pd and all the dsp in another with 
both launched together from a script as the 'app' or using [shell] to launch the 
dsp instance makes a lot of sense ... here there is an obvious split for a 
separate thread. Since many modern computers are multicore and the dsp is only 
running on as many threads as you can devise with [pd~]s there is still plenty 
of idle cpu. I believe other languages have addressed parallelising the dsp 
graph in a more automated way but in pd this is done explicitly. For a single 
core raspberry or such the dsp thread can be given a higher priority so at least 
the audio isn't interrupted by too much interaction with the interface.


However pd is used for much more than audio. Dataflow programming is inherently
parallel but the implementation in pd comes from a single core history (well, a
single messaging core controlling a separate dsp if you go back far enough) and 
is sequential. Hence the whole trigger - fanout discussion, in pd fanouts are 
not really dataflow fanouts at all, just ill-defined triggers. The 
implementation is a sequential depth first tree traversal and triggers make that 
explicit.


Even the dsp-gui problem would be addressed by a proper dataflow 
implementation if it was done well. Keeping all the gui stuff in branches which 
don't have ~ objects should result in these branches being separate threads, and 
well implemented these would not be allowed to block ~ branches. Also splitting 
the dsp graph where ~ objects are in a distinct dataflow branch would make sense 
(there would need to be some decisions regarding exactly what distinct means in 
this context). A good implementation would follow the lead of other languages 
and wouldn't just create zillions of system threads to throw at the OS, but 
rather have a way of grouping them into a smaller number of ongoing system level 
processes. Writing and optimising this would be a huge project, and a patch run 
in a dataflow implementation would not behave in exactly the same way as it 
would in a sequential one, it couldn't.


But it is still an interesting thought experiment in the context of thinking 
about the future of pd in a world where a single thread sequential 
implementation is becoming increasingly problematic ... computers have been 
getting faster by adding cores rather than increasing clock speeds for some time 
now and that is not likely to change any time soon (quantum computing would be a 
whole new game and none of this would be relevant).


Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 10/02/14 20:27, Lorenzo Sutton wrote:

Hi Pall,

On 10/02/2014 04:45, Pall Thayer wrote:

This was a faculty grant at a US arts-focused college. I would say that
95% of students, 80% of faculty use Apple products. That really doesn't
matter though.


As you asked for feedback..
I think it does. I'm not proposing the usual (sterile) apple vs. xyz flame, but
I've noticed this mac for music thing in academia and conservatoires over here
(Italy). One thing that surprised me is the attachment to this ecosystem in the
electoacoustic music landscape, where one would expect people to experiment as
much as possible with unknown and unfamiliar tools in all directions.
What is also interesting is to understand if the use of Apple products and
software (e.g. MAX/MSP) is truly justified by creative/artistic needs or if it's
just a matter of habit/convenience (this question in a neutral way, i.e. nothing
against convenience).


15 years ago editing video was very much better on a mac than any other 
comparably priced system, this certainly helped encourage many AV people to 
learn the mac way. While they still used powerPC chips there were a lot of 
advantages to OSX over linux for working with video in pd. A few good audio apps 
have been available on mac for a lot longer than that, and macs have been pretty 
consistently easy to set up for common audio workflows ... providing you stick 
with mac friendly hardware purchases and adapt your practice those workflows. 
Much earlier Apple had got a lot of designers on board in a similar way with 
desktop publishing.


Learning to use an OS is a lot of invested time, changing OSes means a new 
investment of time. Apple understands this and has often made it quite cheap for 
educational institutions to get macs to teach on and has kept transitions 
between versions reasonably easy for the user, so a lot of students and artists 
with a bit of cash to throw at good equipment learn OSX, then go on to use it 
rather than learn another and when it comes time to pick a platform to teach on 
or recommend to others ...


Habit and already invested time, plus decent equipment and effective tools 
available without changing OS are a quite persuasive combination. Now on a 
hand-held level apple hardware is again significantly better than other stuff 
for some media and audio uses.


But you miss out on quite a lot too, and educational institutions should try to 
broaden their students' experience rather than just go with what is easiest.


Simon



I'm not sure how (much) this fits in the topic you're going to address, but I
think it's an interesting angle to take into account. And I'll be happy to share
my personal experiences further if you think it's interesting (as I guess my
email was already rather long)

Ciao,
Lorenzo.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 11/02/14 04:40, Jonathan Wilkes wrote:


Unfortunately the open source definition was designed to subtly hide the
ethical reasons for doing open source development.  The reasoning for this
was quite straightforward-- share with your neighbor doesn't attract
business dollars.  So open source advocates focus on efficiency, like the
ability to plug a 3-clause BSD-licensed library into just about any device
you want, even a device that is locked down and requires the final app to be
proprietary.


If you consider attracting business dollars actually spent on ongoing 
development of open source code then the GPL, explicitly stating its aims and 
with strict copyleft terms has been quite successful (not denying that BSD, 
Apache and similar have also, in many cases) 



If anyone wants to read a principled statement on user freedom, it's here:
http://www.gnu.org/philosophy/free-sw.html

-Jonathan


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Infinite Permissions Loop


On 11/02/14 08:24, Wesley Boynton wrote:

Hello, all! I am currently using PD-Extended in both OSX 10.8 and 10.9
environments.

On our administrator accounts, we installed X11 and everything went fine.
It launches and all is well.

However, in our primary user accounts, we're greeted with a You don't have
permission to use the application 'Pd-extended' dialog. Repeatedly. No
matter how many times I grant it permission on an always or one-off basis,
it continues to pop up the same dialog until I surrender and click OK.

This is, by the way, all despite the fact that PD and X11 are on the list
of Parental Control-Approved applications for use.

Any input would be extremely appreciated and valuable.


maybe you need Wish and/or Pd-extended and/or pd-gui or something on that safe 
list as well?


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Infinite Permissions Loop


On 11/02/14 09:43, Wesley Boynton wrote:

No such luck, unfortunately. All pd-related programs have the necessary
permissions, yet I am still stuck in the loop.


then maybe you need to turn off the offending filter all together.

Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Infinite Permissions Loop


On 11/02/14 09:43, Wesley Boynton wrote:

No such luck, unfortunately. All pd-related programs have the necessary
permissions, yet I am still stuck in the loop.


try checking the path and permissions of the executables ... maybe your 
administrator path is different, or the limited accounts can't execute when they 
do find them?


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 11/02/14 10:46, Jonathan Wilkes wrote:

On 02/10/2014 05:31 PM, Simon Wise wrote:

On 11/02/14 04:40, Jonathan Wilkes wrote:


Unfortunately the open source definition was designed to subtly hide the
ethical reasons for doing open source development. The reasoning for this
was quite straightforward-- share with your neighbor doesn't attract
business dollars. So open source advocates focus on efficiency, like the
ability to plug a 3-clause BSD-licensed library into just about any device
you want, even a device that is locked down and requires the final app to be
proprietary.


If you consider attracting business dollars actually spent on ongoing
development of open source code then the GPL, explicitly stating its aims and
with strict copyleft terms has been quite successful (not denying that BSD,
Apache and similar have also, in many cases) 


That's true, but an open source advocate could still reframe that in terms of
efficiency, cost-savings, etc., rather than freedom for the end user. An open
source advocate could even make the argument that the GPL actually gets in the
way even for the most successful projects that are licensed with it, creating
unnecessary bureaucracy and copyright sign-off requirements in what would
otherwise be a post-license digital utopia.


looking from a commercial perspective (since it is helpful to understand how 
others may think, in this case the managers of business dollars) ... one fear 
that some businesses have about open source is that they don't want to pay for 
development that can then be used by other businesses chasing the same sales 
revenue. An advantage of copyleft to them is that it is a two-way arrangement 
... another such business is obliged to give their own improvements back in 
return since selling a privatised, moderately improved version of a copyleft 
work is not allowed.




I don't buy those arguments, but the point is that if there are enough voices
framing everything in those terms then fundamental principles about user freedom
get lost. I mean, if I'd never heard much about freedom of the press then who
knows if I'd find it reasonable to prosecute journalists who receive classified
information and sell it to their publishers in the form of news. Instead, that
sounds like tyranny to me. And that's more likely due to a long line of teachers
with the integrity to explain those principles than to living in a country
licensed under the Constitution. :)


indeed, I agree that the stronger GPL position is the better one in a world 
entangled with dubious copyright laws, or even one which simply embraces trade 
secrets and a market economy. It is becoming increasingly obvious that the 
biggest software systems are beyond the capacity of even giant corporations to 
maintain alone and collaboration is the only feasible way.


Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] check mail with pd ?


On 09/02/14 16:34, Jonathan Wilkes wrote:

On 02/08/2014 11:44 PM, Simon Wise wrote:


...


It would be nice to be able to do this natively, especially since many Pd
programmers are not that familiar with procedural programming. It is certainly
practical and worthwhile to extend Pd for this but that requires some of the
things that have been long put off till later for a very very long time.
Meanwhile the Lua external provides the way to do what remains problematic
natively (as much due to policy as anything else) and anyone capable of adding
functionality to Pd will find it much much easier to use Lau than to engage in
a huge and perhaps fruitless effort to push it into Pd.


It sounds like you are rationalizing and encouraging non-development.


More pointing out the frustrations that have been experienced in the past, and 
noting that decisions about what is added to Pd core are very consistent and are 
very careful, cautious and slow in these areas in particular. As you pointed out 
adding something like a string type without introducing it to [print] is not 
good, so ... you use clumsy workarounds that don't actually allow strings in 
messages, perhaps just pointers to stings with arcane results in [print] ... or 
write a bunch of replacement core objects that recognise strings to use within 
the library such as [stringprint] etc ... or use a fork with enhanced types and 
core objects that may or may not be compatible with some eventual core string type.


It may be worth enhancing pd-l2ork this way as it has already departed 
considerably from pd, their choice has been to speed up development by bypassing 
these issues and pushing ahead without integration with core Pd, but I think 
adding strings confined to a small set of string-aware objects which remain 
otherwise compatible with vanilla the way gridflow added matrices isn't worth 
it, there is a much greater pay-off with matrices ... gridflow is a huge project 
with a very substantial library of matrix operations, while the authors long ago 
abandoned hope of their efforts being included in vanilla and develop in 
parallel. Development effort on a smaller scale is probably better spent in ways 
that will integrate with core pd, and there are plenty of those ... including 
your own solid efforts.




But it also sounds like we agree that there is nothing about boxes of text
connected with lines that makes string manipulation more difficult than lines of
text.


Absolutely, just the absence of a well defined string type that can be sent down 
those lines. Arguments advancing the addition of a string selector to Pd core 
are very worthwhile, I guess probably on pd-dev? it ultimately is a discussion 
with Miller. There was a link to something being worked on currently, earlier in 
this thread.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 10/02/14 11:53, Pall Thayer wrote:

I'm giving a presentation this week. In a way, it's a counter argument to a
recent presentation on Max/MSP. One of the things that I want to highlight
is the open sourceness of PD. libpd presents a very good argument and
I'll be highlighting a project I was involved with that produced an IOS app
that used libpd as the audio engine. Is there anything else I should be
considering besides the obvious points of open source being open source.
Concrete examples of PD's open sourceness trumping proprietary technologies?


IOs is an odd choice for talking about open source when the only way to install 
such an app in a device (without jailbreaking it or paying the developer tithe) 
is by licensing the binary closed source (on their terms) to Apple to distribute 
via their platform-monopoly app store, which will not distribute the sources or 
GPL or LGPL apps?


Certainly licenses such as libpd's BSD like one do allow reuse of the code in 
any app, open source or otherwise, but then is that use still open source???



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 10/02/14 13:36, Pall Thayer wrote:

This is where things enter into the odd world of academia. In all honesty,
I think our application for the particular grant that was available was an
outlier. The grant came with caveats. Projects were to target technology
that would likely be used by faculty and students and the resulting work
(publications or, in our case, software) would be released under open
licenses. As far as I could tell, ours was the only project that was
producing actual software. We were able to pay the Apple Dev fee for one
year from our funds but our application wasn't ready for distribution
within that time so we never submitted it to the app store and have
released the source code instead. We were never big fans of distributing it
through the app store anyway.


Well I guess the target platform is jail-broken Apples then.

Re academia ... I spent the last few years studying in an Australian university, 
maths and computing ... the students were a reasonable mix of linux, mac and 
windows users, not sure about the android/iOS split, while the staff and 
teaching had a somewhat stronger emphasis on linux and open source than the 
students. Matlab was the main exception to this.


As a target platform android certainly has a much bigger user base worldwide 
than jail-broken iOS, though the apples may be much better for some audio uses.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 10/02/14 14:45, Pall Thayer wrote:

This was a faculty grant at a US arts-focused college. I would say that 95%
of students, 80% of faculty use Apple products. That really doesn't matter
though. The project is out there. It can be ported to any platform if
people want. More than anything, it was a proof-of-concept project.

If it bothers you that this was developed as an IOS app then, by all means,
take it and turn it into an Android app.


No, it doesn't bother me (and if it is BSD licensed or similar then any 
enterprising person with a developer account could reasonably make it available 
for a dollar or so to the rest of the apple user base, and split the revenue 
with Apple, so it isn't really restricted to jail-broken devices).


Apple is a good platform for lots of audio, I've used it a lot in the past. I 
was more interested in the Apple-centric academic world your choice implied, and 
the contrast to the situation here.



Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?


On 10/02/14 14:46, Pall Thayer wrote:

https://github.com/pallthayer/gesturalmusic


It's GPL, so no enterprising re-distribution allowed.

I'll give it a try if I get time with an iOS device.


Thanks,

Simon

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is open source better?