Related
I'm attempting to have an X-Axis with dates. Unfortunately my data can be have a small range resulting in a date showing multiple times as an xTick. Is there a way to force it to only show "each date" exactly once as a tick.
For example, I don't want to see 12/29/2020 as a tick more than once.
Depends on your version of d3, but d3.timeDay might be what you need.
var input = [new Date(1999, 11, 31, 0),new Date(2000, 0, 1, 0), new Date(2000, 0, 1, 2), new Date(2000, 0, 1, 3), new Date(2000, 0, 2, 2), new Date(2000, 0, 2, 5)];
console.log(input);
var x = d3.scaleTime().domain(input);
var xTick = x.ticks(d3.timeDay.every(1));
console.log(xTick)
<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/5.7.0/d3.min.js"></script>
Using the excellent guide by Nadieh Bremer I'm making a stretched chord diagram.
However, with certain data inputs the rendering goes awry.
I've made a demo to demonstrate my issue here:
https://codepen.io/benmayocode/pen/MPEwdr
Specifically, in the .js file lines 269 to 281 file I have:
var respondents = 40,
emptyPerc = 0.4,
emptyStroke = Math.round(respondents*emptyPerc);
var Names = ['BEN', 'ROSE', '', '1', '2', '6', ''];
var matrix = [
[0, 0, 0, 10, 10, 0, 0] ,
[0, 0, 0, 0, 10, 10, 0] ,
[0, 0, 0, 0, 0, 0, 24] ,
[10, 0, 0, 0, 0, 0, 0] ,
[10, 10, 0, 0, 0, 0, 0] ,
[0, 10, 0, 0, 0, 0, 0] ,
[0, 0, 0, 24, 0, 0, 0] ,
];
This renders incorrectly - but if I change it to...
var respondents = 40,
emptyPerc = 0.4,
emptyStroke = Math.round(respondents*emptyPerc);
var Names = ['BEN', 'LIB', 'ROSE', '', '1', '2', '6', ''];
var matrix = [
[0, 0, 0, 0, 10, 10, 0, 0] ,
[0, 0, 0, 0, 0, 10, 0, 0] ,
[0, 0, 0, 0, 0, 10, 10, 0] ,
[0, 0, 0, 0, 0, 0, 0, 24] ,
[10, 0, 0, 0, 0, 0, 0, 0] ,
[10, 10, 10, 0, 0, 0, 0, 0] ,
[0, 0, 10, 0, 0, 0, 0, 0] ,
[0, 0, 0, 0, 24, 0, 0, 0] ,
];
Then it works great. I obviously see the difference between the two blocks of code, but why are they producing different results, and is it possible to modify my code to accommodate both examples?
If you examine the dodgy arc, you will see you can flip it into the right place by altering the sign on the transform from (50,0) to (-50,0). If you then look at the code that assigns the transform, it is
.attr("transform", function(d, i) {
d.pullOutSize = pullOutSize * ( d.startAngle + 0.01 > Math.PI ? -1 : 1);
return "translate(" + d.pullOutSize + ',' + 0 + ")";
});
with a note in the original text to say that "the 0.01 is for rounding errors". Given that the startAngle is already 3.13--i.e. very close to Pi--it looks like this is an edge case where the value fell just the wrong side of the cutoff. Changing the allowable rounding error value to 0.02 puts the arc in the correct place, or you could do something like
d.pullOutSize = pullOutSize * (
// is the start angle less than Pi?
d.startAngle + 0.01 < Math.PI ? 1 :
// if yes, is the end angle also less than Pi?
d.endAngle < Math.PI ? 1 : -1 );
to prevent edge cases like that in your dataset.
Sometimes the only way to pass precious data from CPU to GPU is by hiding it in textures.
I tried to trick SCNTechnique and simply pass [NSData dataWithBytes:length:] or a CGDataProviderRef containing my neatly prepared raw pixel data bytes, but SceneKit is smart enough to detect my sinister attempts.
But I did not give up, and found a loophole:
[_sceneView.technique setValue: UIImagePNGRepresentation(encodeInSinglePixelUIImage(pos.x, pos.y)) forKey:#"blob_pos_"];
Encoding and decoding single pixel PNGs at 60fps on a mobile device is something you can afford, on an iPhone X it just costs 2ms and keeps your palm a little bit warmer.
However I do not need any heat-generating features till november, so I was wondering if there's a cool alternative to this method.
The most efficient way I found is constructing floating point RGB TIFFs.
It's still not super fast, consuming 0.7ms on the iPhone X, but a lot faster than the PNG method.
Having a float texture also have the benefits of direct float transfer, that is, no encoding to multiple uint8 RGBA values on the CPU and reconstructing floats on the GPU.
Here's how:
NSData * tiffencode(float x, float y)
{
const uint8_t tags = 9;
const uint8_t headerlen = 8+2+tags*12+4;
const uint8_t width = 1;
const uint8_t height = 1;
const uint8_t datalen = width*height*3*4;
static uint8_t tiff[headerlen+datalen] = {
'I', 'I', 0x2a, 0, //little endian/'I'ntel
8, 0, 0, 0, //index of metadata
tags, 0,
0x00, 1, 4, 0, 1, 0, 0, 0, width, 0, 0, 0, //width
0x01, 1, 4, 0, 1, 0, 0, 0, height, 0, 0, 0, //height
0x02, 1, 3, 0, 1, 0, 0, 0, 32, 0, 0, 0, //bits per sample(s)
0x06, 1, 3, 0, 1, 0, 0, 0, 2, 0, 0, 0, //photometric interpretation: RGB
0x11, 1, 4, 0, 1, 0, 0, 0, headerlen, 0, 0, 0,//strip offset
0x15, 1, 3, 0, 1, 0, 0, 0, 3, 0, 0, 0, //samples per pixel: 3
0x16, 1, 4, 0, 1, 0, 0, 0, height, 0, 0, 0, //rows per strip: height
0x17, 1, 4, 0, 1, 0, 0, 0, datalen, 0, 0, 0, //strip byte length
0x53, 1, 3, 0, 1, 0, 0, 0, 3, 0, 0, 0, //sampleformat: float
0, 0, 0, 0, //end of metadata
//RGBRGB.. pixeldata here
};
float *rawData = tiff+headerlen;
rawData[0] = x;
rawData[1] = y;
NSData *data = [NSData dataWithBytes:&tiff length:sizeof(tiff)];
return data;
}
Useful TIFF links I used:
http://www.fileformat.info/format/tiff/corion.htm
http://paulbourke.net/dataformats/tiff/
https://www.fileformat.info/format/tiff/egff.htm
https://www.awaresystems.be/imaging/tiff/tifftags/sampleformat.html
I encountered a probem when I was using the WIC lib. And I found that I can't scale R32G32B32 images using IWICBitmapScaler... The code example shows below:
{
IWICImagingFactory* m_pWICFactory;
HRESULT hr = S_OK;
// Initialize COM
hr = CoInitialize(nullptr);
assert(SUCCEEDED(hr));
// Initialize Factory
hr = CoCreateInstance(CLSID_WICImagingFactory, nullptr, CLSCTX_INPROC_SERVER,
__uuidof(IWICImagingFactory), (void**)&m_pWICFactory);
assert(SUCCEEDED(hr));
// 4x4 R32G32B32 image
XMFLOAT3 srcImg[] = { XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1),
XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1),
XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1),
XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), XMFLOAT3(1, 1, 1), };
// 2x2 R32G32B32 image
XMFLOAT3 dstImg[4];
CComPtr<IWICBitmap> pSrcBitmap;
hr = m_pWICFactory->CreateBitmapFromMemory(4, 4, GUID_WICPixelFormat96bppRGBFloat, 4 * sizeof(XMFLOAT3),
4 * sizeof(XMFLOAT3)* 4, (BYTE*)srcImg, &pSrcBitmap);
IWICBitmapSource *pSrcBitmapSource = pSrcBitmap.p;
// scale to 2x2
CComPtr<IWICBitmapScaler> pScaler;
hr = m_pWICFactory->CreateBitmapScaler(&pScaler);
hr = pScaler->Initialize(pSrcBitmapSource, 2, 2, WICBitmapInterpolationModeFant);
pSrcBitmapSource = pScaler.p;
// copy back
WICRect rect = { 0, 0, 2, 2 };
hr = pSrcBitmapSource->CopyPixels(&rect, 2 * sizeof(XMFLOAT3), 2 * sizeof(XMFLOAT3)* 2, (BYTE*)dstImg);
}
And I just get -1.#QNAN000 in the dstImg buffer :(
I'm not sure whether I did something wrong, or the IWICBitmapScaler just don't support such format?
Another ploblem is that when I use IWICFormatConverter to convert R32G32B32A32 (i.e. 128bppRGBFloat) images to R32Gray (i.e.32bppGrayFloat)format, it always clamp the value to [0, 1], is this a desired behavior? (Why???)
(My platform: Win 8.1 64bit + VS2013)
You are incorrectly assuming that the IWICBitmapScaler always returns the data in the same pixel format as it's input. It does not. You have to call GetPixelFormat to find out how the result is going to be formatted. Also, when working with a COM API you must be checking the HRESULT for every call that returns one to catch problems.
CComPtr<IWICBitmapScaler> pScaler;
hr = m_pWICFactory->CreateBitmapScaler(&pScaler);
if ( FAILED(hr) )
...
hr = pScaler->Initialize(pSrcBitmapSource, 2, 2, ICBitmapInterpolationModeFant);
if ( FAILED(hr) )
...
pSrcBitmapSource = pScaler.p;
WICPixelFormatGUID pfScaler;
hr = scaler->GetPixelFormat( &pfScaler );
if ( FAILED(hr) )
...
// In many cases, pfScaler will not be the same GUID as your pSrcBItmapSource.
You should take a look at DirctXTex for extensive examples of using WIC.
I'm not sure whether SuperCollider can deliver moons on sticks, but I'd really like to be able to specify values in my Pbind that are interpreted in the same way as midinote or degree: i.e. converted automatically to a frequency.
So, an excerpt of such a Pbind, which produces a TB-303-style slide from one frequency to another:
b = Pbind(*[
out: 0,
instrument: \acid,
stepsPerOctave: 19,
scale: [0, 3, 5, 8, 11, 14, 17],
octave: 3,
degree: Pseq([0, \, 3, 3, 4, 4, 9, 4, 4]),
prevFreq: Pseq([\, \, 0, 3, 3, 4, 4, 9, 4]),
dur: Pseq([0.4, 0.4, 0.1, 0.1, 0.1, 0.1, 0.2, 0.1, 0.1]),
]);
...it would be super-duper if prevFreq were interpreted as containing degree values in the same way as degree.
In the absence of some kind of automatic conversion, I assume I need to do some kind of calculation within the synth itself in order to convert my values from a degree-type value to an actual frequency. I'm aware I can use foo.midicps to convert midinote-type values to a frequency, but is there a similar convenience function to convert degree-type values to a frequency (presumably also using the current scale and octave values)?
If you look at the helpfile for Event, you can see how it computes the frequency from the degree and scale:
note: #{ // note is the note in halftone steps from the root
(~degree + ~mtranspose).degreeToKey(~scale, ~stepsPerOctave);
}
midinote: #{ // midinote is the midinote (continuous intermediate values)
((~note.value + ~gtranspose + ~root) / ~stepsPerOctave + ~octave) * 12.0;
}
freq: #{
(~midinote.value + ~ctranspose).midicps * ~harmonic;
}
detunedFreq: #{ // finally sent as "freq" to the synth as a parameter, if given
~freq.value + ~detune
}
Event is an associative array and those ~variables can also be used as keys to the array (something which will hopefully become clear in a moment. It's also possible to get access to the events in a Pbind, by using a Pfunc. Let's say we want to calculate the current frequency for your Pbind:
b = Pbind(*[
out: 0,
instrument: \default,
stepsPerOctave: 19,
scale: [0, 3, 5, 8, 11, 14, 17],
octave: 3,
degree: Pseq([0, \, 3, 3, 4, 4, 9, 4, 4]),
dur: Pseq([0.4, 0.4, 0.1, 0.1, 0.1, 0.1, 0.2, 0.1, 0.1]),
foo: Pfunc({|evt|
var note, midinote, freq, detuned, result;
note = (evt[\degree] + evt[\mtranspose]).degreeToKey(evt[\scale], evt[\stepsPerOctave]);
midinote = ((note + evt[\gtranspose] + evt[\root]) / evt[\stepsPerOctave] + evt[\octave]) * 12.0;
freq = (midinote + evt[\ctranspose]).midicps * evt[\harmonic];
detuned = freq + evt[\detune];
detuned.postln;
})
]).play
Those calculations for note, midinote, freq and detuned freq are the same calculations we saw in the event helpfile. Therefore, this Pbind will now print out the frequency that you are currently playing.
What you actually want is the frequency you were previously playing, which we could figure out from your array of previous degrees. Or we could just keep track of the previous frequency in a variable. This will be a lot easier to keep track of!
(
var prev;
b = Pbind(*[
out: 0,
instrument: \default,
stepsPerOctave: 19,
scale: [0, 3, 5, 8, 11, 14, 17],
octave: 3,
degree: Pseq([0, \rest, 3, 3, 4, 4, 9, 4, 4]),
dur: Pseq([0.4, 0.4, 0.1, 0.1, 0.1, 0.1, 0.2, 0.1, 0.1]),
prevFreq: Pfunc({|evt|
var note, midinote, freq, detuned, result;
if (evt[\degree] == \rest, { detuned = \rest} , {
note = (evt[\degree] + evt[\mtranspose]).degreeToKey(evt[\scale], evt[\stepsPerOctave]);
midinote = ((note + evt[\gtranspose] + evt[\root]) / evt[\stepsPerOctave] + evt[\octave]) * 12.0;
freq = (midinote + evt[\ctranspose]).midicps * evt[\harmonic];
detuned = freq + evt[\detune];
});
//detuned.postln;
if (prev.isNil(), {
result = \rest;
} ,
{
result = prev;
});
prev = detuned
})
]).play
)