![]() | Blog |
![]() | Releases |
Page:
0 3 4 5 6 7 8 9 10 11 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95 ... 100
Drawing windows BUTTONs on coloured backgrounds | |
---|---|
Date: 4/7/2016 Tags: windows | The default windows BUTTON drawing behaviour draws a 1px grey border around buttons. If you place the button on a parent window that is a different colour you get an ugly border like this:![]() So I decided to see what I could do about that. It turns out that there is no "setting" that can fix that. You either draw the whole control yourself or let the system draw it. Now I want the system look without the wrong coloured border. So I reimplemented the WM_PAINT like so: case WM_PAINT: { if (!GetCss()) break; // This is the effective background of the parent window: GCss::ColorDef bk = GetCss()->NoPaintColor(); // If it's not the default... if (!bk.IsValid()) break; // Then create a screen device context for painting GScreenDC dc(this); // Get the control to draw itself into a bitmap GRect c = GetPos(); // Create a HBITMAP in the same size as the control // and the same bit depth as the screen GMemDC m(c.X(), c.Y(), GdcD->GetColourSpace()); // Create a HDC for the bitmap HDC hdc = m.StartDC(); // Ask the control to draw itself into the memory bitmap SendMessage(_View, WM_PRINT, (WPARAM)hdc, PRF_ERASEBKGND|PRF_CLIENT); // End the HDC m.EndDC(); // Draw correct background m.Colour(bk.Rgb32, 32); // The outside 1px border (unfilled rect) m.Box(0, 0, c.X()-1, c.Y()-1); // The 4 pixels at the corners m.Set(1, 1); m.Set(c.X()-2, 1); m.Set(1, c.Y()-2); m.Set(c.X()-2, c.Y()-2); // Now stick it on the screen dc.Blt(0, 0, &m); // Skip over calling the parent class' callback procedure. return true; break; }What it does is get the system to draw the button into a memory bitmap and then "fix" the border, before blting the whole thing to the screen. Now it's implemented with LGI types and classes, but the whole idea is fairly straight forward that you could implement in raw Win32 API calls. This fixes the border and still looks native: ![]() The key is re-purposing the WM_PRINT message to get a copy of the control's native look. For the moment I've limited this to just when running on Windows 7, because I think Windows 8 and 10 use flat colour controls and [possibly] don't need fixing like this. |
(0) Comments | Add Comment | |
Logic Pro X bounce time | |
---|---|
Date: 27/4/2016 Tags: logic audio | I was doing some mixing today and the bounce time in Logic Pro X seemed very long. Much slower than I was expecting. (Bouncing is basically "rendering" all the audio down to a stereo track for those wondering). I opened up the Activity Monitor and Logic was reading 10mb/s off a disk capable of 100mb/s. CPU was about 30%, i.e. it's using one core (of my 4 core i5 machine). In true programmer fashion I started to google the problem and it appears that people are having trouble with various plugins being slow. I didn't have anything much loaded, just lots of audio tracks. But I tried disabling the reverb to see if it made any difference. None whatsoever. I began wondering about the disk speed. Maybe it's causing problems? So I copied the project (all 50GiB) onto a fast USB3 flash drive and run my test again. The export of 2 songs went from 2 minutes to 20 seconds. Uh, ok, wow that's pretty different. Then I started to wonder about why that is so. The USB3 flash drive is capable of 190MiB / second, and the original hard drive can do 110MiB / second. It's in the same ball park really... so why the order of magnitude performance difference? I think it comes down to the read strategy of Logic. Now I'm just guessing here, but I think it reads small blocks (KiB) of audio from the files to keep the in memory buffer of audio small. This means in large projects with many audio tracks seeking from one file to the next constantly trying to get the next little bit of the audio. This is kinda worst case for a mechanical drive that has to move the head to a new location between each file. Seeking is expensive. On the USB key, seeking is almost free... so it runs fast. Now the authors of Logic could have bumped the buffer size up considerably so that when trying to access lots of audio tracks there would be more reading and less seeking between files. In my case with 16GiB of RAM to burn that would be fine, but might be an issue with smaller RAM sizes. You certainly can't afford any paging during audio work. Still Logic should be able to see how much RAM is available and size it's internal buffers accordingly. Obviously for anything to do with "live" audio the buffer size has to be tiny, so that the latency is short. But for pre-recorded material buffering up a few MiB's of audio shouldn't be an issue. |
(0) Comments | Add Comment | |
MC2 April Progress | |
---|---|
Date: 3/4/2016 Tags: mc2 | So here is a scary idea... I'm playing next weekend in my live band. Should I use the MC2 for the first time? If I get a bunch of stuff finished I don't see why not, although I'll definitely have the MC1 packed in case it doesn't go smoothly. The main hurdle will be the expression pedal ports which I haven't really done any work towards other than getting the ADS1115 chip to show up on the I2C bus. Nothing like a dead line to get you moving. Running progress:
|
(0) Comments | Add Comment | |
MC2 March Progress | |
---|---|
Date: 1/4/2016 Tags: mc2 | After when seems like forever I bring you an update on the MC2 project. The good news is that most of the hardware is now working, including MIDI Input/Output, the Neopixel chain, the I2C bus to the GPIO expander chips, which in turn connects to the buttons and encoders. In short I can now use it to change presets on the Axefx which is like the bare minimum functionality. Some of the issues I've had to sort out:
|
(0) Comments | Add Comment | |
Got the NeoPixels working | |
---|---|
Date: 3/3/2016 Tags: mc2 |
I've got around to working on the MC2 again. Last I got up to was getting the NeoPixels working and for some reason none of them would light up. To isolate the issue I used the bread board to step the data signal from 3.3v up to 5v. As you can see it works great. Now I know the NeoPixels themselves, and their connections are good I can get to work finding the issue on the peripheral board. |
(0) Comments | Add Comment | |
Merry Christmas | |
---|---|
Date: 24/12/2015 Tags: scribe linux | I think for the first time ever? There is a simultaneous release of Scribe on 3 different platforms: Windows, Mac AND Linux. The new v2.1.3 build is tri-platform. The Linux (x64) build is a GTK2 app and runs ok on Ubuntu and Arch. Well that's all I've tested at this point. It also runs on a Raspberry Pi 2 although it's a little slow. I know because I got bored and tried building it while working on some MC2 stuff. Links to the i.Scribe builds: |
(0) Comments | Add Comment | |