Re: [PD] [wrap~] issues
yeah, I was gonna say something similar the problem is more likely with phasor~ whose period won't fit harmonically, this means there'll always be an offset in the next period, hence, all periods will be different and have some offset. Like cyrille pointed, you need to have a frequency that matches a number of samples so it gets repeated always the same. What you actually need is not phasor~ but a ramp generator that repeats itself at a fixed number of samples, which corresponds to the frequency you want. Or a ramp generator that gets reset with sample accuracy. See [else/accum~] and [else/ramp~] you could try a hacky way to do something like that with [fexpr~] in vanilla anyway, I'm not sure I actually follow much of your email, but I'm with cyrille here, cause wrap~ will just give you the modulo and it's not likely that it is giving you the offsets cheers 2018-04-26 17:00 GMT-03:00 cyrille henry : > hello, > I don't think your probem is with wrap~. > > if you create a phasor at 25x120 = 3000Hz, using a 44100KHz samplerate, > you will notice that all ramp have different amplitude. > This is because a ramp have 4100/3000 sample = 14.7 point for each ramp. > if you switch to 48KHz, you will have 16 sample per ramp, and all ramp > will have the same amplitude. > This also create phase isue. > > So, I gueess you should use a fps that is compatible with your samplerate. > > cheers > c > > > > > > Le 26/04/2018 à 21:23, Derek Holzer a écrit : > >> Dear Pd friends, >> >> can you help me to understand [wrap~] better? My purpose is to create a >> "video raster" (using audio signals at a high sample rate) of X and Y >> values to read luma information from [pix_data]. >> >> To do this, I have one [phasor~] creating the vertical ramp, at 25 Hz (= >> 25 frames per second). >> >> Then I require another series of ramps from 0 to 1 for the horizontal >> lines. If I want 120 lines per frame, I do it like this: >> >> [phasor~ 25] >> | >> [*~ 120] >> | >> [wrap~] >> >> This gives me 120 ramps for every one cycle of [phasor~]. So far so good. >> >> However, the ramps I get are not equal in amplitude, there are tiny >> variations which cause distortions in the raster, and which I can see when >> I plot the ramps to a array with [tabwrite~], and which I can see as a >> jagged edge if I plot my raster out on an XY oscilloscope or similar. >> >> Also, the ramps have some phase issues. 25 frames with 120 lines per >> frame works just fine, but as I adjust the frame rate or the number of >> lines per frame, the image data which I get from [pix_data] seems to >> "rotate" out of the frame and wrap around to the other side. Only multiples >> of 25/120 give me image date which is centered in the frame of the video or >> image being analyzed by [pix_data]. >> >> I would be happy to make a video of this if you like, but I wonder if >> someone with better DSP knowledge than me might have some suggestions. >> >> You can see the patch in question here: >> >> https://github.com/macumbista/vectorsynthesis/blob/master/V- >> scanprocessor-help.pd >> >> (Requires checking out entire Vector Synthesis library. Also requires PD >> >= 0.47 and Gem if you want all of it to work. Open the [V-scanprocessor] >> object to see the [phasor~] and [wrap~] configuration.) >> >> Andy Farnell suggested that the amplitude differences in the ramps may be >> a cumulative 32 bit precision error, but that would not explain the phase >> issue. I also tried using sample-rate [metro] and [line~] objects to create >> the horizontal lines but this was even less precise. >> >> Thank you for your kind attention! >> Derek >> > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li > stinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [wrap~] issues
hello, I don't think your probem is with wrap~. if you create a phasor at 25x120 = 3000Hz, using a 44100KHz samplerate, you will notice that all ramp have different amplitude. This is because a ramp have 4100/3000 sample = 14.7 point for each ramp. if you switch to 48KHz, you will have 16 sample per ramp, and all ramp will have the same amplitude. This also create phase isue. So, I gueess you should use a fps that is compatible with your samplerate. cheers c Le 26/04/2018 à 21:23, Derek Holzer a écrit : Dear Pd friends, can you help me to understand [wrap~] better? My purpose is to create a "video raster" (using audio signals at a high sample rate) of X and Y values to read luma information from [pix_data]. To do this, I have one [phasor~] creating the vertical ramp, at 25 Hz (= 25 frames per second). Then I require another series of ramps from 0 to 1 for the horizontal lines. If I want 120 lines per frame, I do it like this: [phasor~ 25] | [*~ 120] | [wrap~] This gives me 120 ramps for every one cycle of [phasor~]. So far so good. However, the ramps I get are not equal in amplitude, there are tiny variations which cause distortions in the raster, and which I can see when I plot the ramps to a array with [tabwrite~], and which I can see as a jagged edge if I plot my raster out on an XY oscilloscope or similar. Also, the ramps have some phase issues. 25 frames with 120 lines per frame works just fine, but as I adjust the frame rate or the number of lines per frame, the image data which I get from [pix_data] seems to "rotate" out of the frame and wrap around to the other side. Only multiples of 25/120 give me image date which is centered in the frame of the video or image being analyzed by [pix_data]. I would be happy to make a video of this if you like, but I wonder if someone with better DSP knowledge than me might have some suggestions. You can see the patch in question here: https://github.com/macumbista/vectorsynthesis/blob/master/V-scanprocessor-help.pd (Requires checking out entire Vector Synthesis library. Also requires PD >= 0.47 and Gem if you want all of it to work. Open the [V-scanprocessor] object to see the [phasor~] and [wrap~] configuration.) Andy Farnell suggested that the amplitude differences in the ramps may be a cumulative 32 bit precision error, but that would not explain the phase issue. I also tried using sample-rate [metro] and [line~] objects to create the horizontal lines but this was even less precise. Thank you for your kind attention! Derek ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [wrap~] issues
Dear Pd friends, can you help me to understand [wrap~] better? My purpose is to create a "video raster" (using audio signals at a high sample rate) of X and Y values to read luma information from [pix_data]. To do this, I have one [phasor~] creating the vertical ramp, at 25 Hz (= 25 frames per second). Then I require another series of ramps from 0 to 1 for the horizontal lines. If I want 120 lines per frame, I do it like this: [phasor~ 25] | [*~ 120] | [wrap~] This gives me 120 ramps for every one cycle of [phasor~]. So far so good. However, the ramps I get are not equal in amplitude, there are tiny variations which cause distortions in the raster, and which I can see when I plot the ramps to a array with [tabwrite~], and which I can see as a jagged edge if I plot my raster out on an XY oscilloscope or similar. Also, the ramps have some phase issues. 25 frames with 120 lines per frame works just fine, but as I adjust the frame rate or the number of lines per frame, the image data which I get from [pix_data] seems to "rotate" out of the frame and wrap around to the other side. Only multiples of 25/120 give me image date which is centered in the frame of the video or image being analyzed by [pix_data]. I would be happy to make a video of this if you like, but I wonder if someone with better DSP knowledge than me might have some suggestions. You can see the patch in question here: https://github.com/macumbista/vectorsynthesis/blob/master/V-scanprocessor-help.pd (Requires checking out entire Vector Synthesis library. Also requires PD >= 0.47 and Gem if you want all of it to work. Open the [V-scanprocessor] object to see the [phasor~] and [wrap~] configuration.) Andy Farnell suggested that the amplitude differences in the ramps may be a cumulative 32 bit precision error, but that would not explain the phase issue. I also tried using sample-rate [metro] and [line~] objects to create the horizontal lines but this was even less precise. Thank you for your kind attention! Derek -- derek holzer noise.art.technology http://macumbista.net ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Pd workshop in London + Meetup/show in Berlin?
Hey Pd list, Long time listener, first time caller. I'm going to be teaching a workshop in London from June 23rd to June 24th on how to build a physical sampler instrument using Pd on a Raspberry Pi. http://musichackspace.org/events/harvester-build-diy-sampler-johann-diedrick/ I'll also be giving a talk/performance on June 25th: http://musichackspace.org/events/artist-talk-johann-diedrick/ Hopefully some of you can attend! If not, I'd still love to meet up with people. I'll be in London from June 21st to around July 1st. I'm also going to be passing through Berlin around July 3rd to July 7th. I would love to meet up with other Pd'ers in Berlin if you're around! Dan Wilcox and I were talking about a potential Pd meetup/show/performance night in Berlin if people were interested and could help set up a show. Hope to meet some of you soon! Johann http://www.johanndiedrick.com/ http://aquiet.life/ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
2018-04-26 11:23 GMT-03:00 Jonathan Wilkes via Pd-list : > > > There is a student working on double-precision t_float in Purr Data as > part of GSoC this summer. > wasn't there a talk here on the pd list about double precision too? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
> On Thursday, April 26, 2018, 4:30:47 AM EDT, hans w. koch > wrote: > thanks orm and cyrille > for forcing me to acknowledge, that i´ve indeed hit the IEEE ceiling here. > i stubbornly tried to turn a blind eye to that... > i am using pd 48-1 in 64bit but to my understanding internally it stil > computes single precision. and the copy of pd-double floating around, doesn´t provide the lovely amenities of the text objects, on which most of my operations rely. There is a student working on double-precision t_float in Purr Data as part of GSoC this summer. -Jonathan > maybe its finally time to look into python… > all best hans > Am 26.04.2018 um 10:13 schrieb Orm Finnendahl > : > > Hi Hans, > > this is related to the integer precision of float numbers. In 32-bit > pd to my knowledge single-floats as specified here are used: > > https://en.wikipedia.org/wiki/IEEE_754 > > To be able to use bigger integers you can cascade more than one number > (like hours/minutes/seconds in a clock), if you want to calculate aith > these, implement abstractions for the needed mathematical functions, > using e.g. list representations of the individual numbers as in/output. > > Unfortunately this is also related to indexing into arrays limiting > the maximum address. > > Another solution could be to use 64-bit pd with double float > resolution. > > -- > Orm > > > Am Donnerstag, den 26. April 2018 um 09:57:35 Uhr (+0200) schrieb hans w. > koch: >> thanks, cyrille, >> >> but why does the computation for 5pow12 [print start] in my patch then still >> produce 2.44141e+08? >> or 5pow12 - 4pow12 work? >> (see attached) >> >> cheers hans >> > > >> >>> Am 26.04.2018 um 09:46 schrieb cyrille henry : >>> >>> hello, >>> >>> this is not a probem with until, but a problem of big number precision. >>> see attachment. >>> cheers >>> c >>> >>> >>> Le 26/04/2018 à 09:30, hans w. koch a écrit : dear miller, all for a project i am working with very high number of iterations. but it seems i´ve literally hit a ceiling with [until] for 4pow12 iterations it performs fine. but 5pow12 doesn´t. feeding it into a counter, 5pow12 produces the same result as 4pow12. attached a small patch to demonstrate. is this limitation by purpose? (i have a workaround not using [until], but wanted to make sure i didn´t overlook something) thanks hans ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >>> ___ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >> > >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
thanks orm and cyrille for forcing me to acknowledge, that i´ve indeed hit the IEEE ceiling here. i stubbornly tried to turn a blind eye to that... i am using pd 48-1 in 64bit but to my understanding internally it stil computes single precision. and the copy of pd-double floating around, doesn´t provide the lovely amenities of the text objects, on which most of my operations rely. maybe its finally time to look into python… all best hans > Am 26.04.2018 um 10:13 schrieb Orm Finnendahl > : > > Hi Hans, > > this is related to the integer precision of float numbers. In 32-bit > pd to my knowledge single-floats as specified here are used: > > https://en.wikipedia.org/wiki/IEEE_754 > > To be able to use bigger integers you can cascade more than one number > (like hours/minutes/seconds in a clock), if you want to calculate aith > these, implement abstractions for the needed mathematical functions, > using e.g. list representations of the individual numbers as in/output. > > Unfortunately this is also related to indexing into arrays limiting > the maximum address. > > Another solution could be to use 64-bit pd with double float > resolution. > > -- > Orm > > > Am Donnerstag, den 26. April 2018 um 09:57:35 Uhr (+0200) schrieb hans w. > koch: >> thanks, cyrille, >> >> but why does the computation for 5pow12 [print start] in my patch then still >> produce 2.44141e+08? >> or 5pow12 - 4pow12 work? >> (see attached) >> >> cheers hans >> > > >> >>> Am 26.04.2018 um 09:46 schrieb cyrille henry : >>> >>> hello, >>> >>> this is not a probem with until, but a problem of big number precision. >>> see attachment. >>> cheers >>> c >>> >>> >>> Le 26/04/2018 à 09:30, hans w. koch a écrit : dear miller, all for a project i am working with very high number of iterations. but it seems i´ve literally hit a ceiling with [until] for 4pow12 iterations it performs fine. but 5pow12 doesn´t. feeding it into a counter, 5pow12 produces the same result as 4pow12. attached a small patch to demonstrate. is this limitation by purpose? (i have a workaround not using [until], but wanted to make sure i didn´t overlook something) thanks hans ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >>> ___ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >> > >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
well, 5^12 is in the range of the value represented by a float number. but at this value, the precision is more than 1, so it's can be computed directlly, but not with single iteration. I guess wikipedia will explain it in more detail than what I can do in a mail. https://en.wikipedia.org/wiki/Floating-point_arithmetic more specifically : https://en.wikipedia.org/wiki/Floating-point_arithmetic#Range_of_floating-point_numbers https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems cheers c Le 26/04/2018 à 09:57, hans w. koch a écrit : thanks, cyrille, but why does the computation for 5pow12 [print start] in my patch then still produce 2.44141e+08? or 5pow12 - 4pow12 work? (see attached) cheers hans Am 26.04.2018 um 09:46 schrieb cyrille henry : hello, this is not a probem with until, but a problem of big number precision. see attachment. cheers c Le 26/04/2018 à 09:30, hans w. koch a écrit : dear miller, all for a project i am working with very high number of iterations. but it seems i´ve literally hit a ceiling with [until] for 4pow12 iterations it performs fine. but 5pow12 doesn´t. feeding it into a counter, 5pow12 produces the same result as 4pow12. attached a small patch to demonstrate. is this limitation by purpose? (i have a workaround not using [until], but wanted to make sure i didn´t overlook something) thanks hans ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
thanks, cyrille, but why does the computation for 5pow12 [print start] in my patch then still produce 2.44141e+08? or 5pow12 - 4pow12 work? (see attached) cheers hans big_number_precision2.pd Description: Binary data > Am 26.04.2018 um 09:46 schrieb cyrille henry : > > hello, > > this is not a probem with until, but a problem of big number precision. > see attachment. > cheers > c > > > Le 26/04/2018 à 09:30, hans w. koch a écrit : >> dear miller, >> all >> for a project i am working with very high number of iterations. >> but it seems i´ve literally hit a ceiling with [until] >> for 4pow12 iterations it performs fine. >> but 5pow12 doesn´t. >> feeding it into a counter, 5pow12 produces the same result as 4pow12. >> attached a small patch to demonstrate. >> is this limitation by purpose? >> (i have a workaround not using [until], but wanted to make sure i didn´t >> overlook something) >> thanks >> hans >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [until] ceiling
hello, this is not a probem with until, but a problem of big number precision. see attachment. cheers c Le 26/04/2018 à 09:30, hans w. koch a écrit : dear miller, all for a project i am working with very high number of iterations. but it seems i´ve literally hit a ceiling with [until] for 4pow12 iterations it performs fine. but 5pow12 doesn´t. feeding it into a counter, 5pow12 produces the same result as 4pow12. attached a small patch to demonstrate. is this limitation by purpose? (i have a workaround not using [until], but wanted to make sure i didn´t overlook something) thanks hans ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list #N canvas 254 106 608 443 10; #X obj 145 181 pow; #X msg 164 159 12; #X obj 145 132 t f b f; #X obj 144 215 t b f b f; #X obj 161 245 until; #X obj 144 308 f; #X obj 144 336 print end; #X msg 206 245 0; #X obj 161 274 f 0; #X obj 186 274 + 1; #X obj 238 244 print start; #X msg 144 61 4; #X msg 224 94 5; #X text 54 40 4pow12 produces same result for start + end; #X text 198 75 5pow12 doesn´t=same result as 4pow12; #X obj 462 229 pow; #X msg 481 207 12; #X msg 455 183 4; #X obj 461 256 t f f; #X obj 459 291 + 1; #X floatatom 527 297 9 0 0 0 - - -, f 9; #X floatatom 509 327 9 0 0 0 - - -, f 9; #X obj 462 146 t b b; #X obj 466 120 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 461 326 ==; #X obj 457 369 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X connect 0 0 3 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 2 1 1 0; #X connect 3 0 5 0; #X connect 3 1 4 0; #X connect 3 2 7 0; #X connect 3 3 10 0; #X connect 4 0 8 0; #X connect 5 0 6 0; #X connect 7 0 8 1; #X connect 8 0 9 0; #X connect 8 0 5 1; #X connect 9 0 8 1; #X connect 11 0 2 0; #X connect 12 0 2 0; #X connect 15 0 18 0; #X connect 16 0 15 1; #X connect 17 0 15 0; #X connect 18 0 19 0; #X connect 18 1 20 0; #X connect 18 1 24 1; #X connect 19 0 21 0; #X connect 19 0 24 0; #X connect 22 0 17 0; #X connect 22 1 16 0; #X connect 23 0 22 0; #X connect 24 0 25 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] find last error
find last error doesn't seem to be able to find the source of a bang going into a message box with arguments. no_findable_error.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [until] ceiling
dear miller, all for a project i am working with very high number of iterations. but it seems i´ve literally hit a ceiling with [until] for 4pow12 iterations it performs fine. but 5pow12 doesn´t. feeding it into a counter, 5pow12 produces the same result as 4pow12. attached a small patch to demonstrate. is this limitation by purpose? (i have a workaround not using [until], but wanted to make sure i didn´t overlook something) thanks hans until_ceiling_test.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list