@jameslo said:

@ddw_music This doesn't invalidate your larger point, but RE double precision floating point on Arduino, that reference is needs updating.

Ok.

For fun I tested c# (which agrees with SC and Pd64) and Java (which agrees with Arduino) so I'm not quite ready to join the "Arduino is wrong" team.

At the end of the day, 0.1 stored as any precision binary fraction doesn't actually equal 0.1, because the denominator of 1/10 includes a prime factor (5) that is not a prime factor of the base (2). If you ask for a decimal string for this imperfect binary representation and you ask for more (decimal) digits than are actually stored, then the trailing digits are by definition fake. They're not real.

"I find it hard to believe that there's special-purpose code to suppress..." but that is exactly what it is: the float-to-string function is supplying junk data, in a way that gives you an illusion of precision. Those zeros (the ones past the precision limit) are all fake. They don't exist in the binary number, so they must be manufactured by the "-to-string" function.

The standard C library way has the advantage of reminding the user that the trailing digits are garbage.

hjh

Hi,
how can one do ratio approximation -- fraction from number? (need it for - well tempered - scale, that should also be used on time and modulation).
Some starting patch would be great, cause I did not find anything on web.

It was once provided by Omar Misa on FB, but it got deleted.. it was small patch using prepend and based on simple logic, that u consequently setting numerator w 1-9 denominator, until it match/ is close .. cool was, that u can also set/ show deviation.. and ultimately set what deviation is acceptable or set it some categories..

Imo for musical purposes, u often don't need complex object/ object-patch/ open object (that is hard to follow without Ph.D. or having Pd as almost only instrument and not just one of sometimes over hundred plugins), but rather a simpler patch w/ explanation of logic behind it/ context (like on U-he, D16groups manuals).. so u can alter it to suit your needs.
Just my opinion.
..................................

As a tribute to Omar I've shared patch - in patch section - using his interpolation technique and update it for 3 values.

Happy patching.

Edit: Ok, I am digging to it from scratch - I am now sure, that it will be one of the least eloquent patch on the planet heavily relying on brute force....

EDIT: As I ve said *- least eloquent patch is done..CounterFin.pd

Patch simply rise denominator,. When its fraction ratio is below numeric ratio, it increases numerator +1 and start rising denom. from 1 again...
Increment/Decrements - allow set +/- 1 manually in different part, giving some overview for ratios - specily those that are close by, helping build your scale or its function(s), can serve as modulation etc.

It allows also easy set of deviation parameters, cause chances to find clear fraction from large ratio are pretty slim,

@zigmhount No, your numbers were not wrong.....Yes, I was wrong about the 51 81.

Hex to dec and back is simpler since pd 0.48 as [f] can now convert a Hex symbol to decimal ..... Hex.pd ...(8-bit decimal to Hex and back.... vanilla).
So your message was therefore correct...... but probably needs to be sent into the midi file as one list.

It does seem Musescore is not doing tempo correctly though...... the link you posted says sequencers should set 120bpm for midi files with no tempo information.
David.

8-bit Hex with keyboard entry, and for converting sysex lists....... hex2dec.zip

Pd prints floating point numbers with 6 decimal digits only, but it may be accurate below that (or it might not be).

In this specific case, 1048580 in fact requires only 6 decimal digits of precision! 1.04858 * 10^6 happens to be exact. So the number did come out right.

1048580 by my calculation needs 21 bits. In 32 bit floating point, the mantissa has 24 bits of precision (23 encoded bits + 1 implicit bit). So 1048581 and 1048579 should also be precise internally, though they will not print the 1s digit.

hjh

@lead said:

So, starting with the smallest number of decimal places and ending with the smallest number of decimal places is preferable, does that make sense?

Formally, it doesn't make sense.

The ratio for 2 semitones down is 2 ** (-2 / 12). 2 is a prime number. Raising any (positive) prime number to a fractional power results in an irrational number, with infinitely many decimal places (without ending up in a repeating sequence).

A rational number times an irrational number must be irrational. So your initial bpm value * the ratio is irrational and has infinitely many decimal places. To say "this one has 3 places" glosses over the real situation.

What you're really doing is rounding this irrational number to an arbitrary number of places. The denominator of the rounded number will be 10 ** num_places -- thus both the numerator and denominator are integers and the result is rational.

The difference (or quotient, depending how you want to measure it) between bpm * ratio and the rounded version is an error value.

And the math problem, then, is to minimize the error.

You can see it more clearly if you use a language with double precision floats, e.g., SuperCollider:

f = { |bpm, semitones = -2, places = 3|
    var r = 2 ** (semitones / 12);  // '.midiratio'
    var bpm2 = bpm * r;
    var rounded = bpm2.round(10 ** places.neg);
    // for easier comparison I'll "absolute-value" the error values
    var errorDiff = bpm2 absdif: rounded;
    var errorRatio = bpm2 / rounded;
    if(errorRatio < 1) { errorRatio = 1 / errorRatio };
    [bpm2, errorDiff, errorRatio]
};

f.value(69);  // [ 61.472011551683, 1.1551683407163e-05, 1.0000001879178 ]
f.value(59);  // [ 52.56302437028, 2.4370280016228e-05, 1.0000004636394 ]
f.value(77);  // [ 68.599201296806, 0.00020129680612513, 1.0000029343985 ]

... where, indeed, the error for 77 * r is about an order of magnitude worse.

@jameslo -- "It would be cool if you were asking https://math.stackexchange.com/questions/2438510/can-i-find-the-closest-rational-to-any-given-real-if-i-assume-that-the-denomina "

I think this is exactly what the problem reduces to -- what is the closest rational to x where the denominator = 1000. (However, the numerical methods in the thread will likely evaluate better with double precision floats. Pd prints 6 digits so it may not be clear what you're seeing.)

Actually something else... if x is the original bpm and y is the adjusted, find x and y where the error is minimized. So far the assumption is that x is an integer, but maybe the error could be even lower if they're both fractions.

hjh

@lead Sorry, still not quite understanding what you're after. Is the 77 BPM example bad because it has 4 decimal places instead of 3 like your good examples? Or are you asking "which BPMs when pitched down 2 semitones results in a BPM that has as few decimal places as possible?" It would be cool if you were asking https://math.stackexchange.com/questions/2438510/can-i-find-the-closest-rational-to-any-given-real-if-i-assume-that-the-denomina

@jameslo Two years later but hey - ratio was probably the wrong word to use, sorry. I updated the patch so it starts with whole numbers, hopefully making it easier to understand:

bpmcalculator2.pd

So good ones would be:
69 BPM gives 61.472
59 BPM gives 52.563

A bad one would be:
77 BPM gives 68.5992

It's for a studio project where I have to pitch and slow everything down 2 semitones. The starting point isn't so important, but the nearer to a whole number it is the better precision there is with keeping everything on the grid.
So, starting with the smallest number of decimal places and ending with the smallest number of decimal places is preferable, does that make sense?

A numeric representation with a finite number of digits is always an approximation, unless it's a rational number and the prime factors of the denominator are all prime factors of the base.

2022.122 can be represented accurately in decimal because the denominator is 1000, with prime factors 2 and 5 (same as base 10).

1/3 cannot be represented accurately in decimal because base 10 does not include 3 as a prime factor.

In binary floating point, base 2 has only one prime factor, so the only numbers that can be represented accurately are those whose denominator is a power of 2. 0.25 = 1/4, ok. 0.2 = 1/5, not ok.

Many people get confused because they wrote an exact decimal value and assume that it will be exact in binary. It may very well not be. 2022.122 is one of those (the denominator has three factors of 5, which binary cannot handle).

One takeaway is that == tests are often invalid for floating point. You shouldn't expect it to work, actually. It isn't weird. It's in the nature of the number system.

Similarly, there's no "right pi" and "wrong pi." Every representation of pi in a computer is wrong. The expr example merely generates a wrong pi whose wrongness matches the later operations.

Double precision pushes these issues further away so they are less visible -- but 2022.122 is a repeating binary in double just as much as in single precision. It would be good for Pd to move up to doubles for control messages though.

hjh

How to create nested For loops

Example:

for i=1 to 2
    for j=1 to 3

output would be / trying to get:
1-1
1-2
1-3
2-1
2-2
2-3

I tried this which works for the first For loop.

But it didn't work with the second For loop

nested for loop.pd

@whale-av said:

@lo94 [midiout] requires decimal....... and a sysex file will be in Hex (almost certainly)....... https://forum.pdpatchrepo.info/topic/377/sysex/32

Well... maybe.

For instance, https://mido.readthedocs.io/en/latest/syx.html has a section for "SYX files -- reading and writing," and another section for "Plain Text Format" sysex files. So, apparently, there are two ways that sysex could be written to disk -- a sequence of bytes (numeric), or as text, where each byte has been encoded as two hex digits.

"read_syx_file() determines which format the file is by looking at the first byte. It raises ValueError if file is plain text and byte is not a 2-digit hex number."

Sysex messages are supposed to be introduced by a byte F0, and terminated by F7. So you could do as this site suggests -- read one byte, and if it == 240, then treat it as a byte stream.

I have no idea whether binary or hex-coded sysex dumps are more common in the wild, only that at least one reference page implies that both exist.

It is possible that a whole sysex dump can be passed in one message (still decimal though) to [midiout], but I have no means for testing that.

I just tested this by having SuperCollider print out sysex messages -- that is, there is no need to have a MIDI device receive sysex.

MIDIClient.init;

// '5' is Pd's MIDI source in the device list
// may vary in your system
MIDIIn.connect(0, 5);

MIDIdef.sysex(\y, { |... args| args.postln });

[240 1 2 3 4 247( --> [midiout] then caused SC to print: [ Int8Array[ -16, 1, 2, 3, 4, -9 ], 8454145 ] = data block, and device UID (where -16 = 0xF0 and -9 = 0xF7, as signed 8-bit ints).

hjh