This patch takes a number and converts it to 8-bit binary. The binary is interpreted as a rhythm cell.

I want to get the number to update on the downbeat so it doesnt play anything while the number is being updated by some other process.

I'm having trouble explaining so ask away if you have any interest.

Thanks!

1.dec-bin-drummer.pd

Because $f1 is already floating point, you gain nothing by multiplying by 1000000. That might be useful in the integer domain, but floating point numbers "shift" their full precision based on the magnitude, so it's a wasted operation.

Then, dividing by 1000000 is the same as multiplying by 0.000001. These are convenient numbers in decimal, but they are repeating fractions in binary floating point (like 1/7 = 0.142847142847...) so... you thought multiplying and dividing would give you extra precision but in fact, you've just introduced extra rounding error. This probably explains why it never reaches 1. (This is a very common misconception with floating point numbers. We tend to assume that a finite decimal should also be a finite float, but computer floats are binary. Any rational number where the denominator's prime factors are 2 and 5 will be finite in decimal, but a factor of 5 in the denominator will create an infinitely repeating binary representation, so 0.1 decimal is 1.1001100110011... x 2^(-4) in binary -- it's no more precise than 0.3333 in decimal or binary.)

hjh

@jameslo just investigating further: the closest that a 32 float value can come to representing 1/44100 seems to be 0.00002267573654535226523876190185546875. However, since bit value 32 must be 1 and because the exponent of this number is 2^-16, that means that once this number is added to 1572864 as a double the fractional part can only represent
0.0000226758420467376708984375

0.0000226758420467376708984375×44100 = 0.00000463426113128662109375
as the fractional part of the first "wrapped-around" sample (I might be missing something, but something like that is probably happening)
edit: actually after testing this matches exactly with the behavior of your first patch (1st wrap-around is that # after sending "1" to the phase of phasor~ and the toggle at the same time)

@jameslo the phasor~ source was a bit confusing to me at first, it works by setting the upper 32 bits of a double (including the exponent) such that bit 32 of the double represents the "1s" place value, so all of the lower 32 bits represent the fractional part. Then after the correct phase accumulation is added, the magnitude that was added to make all lower 32 bits the fractional part is subtracted from the double in order to output just the fractional part. (and then the upper 32 bits are again set to that value, destroying the non-fractional part)
All of this is done to avoid cpu branching so it can pipeline instructions better (so instead of having to check if the phase > 1, each sample you just set bits to a certain value)

@EMR66 "I have only got a real precision, using soundfiler (although this limits me since the table only accepts whole samples as we have already spoken ..)"

This, of course, is not a limitation of soundfiler... It's a limitation of all sampled audio files.

There is no way to create an audio file, in any software, containing a fractional number of samples. Period, end of discussion.

In theory, if the frequency is a rational number, you could find the least common multiple of the wavelength and 1.0 and then have all the required sample values precalculated. But this would disallow irrational wavelengths because the LCM would be infinite. So if the desire is to support every possible real number frequency, without interpolation, it's mathematically impossible because of irrational numbers.

To handle every possible real number frequency requires interpolation. There is no way out of that.

"So, until I get that [writesf ~] record correctly, it is useless for me to use [tabread4 ~] or [tabplay ~] ..."

A fractionally sized wavetable is impossible. Literally, impossible.

Meanwhile, it's very easy to play a wavetable at an arbitrary frequency, with interpolation.

The practical solution here is to create the wavetable with a whole number of samples and interpolate in the wavetable oscillator.

hjh

Haha, thats a funny discussion If i am not wrong most of the PD objects (also the [expr] family) make use of the decimal numeral system. Though there are some objects for bit twiddling, and with [expr] you can do some bitwise operations too. Even with Python and C++ I use decimal numbers and feel quite comfortable with it (but I am not a sane programmer ). The programming languages are so nice and translate it for the computer. So the computer feels comfortable too

You've entered the fun and exciting world of floating point fractions.

0.2 is a finite decimal, but in binary, it's infinitely repeating. (1/3 in base 10 is infinitely repeating, because the denominator includes at least one prime factor, 3, which is not a prime factor of the base. Decimal fractions are finite only if the denominator has no prime factors other than 2 or 5: 5, 10, 20, 2, 4, 8 etc. are OK, 3, 7, 11, 15 are not.)

In binary, the base has only one prime factor: 2. So a fraction is exact only if the denominator is a power of two. 0.2 = 1/5 = non-power-of-two denominator.

So when you write 0.2, the floating-point number is something very close to 1/5 but not exactly. And the rounding algorithm is coming up with some other floating point number that is very close to 1/5 (but again, not exactly, because 0.2 is impossible to represent exactly in binary).

TL;DR "equals" comparisons for floating-point numbers are not necessarily safe.

You could multiply the osc~ by 100, round to 1.0, and [select 20]. Then the denominator is 1, which is a (trivial) prime factor of base 2, therefore non-repeating, therefore exact.

hjh

@s.elliot.perez it has to do with the internal representation of floating-point binary numbers: both base-10 decimal numbers have to be converted into binary floating point, and then the operation takes place. (If you looked at the numbers in binary representation the result would probably make more sense)
edit: here you can see that when you type .99 it actually gets represented as
0.9900000095367431640625
http://www.binaryconvert.com/result_float.html?decimal=048046057057

Hi guys,

I'm trying to assign a knob from my hardware controller to control the frequency of the operators on a tiny Yamaha Reface DX.

Only "problem" is that on the actual keyboard Data List parameters there is 2 different CC Number for each operator frequency level: a "coarse" and a "fine".

For example for the OSC1 of the Reface DX, the CC 89 (with value between 0-31) controls the Coarse frequency value (integer only), and the fine frequency is control by another CC (90) with value between 0 and 99 for decimal.

(gosh, i hope i'm clear enough!!).

I would like one single knob to smoothly operate the change of frequency because the audio rendering is quite bulky when only using integer value only and the charm of FM synthesis realtime morphing is then lost...

I've tried a a patch that isolates the decimal from the integer from the midi control value and send the two values to the target CC number (89 and 90) via a [ctlout] object but the result isn't perfect really. I've put some short delay for the decimal values to be send before the integer value...

Nothing very complicated for most of you i think, but i am an eternal newbie on PureData, and i could do with some help!

Thanks for any advice guys!

Regards,

Anthony

PS: here's my patch so far:

#N canvas 398 124 739 708 10;
#X floatatom 264 182 0 0 0 0 - - -;
#X floatatom 398 173 3 0 0 0 - - -;
#X floatatom 368 172 3 0 0 0 - - -;
#X obj 355 100 ctlin;
#X obj 222 287 line;
#X floatatom 210 347 5 0 0 0 - - -;
#X obj 208 382 float;
#X floatatom 269 415 5 0 0 0 - - -;
#X obj 273 376 int;
#X floatatom 211 416 5 0 0 0 - - -;
#X floatatom 208 503 5 0 0 0 - - -;
#X obj 210 450 -;
#X obj 475 491 ctlout $1;
#X obj 490 403 + 1;
#X floatatom 563 422 5 0 0 0 - - -;
#X obj 373 295 ctlout $1;
#X obj 317 498 * 99;
#X floatatom 359 503 5 0 0 0 - - -;
#X floatatom 325 314 5 0 0 0 - - -;
#X obj 300 278 int;
#X obj 366 141 / 4.09667;
#X msg 211 243 $1 400;
#X obj 328 228 delay 500;
#X connect 0 0 21 0;
#X connect 0 0 19 1;
#X connect 0 0 22 0;
#X connect 1 0 13 0;
#X connect 1 0 15 1;
#X connect 2 0 0 0;
#X connect 3 0 20 0;
#X connect 3 1 1 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 8 0;
#X connect 6 0 9 0;
#X connect 7 0 11 1;
#X connect 8 0 7 0;
#X connect 9 0 11 0;
#X connect 10 0 16 0;
#X connect 11 0 10 0;
#X connect 13 0 14 0;
#X connect 14 0 12 1;
#X connect 16 0 17 0;
#X connect 17 0 12 0;
#X connect 19 0 18 0;
#X connect 19 0 15 0;
#X connect 20 0 2 0;
#X connect 21 0 4 0;
#X connect 22 0 19 0;

The concept is rather simple. Each number between 0 and 2^16 -1, has a unique 16 bit binary representation. Now, instead of arrays and shit suppose you want a bass drum to go || : DUM . . . . . . DA DUM . DUM . . . . . : || - that would be 1000000110100000 in serial binary representation. And in decimal / float, that would be 1409.

Now suppose you have a counter going from 0 to 15 for every bar, you can use that to power up 2^n and have the binaries spit out as ones and zeores in sync.

That's what PReader.pd does. You provide the count and the seed. Preader spits out a loop of zeores and ones useful for triggering anything. All in the message domain.

PReader.pd

Now, for those of us who don't calculate back and forth between binary and decimal, I made a simple seed calculator too. You on/off the binary toggles and get the float seed.

PWriter.pd

Once you have the seeds, get rid of the Pwriter. It's just here for you to quickly get from graphic representation (binary) to decimal sead for the reader. Use messages to seeed your reader, i.e.: [1409< etc. You can have other counters control different seed messages to the same reader and so forth.

This is all very simple, but I find it extremely useful for sequencing, rather than setting up complex matrices of this and that with multiple arrays. The gordian knot and KISS and all that jazz.