BulkDump

You do hate when you get very obscure error reports from your clients? Atleast I do. Especially those screenshots of the very descriptive Microsoft “This program has encountered error and needs to be closed.”. Why the default crash dialog needs to be so general and all the interesting bits are hidden behind some “click here” link? Normal users usually just take screenshots of the first error dialog they see and assume we would know from that what’s wrong.

This time the problem was that IE was crashing instantly when visiting our web application’s first page. I asked our client to send some screenshots of his IE settings and I google around a bit. I instructed him to disable 3rd party extensions which did solve the problem. Further investigation revealed that the problem was Textware’s QuickFIND BHO which he no doubt gotten from Cambridge Learner’s Dictionary. I could find only one screenshot of this program in action. Looks quite useful application, but definetely very buggy. Unfortunately the Textware company is long gone as well. Their website just points to some very generic site. I doubt we will be getting any updates to QuickFIND.

The problem is the way this IE add-on works. It monitors your mouse movements in IE and displays info about the text your mouse is hovering. For some reason prototype.js makes the plugin to crash and take IE down with it. I really hope we don’t have to try to solve this issue, or are forced to strip prototype.js till it’s working. And to be honest, it would only solve the problems in our website. There are many Web2.0 applications in the web, and especially since Ruby on Rails relies heavily on the prototype.js and includes it by default, these QuickFIND users are going to experience more and more IE crashes. Even IE7 crashes just like that.

If we have to go down the harder road, I will definitely report back my success in debugging prototype.js. Right now, we’re waiting on customer’s opinion and hoping for the best.

I could find only couple of sources of the same problem:
Source 1,
Source 2

Sometimes I kind of forget my blog. Sorry about that, I’ve never been good at keeping journals. Especially now that I disabled usage of any links in comments. Was getting like 10 spams into moderation queue per day, so I added few keywords into the blacklist, and now almost forgot my blog because it’s been so quiet after that. Hehe.

My cat created small accident couple of days ago. Shame I didn’t take picture, but I was more concerned about the Tascam US-2400 at that time. My other cat, Viivi, jumped over the Tascam US-2400 quite hard and it dropped from the spider stand. I just heard crash and went to see what happened; there it was, one end of US-2400 in my cat’s soft bed and the other end pointing up to the ceiling, the controller was leaning towards the stand. Fortunately it survived the crash unharmed, not even a scratch. It’s really quite well built with metal casing. However the cat bed suffered slightly, but nothing too big. Now I’ve positioned the controller slightly better, so this should not happen again. Now Viivi is sleeping in her favourite place - on top of my amplifier (it’s warm) and next to Genelec 8040A. I sometimes wonder how she can sleep there, Genelec playing directly to her ear. I guess it sounds that good

Now the real subject I was thinking about to write about. That is overhauling the Orion’s MIDI input and output handling into something more “modern”. There are some issues and big limitations with the current implementation which I’d like to get rid off. Considering the MIDI input might crash Orion very randomly when deleting generator you’re controlling with MIDI controller at the same time. Hopefully 7.2 fixes that, but the quick fix most likely affects the performance a bit. Not to mention the limitations; for example motorized controllers don’t work, no endless knob support, no customizable transport controls. Midiout is limited to assigned 4 parameters, no real deal with Midimaps. Oh, and no sysex support or automateable program change events.

I know Orion was not originally designed to support those, it was mainly ment to be software virtual studio. However time has gone forward and we’d atleast need support for motorized/touch sensitive controllers and some special controllers such as Novation Remote SL. Some have asked for Mackie HUI protocol support as well. My personal needs go forward with US-2400 native support and better Midiout to support several hardware synthesizers.

I’ve tried to think ways to implement all this with the easy-to-use Orion way. I’ve done some industry “spying” by taking a look at Cubase, Sonar, Reason, Logic and few others. They all work a bit similar way, you setup your enviroment and tell what kind of controllers you have available. For special controllers there exists presets, possibly with some special functionality programmed in. Such as HUI or US-2400 would need for time displays and VU meters and other status leds. I was thinking something into this direction with few quirks. By default there probably would be chosen port assigned as Generic Midi controller, which would be corresponding to midi input and output ports Orion has now.

I also would like to close the gap between Midi-out synthesizer and Midi-in controller, after all, all are just devices. What I don’t want to do is to go to Cubase way of using midi recording. It’s just so confusing. What I’d like to get rid of from Orion is the Easy/Advanced midi mode selection. One mode is enough with best of both worlds. Mixer surface controllers support with automatic mappings to Orion’s mixer. Automatic knob assignments to generators (VSTs too). Yet, leave all that learning assigment support, modwheel is the universal controller . I really don’t want to see CCs and other stuff when making music, when I left tracker programs behind, I wanted to leave numbers and hex codes behind too.

Maybe some of you have ideas how it should work? I have quite clear picture about it (a lot of it not listed here), but it’s mainly guided with my way of working in my studio. I wouldn’t mind having some discussion about this, you never know if it brings up some good ideas I haven’t though about yet.

Happy christmas for all of you!

I wrapped some last presents for my sisters and tomorrow (well today if being precise) it’s quite traditional christmas day atleast for our family. Some rice porridge (one almond hidden in it, who get’s it can make a wish) for breakfast and then my sisters and I make fruit salad for the evening. No turkey, but ham, potatos and the secret sauce recipe by my mother. After eating santa claus comes and gives the presents (don’t tell my little sister that it’s just me in disguise). I wonder what he’s giving for me this year..?

Other than that I’ve been fixing tons of bugs from Orion in the last few days. I’ll put up new beta for the testers and maybe they have some free time to test in the next few days before I can get back to do some work again.

Some time ago I wrote about the PDF::Writer changes to be able to use font embedding properly. I got one inquiry about this, which is cool. I haven’t yet had time to test the PDFs in Mac OSX (I don’t have Mac myself, only two of my colleagues).

However shortly after writing about the font problem and solution for it I needed some text-transformations and they appeared to be really troublesome. Ie. rotate, stretch, skew text or all at the same time. Especially with the in-place transformations got from SVG files. Same for embedded images.

This led me again back to the PDF specifications and I found solution about transformations for the text block itself. PDF::Writer did not support this except for the fixed angle parameter. What I did I extended the angle parameter also to accept 6 element transformation array. Similar transformation array is accepted by the add_image methods.

After I had “fixed” that the text still did not look correct. Adobe Illustrator was still showing the texts to be have less width. Just by accident I noticed the kerning information in Illustrator and I figured PDF::Writer is not really adding kerning to the text for some reason. And it turned out atleast Acrobat does not view text automatically with kerning even if the kerning data is embedded in the font data.

Once again the PDF specifications were the saviour. Solution was to pre-process the text strings into array strings with the kerning data in them prior writing the PDF data block (so modifications on the add_text were needed). Rather simple string processing (although I admit the code doing it might be a bit poorly written as-is) after fixing bug from fontmetrics.rb to get proper kerning data.

That’s about it. Here’s are the changed and added methods:

PDF::Writer.add_text(x, y, text, size = nil, angle = 0, word_space_adjust = 0, char_space_adjust = 0, text_kerning = 1)

I added support for char_space_adjust and text_kerning. Angle can also be transformation matrix which is in-place relative transformation only to the text’s x, y and own size. No more need to “manually” correct x, y for add_text if you just want to rotate the text.

PDF::Writer.kern(text)
Returns PDF string array with text kerning information of the current font. Mostly useful only internally by the add_text. Note that this requires fixes in the fontmetrics.rb (fixes in the package). In short pdf-writer 1.1.3 just has few bugs in the fontmetrics.rb preventing kerning information being loaded properly.

PDF::Writer.add_image(image, x, y, width = nil, height = nil, image_info = nil, link = nil, matrix = nil)
PDF::Writer.add_image_from_file(image, x, y, width = nil, height = nil, link = nil, matrix = nil)
Basically I added same functionality as with add_text in-place transformation matrix. However there’s small catch in this implementation about the corner of the x, y position when adding image. In 1.1.3 the x, y is the position of the bottom, left corner, but in SVG transformations the corner is top, left. It was easier for me to do it this way for the purpose I needed this change.

This time I provide full package of the PDF::Writer. It’s basically 1.1.3 with the changes I made. Most likely the demos won’t work, but I don’t want to bother myself with that

Download: PDF::Writer 1.1.4

I had this problem of not being able to control my favourite (and you know to my surprise that application actually uses my BarMenu Components Delphi package for it’s menus and popup menus, so even more reason to be my favourite!) video player KMPlayer from the other room we have the TV for watching videos. That constant running between rooms was killing. I had then the idea using my PlayStation Portable as remote controller. It took a moment of thinking that I could harness the webbrowser into use through my WLAN. I couldn’t find any software already doing it, so I decided to create my own small program.

I did some more research to find what the PSP browser is capable of and ways how I could control KMPlayer. What I learned is that there’s no way to get AJAX working in PSP browser, but Flash could work. But for now I settled with invisible frame for GET url requests from the main frame links. That way the main UI would not refresh and links would be “executed” in the invisible frame. I needed small webserver for this purpose and it felt too much trouble to setup apache or something else bigger. So I went for creating own webserver with Delphi’s Indy components. After hour or so I had working webserver which could serve html, images and stylesheets from a docroot directory as any webserver would do. That was all I need to serve nice webbrowser UI for my PSP. Some tweaking was done for port configuration and adding a bit more security for the webserver so we don’t have backdoors.

Now next part was figuring out the interface to KMPlayer. Researching did pay off and I found out that (Win)LIRC protocol was rather simple and KMPlayer supports it out of the box. Creating own LIRC server was done in matter of minutes. Nothing more than simple TCP port listening for clients and sending oneliner text strings as command execution. That server was built into the same application as the webserver. That way I had direct link from the webserver to the LIRC server. I implemented virtual URLs for the webserver in form of /command/command_name_here. Any command executed that way would be directly sent to the clients in the LIRC server. Instantly I had as many remote controller “buttons” I needed.

That app was built as standard Windows Service, so it works completely in background and I created installer to easily install and uninstall it. I forgot to take some pictures of the UI in the PSP screen, but I do that later. The default UI in this version contains only Play/Pause and four seek buttons. But I’ll let you to customize it for your own needs. After all it’s just plain html you need to create and all the commands are automatically available for assignment in your LIRC compatible applications. Or why not create full screen Flash app to call these command urls?

So short, my life got much easier now. I just use my PSP from the other room to control KMPlayer! No need to worry about walls what would be problem with standard IR controllers. Maybe some of you find this application useful as well. Let me know…

Download: PSP Remote Controller Daemon 1.0.0

Good source of PSP Webbrowser capabilities: http://www.brothercake.com/site/resources/reference/psp/

I took some photos of my studio couple of days ago. First I was thinking about setting up some photo album script, but I decided to be a little bit lazy this time and I setup account on Nebula.fi’s service which provides me 5GB webspace with very nice and simple photo album web application. Considering the price is only 5 € per month, I decided fiddling around some 3rd party php scripts would be too troublesome.

The dark overview shot has my two cats somewhere in the picture as well. Can you find both of them?

I’ve been working with some interesting stuff with Ruby and PDF generating lately at work. This includes Ruby code reading one standard file format (used ie. for printing invoices by print houses here in Finland) and then converting that file format into similar looking PDF with pdf-writer Ruby library. we already had invoice generating in that file format and those print houses aren’t too good in providing services for PDF invoices if you want to archive or send PDF invoices, so we ended up using the same file and that makes invoice layout maintaining a lot easier.

Only problem with that above is that print houses provide standard and custom made layout templates which contain static graphical elements for the printed pages. Only the content text with few control codes are in the file format itself. Due this I also created small application for reading SVG files with Ruby REXML, converting the SVG files into structured arrays and hashes. From there the application writes it into Ruby code file which contains code lines for reproducing the SVG graphics in PDF with pdf-writer. So it’s sort of svg to pdf-writer rb converter. This static approach was decided for better performance. There’s no point parsing and converting the svg each time we need the static graphical elements.

The SVG converter supports about 70-80% of SVG specifications, which is all the basic stuff including the path curves for more complex graphics. This makes it possible to use other PDF files (when converted into SVG) or Adobe Illustrator (application I use here at work for vector graphics) to create invoice layouts.

Unfortunately I cannot share any of that, even if I wanted to, because that has been made during my work time.

However there’s something I can share to contribute something for all pdf-writer users. That is some help on embedding TrueType/OpenType and Type1 fonts. I had lots of troubles doing that and I did some debugging with Adobe Illustrator written PDF files and other PDF files. I had to dig the pdf-writer source code as well to see what’s going on. Not to mention the requirement for the AFM files. When I got some PDF files out I was just getting the famous “The font contains a bad /BBox” error message and it was so frusturating when the pdf-writer manual was incomplete on this matter.

Today I’m much wiser on those issues. I even had to do some changes for the pdf-writer source code to get the font-embedding to work properly. In addition to the changes I found perfect OpenSource tool called TTF2PT1 for creating the AFM/PFB files of TrueType fonts. There’s also link for downloading Windows binaries, which was great time saver for me.

First apply the patch to your pdf-writer. The patch includes replacements for the two changed files and diff files if you want to use patch instead of just replacing the files. What I changed is how the font files are handled. There even was a syntax error in the pdf-writer preventing the font embedding from working. In addition the TrueType license checking code was not working properly, atleast on the fonts I tried, so I removed that check from the code. Just make sure you’re using fonts which you are allowed to embed into your PDF files.

What the pdf-writer manual did not mention is the fact that the font files need to be renamed to same name as the FontName data in the AFM file. It just does not work unless you do that. Also the select_font() call takes the file name as parameter. My pdf-writer patch fixes select_font() a bit so you don’t have to give the .afm extension of the file name when using select_font(). That was also something the pdf-writer manual decided not to tell us.

The pdf-writer manual does tell that you need the AFM files (the PDF specification requires that information and pdf-writer doesn’t know how to extract this info by itself). You can use the TTF2PT1 program to convert TTF file into pair of AFM and PFB files. pdf-writer does prefer the PFB over TTF file if you have both in the fonts directory. To setup the fonts directories you can use the following code:

PDF::Writer::FONT_PATH << "./fonts"
PDF::Writer::FontMetrics::METRICS_PATH << "./fonts"

I prefer this, so I can have application specific font files. Copy your TTF font file(s) into that directory and use the following command to convert the font into AFM and PFB file pair:

ttf2pt1 -GFA -b -p ttf myfontfile.ttf

The open the AFM file into text editor and see the line starting with “FontName”. Take the font name and rename the 3 files with that name. For example if you had font “SF Movie Poster.ttf” you’d get files “SFMoviePoster.ttf”, “SFMoviePoster.pfb” and “SFMoviePoster.afm” because the AFM file has line “FontName SFMoviePoster”. As far I as I know the FontName should never contain spaces.

Now in pdf-writer you use this font name with select_font() method. For example:

pdf = PDF::Writer.new(:paper => "A4")
pdf.fill_color Color::RGB::Black
pdf.stroke_color Color::RGB::Black
pdf.select_font "SFMoviePoster"
pdf.add_text 10, 200, "Text with embedded font."
pdf.save_as "test.pdf"

And that’s about it. The generated PDF should open in Acrobat Reader without any error messages and the text is written with the given font. Also the font is shown as embedded font in the Acrobat document properties.

• pdf-writer 1.1.3 patch for Font Embedding
• TTF2PT1, Windows binaries

So Orion Platinum was released couple of days ago. All went pretty nicely considering the size of the upgrade. Few small issues already reported, but nothing serious what couldn’t wait for next release. One user had problems with Wine (that is Linux) and Orion, but I was able to fix that problem and provide a patch for him. If someone has crash problems when starting Orion and preventing Orion startup, I can provide the same patch, but otherwise the fix will be on next release.

Next will be the Orion Pro 7.1. All of the fixes Platinum 7.1 upgrade should be in Pro too (except for the things not already in Pro of course).

What’s after that someone might ask. Infact we have created list of all requested and insane ideas and that list needs to be sorted out. Most likely next upgrade will address the long due Midiout and handling of Midi devices for better support of hardware synthesizers and different midi controllers (ie. motorized controllers). Atleast those are important for me personally. After all I do have 10 hardware synthesizers and that Tascam US-2400 controller here.

As in my earlier post I told I was installing Virtual PC and Windows 98. Luckily I was able to sort out the problems with some Windows 98 driver reinstallations. Orion works great, although maybe slightly slow, but that’s understandable. Now the problem Orion was having was that we updated the ReWire installer on Orion installer (people have been having problems on ReWire not working - but now it should). Seems the latest ReWire 1.7 doesn’t work with Windows 98 and crashes right away when ReWire host is initialized. It’s been solved now by the installer so that it will use older ReWire.dll for those legacy Windows’.

Orion 7.1 getting closer