On Mon, 2016-11-07 at 17:49 +0100, patrice colet wrote:

Hello,

this is quite interesting but there is something I don't get in  attached patch, both 1 and -1 outputs the same thing, so I don't know if  I've misinterpreted something or if there is a mistake in message computing

No, you're right. The message based reference is already wrapping over. I added a [clip -32768 32767] to avoid that.

See attachment.

Roman

Le 07/11/2016 à 16:24, Roman Haefeli a écrit :

...

Hi all

In order to store audio data more efficiently in netpd presets and also to transmit live audio through OSC, I'm thinking of ways to convert an signal to a 16-bit stream represented as two signals, one for each byte, the first for MSB and the second for LSB. I already came up with a few solutions, but I'm not totally happy with any of them because they are not very efficient or/and have strange edge cases. It turns out what seems a simple task is a bit more complex and probably has quiet a few totally different solutions.

I would be interested to see with what solutions people come up with. Consider it a puzzle, a brain teaser (in case you're done writing your paper for pdcon and need some distraction).

Requirements:   * It must be done in signal domain (I was doing it in message domain     yet, but performance is obviously bad)   * Only vanilla objects are allowed.   * Input is in the range -1 to 1. Input outside this range should be     clipped and not wrapped around.   * Output is two signals, each consisting of an integer value between     0 and 255   * The two bytes represent a 16-bit _signed_ integer

You can compare your output with the message version in attached patch. If this generates interest and makes some people participate, I'll disclose my solutions after people submitted their solutions.

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list

On 11/07/2016 10:31 PM, patrice colet wrote:

with internals only, here is a workaround with expr~

but [expr~] is internal now.

fgmdsar IOhannes

Hey all

Thanks for your submissions, Cyrille and Patrice. I put my 4 versions and yours into a single patch to make it easy for comparing. It turns out I'm not clearly in favor of any of them. All work fine and none is perfect. In netpd, I went for table_lookup, however, it later turned out that CPU wise, it's not that significantly faster than the others and may not justify to use 2x4x65536 (which is a half MB!) of memory.

All of them are significantly faster than the message based version, which is not that surprising.

Cyrilly, I think the table_lookup variant is what you described in your mail.

It turns out that the difficult part is to find a way to implement an [int~] with Pd-vanilla objects. Once, you have an [int~], you have a [div~], and when you have [div~], you have a [mod~]. However, making a good [int~] is not that trivial. One can make one with [wrap~], but it exhibits the strange behaviour that it outputs '1' with '0' as input. To work-around that, I add an integer constant to the input of [wrap~] so that its input is always greater than 0. But because we're dealing with floating point numbers, the fractional part of [wrap~] output is less precise than the fractional part of its input (before constant was added), which leads to rounding errors.

uint8_table uses a pre-computed table with values from 0 to 255, which can be used as [int~] for said range.

float_rounding implements an [int~] by adding (and subsequently subtracting) a constant which is high enough so that the fractional part of the floating point number disappears. This approach might be interesting for the purpose of this exercise, but it shoudln't be used. It would break in an environment with a different floating point number format.

Cyrille Henry's approach assumes the receiving side automatically wraps negative numbers around. It turns out to be true for the object classes I'm interested in ([packOSC], [tcpclient], [netsend -b]), so his version is quite clean and because of the lack of implementing another [mod], it uses less arithmetic operations than my 'wrap' approach. It totally lacks divisions. Thumbs up!

Patrice Colet's version uses [expr~] for some parts, which is fine, I think. Somehow, for positive inputs the LSB is always higher by one compared to the others. This leads to even more severe side effect for input 1: 127 0 (should be 127 255).

Please share your opinions. I now think Cyrille's version is the best.

Roman

On Tue, 2016-11-08 at 12:06 +0100, cyrille henry wrote:

hello,

in your patch, the input signal is truncated, so strange things append near 0. I think rounding to inferior value will gives better result.

here is a version done with 2 wrap~. the result for negative number is a bit different than in your example for 2 reason :

• it round to inferior value and not truncate the input.
• it return negative int, but in uint8 : 255 and -1 are the same

number anyhow.

sometimes rounding error result in 1 being 0.9999. So i guess this patch is useless.

The other easy solution I can think of is using 2 tables with 65K point each, and reading the tables with tabread~. it is easy to populate the table with the value you want.

sorry, i don't have time to provide a patch.

cheers Cyrille

Le 07/11/2016 à 16:24, Roman Haefeli a écrit :

...

Hi all

In order to store audio data more efficiently in netpd presets and also to transmit live audio through OSC, I'm thinking of ways to convert an signal to a 16-bit stream represented as two signals, one for each byte, the first for MSB and the second for LSB. I already came up with a few solutions, but I'm not totally happy with any of them because they are not very efficient or/and have strange edge cases. It turns out what seems a simple task is a bit more complex and probably has quiet a few totally different solutions.

I would be interested to see with what solutions people come up with. Consider it a puzzle, a brain teaser (in case you're done writing your paper for pdcon and need some distraction).

Requirements:  * It must be done in signal domain (I was doing it in message domain    yet, but performance is obviously bad)  * Only vanilla objects are allowed.  * Input is in the range -1 to 1. Input outside this range should be    clipped and not wrapped around.  * Output is two signals, each consisting of an integer value between    0 and 255  * The two bytes represent a 16-bit _signed_ integer

You can compare your output with the message version in attached patch. If this generates interest and makes some people participate, I'll disclose my solutions after people submitted their solutions.

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list

On Wed, 2016-11-23 at 11:18 +0100, cyrille henry wrote:

just few comment :

• [<~] in patrice patch is not vanilla.

True (didn't notice since I had zexy loaded).

• the patch with it's 6 different and simultaneous conversions use

about 1% of my CPU. why do you need to optimise?

I don't need to specifically optimize solely for this case. However, CPU usage still is a thing with netpd and many small optimizations make a difference. Turns out that CPUs aren't getting faster significantly since a few years.

Roman

On Wed, 2016-11-23 at 11:29 +0100, cyrille henry wrote:

oh, and to answer about the why do you need a [t b b] to generate your table : it's because you bang 1st the switch~. I would bang it last. but since you've got an other switch~ in a subpatch (for the elegant upsampling), the correct order is in attachment.

I see, thanks. I had the order exactly the opposite way. I gather that with nested reblocked subpatches the deepest subpatch needs to be triggered last.

Roman

Le 23/11/2016 à 10:59, Roman Haefeli a écrit :

...

Hey all

Thanks for your submissions, Cyrille and Patrice. I put my 4 versions and yours into a single patch to make it easy for comparing. It turns out I'm not clearly in favor of any of them. All work fine and none is perfect. In netpd, I went for table_lookup, however, it later turned out that CPU wise, it's not that significantly faster than the others and may not justify to use 2x4x65536 (which is a half MB!) of memory.

All of them are significantly faster than the message based version, which is not that surprising.

Cyrilly, I think the table_lookup variant is what you described in your mail.

It turns out that the difficult part is to find a way to implement an [int~] with Pd-vanilla objects. Once, you have an [int~], you have a [div~], and when you have [div~], you have a [mod~]. However, making a good [int~] is not that trivial. One can make one with [wrap~], but it exhibits the strange behaviour that it outputs '1' with '0' as input. To work-around that, I add an integer constant to the input of [wrap~] so that its input is always greater than 0. But because we're dealing with floating point numbers, the fractional part of [wrap~] output is less precise than the fractional part of its input (before constant was added), which leads to rounding errors.

uint8_table uses a pre-computed table with values from 0 to 255, which can be used as [int~] for said range.

float_rounding implements an [int~] by adding (and subsequently subtracting) a constant which is high enough so that the fractional part of the floating point number disappears. This approach might be interesting for the purpose of this exercise, but it shoudln't be used. It would break in an environment with a different floating point number format.

Cyrille Henry's approach assumes the receiving side automatically wraps negative numbers around. It turns out to be true for the object classes I'm interested in ([packOSC], [tcpclient], [netsend -b]), so his version is quite clean and because of the lack of implementing another [mod], it uses less arithmetic operations than my 'wrap' approach. It totally lacks divisions. Thumbs up!

Patrice Colet's version uses [expr~] for some parts, which is fine, I think. Somehow, for positive inputs the LSB is always higher by one compared to the others. This leads to even more severe side effect for input 1: 127 0 (should be 127 255).

Please share your opinions. I now think Cyrille's version is the best.

Roman

On Tue, 2016-11-08 at 12:06 +0100, cyrille henry wrote:

...

hello,

in your patch, the input signal is truncated, so strange things append near 0. I think rounding to inferior value will gives better result.

here is a version done with 2 wrap~. the result for negative number is a bit different than in your example for 2 reason :

• it round to inferior value and not truncate the input.
• it return negative int, but in uint8 : 255 and -1 are the same

number anyhow.

sometimes rounding error result in 1 being 0.9999. So i guess this patch is useless.

The other easy solution I can think of is using 2 tables with 65K point each, and reading the tables with tabread~. it is easy to populate the table with the value you want.

sorry, i don't have time to provide a patch.

cheers Cyrille

Le 07/11/2016 à 16:24, Roman Haefeli a écrit :

...

Hi all

In order to store audio data more efficiently in netpd presets and also to transmit live audio through OSC, I'm thinking of ways to convert an signal to a 16-bit stream represented as two signals, one for each byte, the first for MSB and the second for LSB. I already came up with a few solutions, but I'm not totally happy with any of them because they are not very efficient or/and have strange edge cases. It turns out what seems a simple task is a bit more complex and probably has quiet a few totally different solutions.

I would be interested to see with what solutions people come up with. Consider it a puzzle, a brain teaser (in case you're done writing your paper for pdcon and need some distraction).

Requirements:  * It must be done in signal domain (I was doing it in message domain    yet, but performance is obviously bad)  * Only vanilla objects are allowed.  * Input is in the range -1 to 1. Input outside this range should be    clipped and not wrapped around.  * Output is two signals, each consisting of an integer value between    0 and 255  * The two bytes represent a 16-bit _signed_ integer

You can compare your output with the message version in attached patch. If this generates interest and makes some people participate, I'll disclose my solutions after people submitted their solutions.

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.in fo/l istinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.in fo/listinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list