Re: [PD] [wrap~] issues

2018-04-26 Thread Alexandre Torres Porres 
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

2018-04-26 Thread 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/listinfo/pd-list

[PD] [wrap~] issues

2018-04-26 Thread Derek Holzer 

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?

2018-04-26 Thread Johann Diedrick 
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 Thread Alexandre Torres Porres 
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

2018-04-26 Thread Jonathan Wilkes via Pd-list 
 > 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

2018-04-26 Thread cyrille henry 

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

2018-04-26 Thread 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



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

2018-04-26 Thread 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

#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

2018-04-26 Thread Matt Davey 
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

2018-04-26 Thread hans w. koch 
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