OSChook error. oscparse: unknown tag 'h' (104)
Per https://opensoundcontrol.stanford.edu/spec-1_0.html , 'h' is the type tag for 64 bit big-endian two’s complement integer. Probably [oscparse] simply doesn't implement it.
... in which case, try mrpeach. (Though, come to think of it, what would Pd do with a 64-bit integer? It can't be squished down into a 32-bit float. Even a 64-bit float would be able to keep only 53 bits' worth of precision, or 54 if you count the sign bit. So it would be helpful to know what data the app is sending in this format.)
hjh
What (if any) version of PD Open Sound Control (OSC) supports 64-bit numbers?
There's an experimental 64-bit version of Pd
This is really orthogonal to 64-bit OSC timetags. This version just uses 64-bit floats as the underlying type for float atoms and samples. It does not magically implement the missing OSC typetags. Also, let's please call this the "double-precision" version, as "64-bit" typically refers to the CPU architecture.
Actually, there is no reason why Pd's [oscformat]
and [oscparse]
could not support the h
(= int64) and d
(= float64) typetags for sending/parsing OSC message. Of course, single-precision Pd would need to round the values down to 32-bit floats, but double-precision Pd could keep the precision (at least for 64-bit floats; 64-bit integers may still lose some lower bits when converted to 64-bit float atoms).
90-second limit on audio buffers?
@seb-harmonik.ar said:
internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.
Must be.
Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.
SC UGens are free to use doubles internally, but the interconnection buffers are single precision, so we do run into trouble at that 24 bit mantissa limit.
I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit...
I think it's a bit more than that. When the phase increment is 1 buffer frame per output sample, then there is no inaccuracy at all, because integer values are never repeating fractions, and up to 2^24, are not subject to truncation (2^24 - 1 is ok but 2^24 + 1 is not). It avoids the problem of scaling inaccuracy by not scaling at all -- which may be what you meant, just being clear about it. rpole's similar results are because my example is integrating a stream of 1's, so everything is integer valued.
It struck me interesting how the correct observation "buffer playback by scaling phasor~ runs into trouble quickly" slips into a generalized caution. Agreed that the phasor~ way isn't sufficient for many use cases; perhaps a new object would be useful, or, the accumulator technique would be useful as a more prominent part of pd culture.
hjh
90-second limit on audio buffers?
internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.
Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.. https://github.com/supercollider/supercollider/blob/137cb4cd56f5bdf4484c9ad6761d4724dc8d7818/server/plugins/TriggerUGens.cpp#L134
I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit whereas when using phasor~ it is output as 32-bit and also scaled from range 0-1 as a 32-bit by multiplying by buffer size
If there were a Phasor equivalent in pd it might be comparable..
(and that also seems to be the case if [rpole~]
gives similar results)
[vline~]
should work as well
Receiving 14-bit MIDI CC messages.
@ddw_music Beware all....... Yamaha send MSB and LSB in reverse order to everyone else.. see below for how to deal with that....
Also most manufacturers... for low values.... when only 7bits are required they output just the LSB.
You might already be aware of all that.
A byte has 8 bits, bit 0 to bit 7 (0 = cleared or 1 = set).
A MIDI status byte – i.e. what sort of MIDI message it is - always has bit 7 set
A MIDI data byte – i.e. what value - always has bit 7 cleared.
Therefore a data byte can only use the lower 7 bits to determine its value
0 to 127 ($7F) or 0111 1111 (bit 0 is the rightmost 1, bit 7 is 0)
To get a value greater than 127 we join two data bytes together. The rightmost 7 bits from each byte gives a 14 bit number
0111 1111 and 0111 1111 becomes 0011 1111 1111 1111 the top 2 bits (bit14 and bit15) are ignored
So the 14bit number range is0 to 16383 ($3FFF) or 0011 1111 1111 1111(this is just 14 data bits in a 16 bit number – the 2 top (leftmost) bits are always 0).
The two bytes that make up the 14 bit number are what MIDI calls a course adjustment and a fine adjustment.
The byte that does a course adjustment is called the Most Significant Byte (MSB) and the fine adjuster is called the Least Significant Byte (LSB).
Also NRPN can be very slow over midi when data rates are high...... and SYSEX will be much faster.
David.
P.S. I have a lot of old docs and software from the decade before last..... midi stuff.... that has disappeared from the web...... stuff that can change encoder resolution on Behringer BCF units for example, which is not available in the Behringer software or on the hardware.
Just ask.
Receiving 14-bit MIDI CC messages.
That [t b f] will give spurious values, though, I wouldn't.
[buddy] from cyclone is designed for this case.
Or vanilla:
23-0727-pd-14-bit-midi-vanilla.pd
EDIT: Replaced the last image and pd patch upload -- previously I used [+] in the buddy logic but it really must be bitwise-or.
hjh
warble tones considered harmful?
@ddw_music said:
I also admit some ignorance here and I suspect we are going to enter the clashing worlds of digital and analog, the brutal absolutes of the digital world are alien to my analog sensibilities where we can just ballpark it and generally get closer to the real world result than the math would get us and get there in a fraction of the time (talking circuit design and the like here, not physics). And like you I am not 100% certain what is meant by warble tone, I based my answer on what was likely to kill a speaker which assumes the salesman that scolded jameslo had a clue.
One of the sines is too low to be audible
How does the amplifier and speaker know what is audible? We can hear the tremolo effect of this beating so the speaker has to be moving at that rate and those tones we hear as tones are moving on top of that beating, the 4hz looks sort of like a carrier frequency as far as the speaker is concerned. Beat frequencies can cause large extension to the point of over extension (voice coil pops out of the gap) and sustained beat frequencies of these low frequency sorts can cause heat to build up in coil faster than it can dissipate it leading to warping. Getting a good strong beat frequency going and feeding it into a speaker with decent extension will let you see that beat frequency, change one oscillator to half or double the frequency of the other so there is no beating and it will barely move, just a nice even tremble. This of course is dependent on the frequency characteristics of the entire setup but generally if you get one of those beat frequencies going that you can feel than you will be able to see it in the speakers movement.
Beating can be produced from any waves, not just sines.
PlugData / Camomile "position" messages: What are these numbers?
@ddw_music said:
To work with the scheduler, I need to be able to anticipate the next tick time. The difference between successive beats (first number) appears to be consistently 0.04644012, and this seems to be proportional to tempo (160 bpm gets 0.061919212341).
Different machine, different DAW, I get half that (0.02322). So I guess this is a number of beats (because it increments by a larger amount at higher tempo = more beats per unit of time) and it must be updating once per audio callback, and the soundcards must be configured differently.
It's tricky: you can't just tick beats because you never get an exact whole beat (unlike abl_link~ which does provide a "step" output), and the beat interval between successive "playhead" ticks may change, and you won't detect that change until after you've already ticked the current one. So there will always be some sync inaccuracy AFAICS, probably minimal at constant tempo.
I guess nobody cares much about interoperability but I feel like I'm this close to a good way...
hjh
Is there a scheduler-queue external?
@ddw_music you could also use a combination of external and internal. keep track of the current beat #. If the next item in the queue is >= the beat # for the next tick then wait for the next tick. Otherwise, [delay]
by the difference to the next beat value in the queue and then output the message (and increment the current beat #).
for example if you get 16th note (0.25 beat) ticks and are on beat # 0.5 with
elements in queue: 0.6 "something", 0.7 "something else", 0.8 "third thing":
-> check if beat value for next element ("something") >= (0.5 + 0.25) = 0.75 -> no
-> delay by (0.6 - 0.5) = 0.1 beats and then pop "something"
-> increment beat # to 0.6
-> check if beat value for next element ("something else") >= 0.75 again -> no
-> delay by (0.7 - 0.6) = 0.1 beats and then pop "something else"
-> increment beat # to 0.7
-> check if beat value for next element ("third thing") >= 0.75 -> yes
-> wait for next tick and then increment beat # to 0.75
-> check if beat value for that element ("third thing") >= 1 -> no
-> delay by (0.8 - 0.75) = 0.05 beats and then pop "third thing"
etc.
New version of Pd - [pink~] and [freeverb~] disappeared
@oleathlobhair They are both externals....... not a part of the Pd package.
If you have gone from a 32-bit version of Pd to a 64-bit version then externals cannot be carried over into the new version...... as they simply will not work.
You will have to install 64-bit versions in the 64-bit Pd "extra" folder.
You will still have the 32-bit versions in your old 32-bit Pd in its "extra" folder...... they will not be overwritten.
That is quite simple though.
Open (in your new Pd) in the Pd top menu "Help"... "Find Externals" and type e.g. freeverb~
You will be given a list of packages (libraries) that contain that object and you can install the one you choose.
David.