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. > > > > > > > > > > > > > > > > _______________________________________________ > > > > [email protected] mailing list > > > > UNSUBSCRIBE and account-management -> https://lists.puredata.in > > > > fo/l > > > > istinfo/pd-list > > > > > > > > > > > > _______________________________________________ > > > > [email protected] mailing list > > > > UNSUBSCRIBE and account-management -> https://lists.puredata.in > > > > fo/listinfo/pd-list > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis > tinfo/pd-list
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
