I want to draw the pitch track based on a Text-Grid annotated sound object.
I call the TextGrid and the Pitch file and use the following code to get the
textgrid and the pitch extracted.
Read from file... 'textDir$'\'baseFile$'.TextGrid
Read from file... 'soundDir$'\'baseFile$'.wav
To Pitch (ac): 0.005, 75, 15, "no", 0.1, 0.45, 0.01, 0.35, 0.14, 600
Times
Font size... 20
Black
select TextGrid 'baseFile$'
plus Pitch 'baseFile$'
Draw separately (semitones): 0, 0, -5, 15, "yes", "yes", "yes"
That works fine. However, I want to change the thickness of the pitch curve and
also possible the color.
Any idea how that can be done?
In the Praat Picture window, go to the Pen menu. Select your line width, and colour from the list. Then run the Draw command again.
Related
Below COLOR/INDEX are information that I want to use for heatmap color palette
COLOR= ['#36abdf','#84d9a3','#f4d646','#e86000','#ff0000','#671b1b']
INDEX= [0, 0.001, 10, 25, 50, 75, 1]
I'm trying to make some HEATMAP which havs continuous (Gradient) color value.
My original Intension was that
Set Blue color ('#36abdf') for only '0' vlaue,
If value is bigger than 0, must start with green color('#84d9a3') and be gradually changed within color set for bigger value.
I found some code that can make LinearColormap through branca.colormap
cmap = b_cm.LinearColormap(colors=['#36abdf','#84d9a3','#f4d646','#e86000','#ff0000','#671b1b'], index=[0,0.001,25,50,75,90],vmin=0,vmax=100)
but it seems that I cannot use LinearColormap for color palette in seaborn/matplotlib heatmap
please let me introduce code that make color palette that I want.
I will be so appreciate if you let me know.
thx!!
Repeatedly drawing a semi-opaque black rectangle over the entire canvas before each animation frame is an easy way to get an afterimage effect for moving shapes and it gives me exactly what I need - up to a point. With too slow a fade it doesn't fade all the way to black. Here's an example:
var canv = document.createElement('canvas');
document.body.appendChild(canv);
var ctx = canv.getContext('2d');
ctx.fillStyle = 'rgba(0, 0, 0, 1)';
ctx.fillRect(0, 0, 100, 100);
ctx.fillStyle = 'rgba(255, 255, 255, 1)';
ctx.fillRect(20, 20, 60, 60);
window.requestAnimationFrame(doFade);
function doFade() {
// Never fades away completely
ctx.fillStyle = 'rgba(0, 0, 0, 0.02)';
ctx.fillRect(20, 20, 60, 60);
window.requestAnimationFrame(doFade);
}
jsfiddle
This looks to me like a numeric precision problem - you can't expect the canvas to keep floating point pixel values around - but I'm not sure how to get around this.
I tried reading the image into a pattern, blanking the canvas, and then filling with the pattern at lower opacity in the hope that I could make rounding error work in my favor, but it seems to have the same result.
Short of reading out the image data and setting to black any pixels below a certain threshold, which would be prohibitively slow, I'm running out of ideas and could use some suggestions.
Thanks!
I thought I'd share my solution for the benefit of anyone else who might run into this problem. I was hoping to avoid doing any pixel-level manipulation, but beyond a certain threshold it's just not possible with the built-in canvas operations because the underlying bitmap is only 8 bits per channel and small fades will work out to less than one least significant bit and won't have any effect on the image data.
My solution was to create an array representing the age of each pixel. After each frame is drawn, I scan the imageData array, looking only at the alpha channel. If the alpha is 255 I know the pixel has just been written, so I set the age to 0 and set the alpha to 254. For any other non-zero alpha values, I increment the pixel age and then set the new alpha based on the pixel age.
The mapping of pixel age to alpha value is done with a lookup table that's populated when the fade rate is set. This lets me use whatever decay curve I want without extra math during the rendering loop.
The CPU utilization is a bit higher, but it's not too much of a performance hit and it can do smooth fades over several seconds and always fades entirely to black eventually.
Background
I'm working a legacy MFC application which uses GDI draw its content.
I need to draw rounded rectangles where each corner has a (potentially) different radius.
This means that I can no longer use RoundRect and have to roll my own using ArcTo.
I'm using SetWindowExtEx, SetWindowOrgEx, SetViewportExtEx and SetViewportOrgExt to implement zooming.
This works fine in most situations.
Problem
On certain zoom levels, my code fails to construct a proper path of the outline of the roundrect.
The following screenshots is of my RoundRect code used to create a path, then used to clip a bigger rectangle (to get an idea of it's shape).
The clipping region created by this path is sometimes missing a corner, clips everything (two missing corners?) or clips nothing.
My guess is that due to rounding errors, the arcs are too small, and is skipped alltogether by GDI.
I find this hard to believe though since it is working correctly for smaller zoom factors than the ones pictured here.
Working correctly:
Missing a corner:
The Code
I have tried to reduce the code needed to reproduce it and have ended up with the following. Note that the number in the screenshots is the value of zoomFactor, the only variable.
You should be able to paste this code into the OnPaint function of a newly created Win32 application project and manually declare zoomFactor a constant.
SetMapMode(hdc, MM_ISOTROPIC);
SetWindowOrgEx(hdc, 0, 40, nullptr);
SetWindowExtEx(hdc, 8000, 6000, nullptr);
SetViewportOrgEx(hdc, 16, 56, nullptr);
SetViewportExtEx(hdc, 16 + (396)*zoomFactor/1000,
48 + (279)*zoomFactor/1000, nullptr);
BeginPath(hdc);
MoveToEx(hdc, 70, 1250, nullptr);
ArcTo(hdc,
50, 1250, 90, 1290,
70, 1250,
50, 1270);
ArcTo(hdc,
50, 2311, 90, 2351,
50, 2331,
70, 2351);
ArcTo(hdc,
1068, 2311, 1108, 2351,
1088, 2351,
1108, 2331);
ArcTo(hdc,
1068, 1250, 1108, 1290,
1108, 1270,
1088, 1250);
CloseFigure(hdc);
EndPath(hdc);
SelectClipPath(hdc, RGN_AND);
HBRUSH br = CreateSolidBrush(RGB(255,0,255));
const RECT r = {0, 0, 8000, 6000};
FillRect(hdc, &r, br);
Here is a simpler bit of code to illustrate the problem:
const int r = 20;
MoveToEx(hdc, 200, 100, 0);
BOOL b = ArcTo(hdc,
100 + 2 * r, 100,
100, 100 + 2 * r,
100 + r, 100,
100, 100 + r);
POINT p;
GetCurrentPositionEx(hdc, &p);
This draws a single corner of radius r. This works fine for non-zero values of r and the position p is correctly updated to match the end of the arc: (100, 100+r), give or take a pixel.
However, when r is zero ArcTo returns TRUE but the position is not updated: p contains the starting position of (200,100).
The documentation states that "If no error occurs, the current position is set to the ending point of the arc." The function returned TRUE indicating success so the position should have been updated.
In my view this a bug. The function should return FALSE because the rectangle is empty so there is no arc and thus no well-defined endpoint. However, it would be more useful in practice if the function returned TRUE and updated the current position to match the final coordinate pair in the parameter list. But it does neither of these things. EDIT: An even better implementation in your case would be to calculate the arc end points in logical coordinates before converting to device coordinates, but GDI in general doesn't work like this.
The problem occurs in your code because your coordinate transformation collapses the second arc's rectangle to an empty rectangle when the zoom is 266. You can see this yourself by adding the following to your code to transform the coordinates of the second arc:
POINT points[4] = {{50,2311},{90,2351},{50,2331},{70,2351}};
LPtoDP(hdc, points, 4);
With the zoom set to 266 the points are transformed to (17,90), (17,91), (17,91), (17,91) so the rectangle has no width and is empty. And you hit the ArcTo bug.
I guess it works for smaller zooms when the rounding happens to put the x-coordinates into adjacent integers rather than the same integer.
A simple fix would be to create a MyArcTo function that replaces the arc with a LineTo when it is too small to be visible.
I want to modify the pitch at two different parts of a wav file. To do that , i have the information of starting time and ending time from the corresponding textgrid file of the wav file. Is it possible to modify the pitch at two parts.
You can use a Manipulation object to make any changes you want to the original sound's pitch.
# Original sound made of three consecutive notes
snd[1] = Create Sound as pure tone: "A", 1, 0, 0.3, 44100, 220, 0.2, 0.01, 0.01
snd[2] = Create Sound as pure tone: "B", 1, 0, 0.3, 44100, 247, 0.2, 0.01, 0.01
snd[3] = Create Sound as pure tone: "C", 1, 0, 0.3, 44100, 277, 0.2, 0.01, 0.01
selectObject(snd[1], snd[2], snd[3])
sound = Concatenate
Rename: "original"
removeObject(snd[1], snd[2], snd[3])
selectObject(sound)
Play
# We will invert the pitch, so that the notes play in the opposite direction
manipulation = To Manipulation: 0.01, 200, 300
pitchtier = Extract pitch tier
# We copy it because we want to modify it, not create one from scratch
# and we want to be able to read the values of the original from somewhere
original = Copy: "old"
points = Get number of points
# This for loop looks at the values of the original pitch tier and writes them
# onto the new pitch tier
for p to points
selectObject(original)
f = Get value at index: points - p + 1
t = Get time from index: p
# If you uncomment the if block, the changes will only affect the first and last
# quarter of the sound
# if t < 0.25 or t > 0.75
selectObject(pitchtier)
Remove point: p
Add point: t, f
# endif
endfor
# We replace the pitch tier
selectObject(pitchtier, manipulation)
Replace pitch tier
# Resynthesize
selectObject(manipulation)
new_sound = Get resynthesis (overlap-add)
# And clean up
removeObject(original, pitchtier, manipulation)
selectObject(new_sound)
Rename: "modified"
Play
You change the pitch tier by adding points at different times with different pitch values (in Hertz), and when you do the resynthesis Praat will modify the original values so they match the ones you specified.
In your case, you can use the time values from the TextGrid to know when the modified PitchTier points need to be added and leave the rest alone. You can also manipulate duration like this.
In the example, the script changes the value of each of the points in the original pitch tier with the value of the points in the inverted order, so that the first point will have the value of the last one. The if block inside the for is one way of limiting those changes to a subset of the pitch tier, but how you do this will depend on the sort of changes you are trying to make.
Please check this neat piece of code I found:
glEnable(GL_LINE_SMOOTH);
glColor4ub(0, 0, 0, 150);
mmDrawCircle( ccp(100, 100), 20, 0, 50, NO);
glLineWidth(40);
ccDrawLine(ccp(100, 100), ccp(100 + 100, 100));
mmDrawCircle( ccp(100+100, 100), 20, 0, 50, NO);
where mmDrawCircle and ccDrawLine just draws these shapes [FILLED] somehow... (ccp means a point with the given x, y coordinates respectively).
My problem .... Yes, you guessed it, The line overlaps with the circle, and both are translucent (semi transparent). So, the final shape is there, but the overlapping part becomes darker and the overall shape looks ugly.. i.e, I would be fine if I was drawing with 255 alpha.
Is there a way to tell OpenGL to render one of the shapes in the overlapping parts??
(The shape is obviously a rectangle with rounded edges .. half-circles..)
You could turn on GL_DEPTH_TEST and render the line first and a little closer to the camera. When you then render the circle below, the fragments of the line won't be touched.
(You can also use the stencil buffer for an effect like this).
Note that this might still look ugly. If you want to use anti-aliasing you should think quite hard on which blending modes you apply and in what order you render the primitives.