Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
Also, I am getting an error message in the Pd console upon creating a single pix_sig2pix~ object in an empty patch: GEM: Someone sent a bogus pointer to copy2Image and am curious if this red error message is related to the above problem...
Thank you for all ideas and advice! Peter
Le 24/10/2017 à 13:18, Peter P. a écrit :
Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
8 bits / channels
so resolution is 1/256 = 0.0039...
You can code MSB in Red, and LSB in green is you want 16 bits...
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
I don't see any flicker in your patch. (linux / intel GPU)
cheers C
Also, I am getting an error message in the Pd console upon creating a single pix_sig2pix~ object in an empty patch: GEM: Someone sent a bogus pointer to copy2Image and am curious if this red error message is related to the above problem...
Thank you for all ideas and advice! Peter
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Le 24/10/2017 à 13:18, Peter P. a écrit :
Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
8 bits / channels
so resolution is 1/256 = 0.0039...
You can code MSB in Red, and LSB in green is you want 16 bits...
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
I don't see any flicker in your patch. (linux / intel GPU)
Thank you Cyrille for this helpful information!
Jack, I am on Debian GNU/Linux with an onboard Intel graphics controller (i915 variant).
P
Hello,
Le 24/10/2017 à 11:24, Peter P. a écrit :
- cyrille henry ch@chnry.net [2017-10-24 13:32]:
Le 24/10/2017 à 13:18, Peter P. a écrit :
Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
8 bits / channels
so resolution is 1/256 = 0.0039...
You can code MSB in Red, and LSB in green is you want 16 bits...
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
I don't see any flicker in your patch. (linux / intel GPU)
Thank you Cyrille for this helpful information!
Jack, I am on Debian GNU/Linux with an onboard Intel graphics controller (i915 variant).
OK, i guessed you were on nvidia because if you are not sync to vblank, you often get a line diagonaly separating two pictures. It is called "screen tearing". I didn't test your patch yet... ++
Jack
P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
OK, I tested your patch and on my side, i get a solid red square. No flicker. ++
Jack
Le 24/10/2017 à 18:33, Jack a écrit :
Hello,
Le 24/10/2017 à 11:24, Peter P. a écrit :
- cyrille henry ch@chnry.net [2017-10-24 13:32]:
Le 24/10/2017 à 13:18, Peter P. a écrit :
Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
8 bits / channels
so resolution is 1/256 = 0.0039...
You can code MSB in Red, and LSB in green is you want 16 bits...
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
I don't see any flicker in your patch. (linux / intel GPU)
Thank you Cyrille for this helpful information!
Jack, I am on Debian GNU/Linux with an onboard Intel graphics controller (i915 variant).
OK, i guessed you were on nvidia because if you are not sync to vblank, you often get a line diagonaly separating two pictures. It is called "screen tearing". I didn't test your patch yet... ++
Jack
P
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
By red I mean a RGB value (0.5, 0, 0). ++
Jack
Le 24/10/2017 à 19:07, Jack a écrit :
OK, I tested your patch and on my side, i get a solid red square. No flicker. ++
Jack
Le 24/10/2017 à 18:33, Jack a écrit :
Hello,
Le 24/10/2017 à 11:24, Peter P. a écrit :
- cyrille henry ch@chnry.net [2017-10-24 13:32]:
Le 24/10/2017 à 13:18, Peter P. a écrit :
Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
8 bits / channels
so resolution is 1/256 = 0.0039...
You can code MSB in Red, and LSB in green is you want 16 bits...
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
I don't see any flicker in your patch. (linux / intel GPU)
Thank you Cyrille for this helpful information!
Jack, I am on Debian GNU/Linux with an onboard Intel graphics controller (i915 variant).
OK, i guessed you were on nvidia because if you are not sync to vblank, you often get a line diagonaly separating two pictures. It is called "screen tearing". I didn't test your patch yet... ++
Jack
P
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
[...]
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
I don't see any flicker in your patch. (linux / intel GPU)
Thank you Cyrille for this helpful information!
Jack, I am on Debian GNU/Linux with an onboard Intel graphics controller (i915 variant).
OK, i guessed you were on nvidia because if you are not sync to vblank, you often get a line diagonaly separating two pictures. It is called "screen tearing".
Thank you, in my case it is not a missing sync to vblanc but a more drastic flicker. Also thanks for testing my patch and getting back to me on that, it is much appreciated!
P
Do you have a laptop with a discrete GPU (nvidia) and an integrated GPU (intel) ? Which one do you use ? Have you tried with the other GPU ? What is your OS ? Seems you are using the NVidia on a Linux (if i am right) ? ++
Jack
Le 24/10/2017 à 07:18, Peter P. a écrit :
Hi list,
I am trying to convert an audio signal to pixel data using pix_sig2pix~ and then back to audio data using pix_pix2sig~ without further manipulations. Please see attached patch.
I do scale the audio signal from -1 to 1 to lie in a range compliant to pixel data, which I assume to be 0 to 1.
Not having connected an input to the subpatch, this signal will hence be 0.5 and will display in the red color channel.
Converting that red channel back to audio signals and doing the opposite scaling operation, I am getting a 51dB constant signal at the output even without having attached a signal to the input of pix_sig2pix~. Checking with a snapshot~ object indicates a constant signal of 0.003921
I assume this to be due to limited resolution numbers in the pixel data and wonder what their resolution is?
Then I texture the pixel data onto a rectangle. This rectangle does flicker and flip diagonally from time to time and I wonder if it is an error on my machine only and where it could come from.
Also, I am getting an error message in the Pd console upon creating a single pix_sig2pix~ object in an empty patch: GEM: Someone sent a bogus pointer to copy2Image and am curious if this red error message is related to the above problem...
Thank you for all ideas and advice! Peter
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list