On intuition and habits

Published on February 13, 2011 in Graphics. 4 Comments

One of the most amusing misconceptions about software is that it can be intuitive or non-intutitive, with gradations between them. Being part of Audacity team, I’ve been receiving all sorts of feedback to our feedback email adress that we share for years. The nonsense of intuition as a notion regarding software can be easily illustrated with these two mails received with a gap of just an hour:

“Forward: Audacity is AWESOME! Absolutely love how intuitive it is and the price tag!”

“I tried the program and need to say that it is very un-intuitive. So I do not use it. Even simple tasks, like splitting a large file into several small ones (with lost cue sheet) is impossible to figure.”

C’mon people, software isn’t about intuition, software is about habits :) And speaking of habits here is another (translated) quote I can share:

“I use Inkscape. The migration from Corel [DRAW] was long and painful, I sat at nights and yelled. A month later I was thinking “OK, I think it’s usable after all, but Corel is still much better”. Two months after that I was thinking in the lines of “Yeah, it’s usable, but Corel is still better”. Then half a year later: “Well, Corel is a good vector graphics editor too.”

Parsing and viewing OLE containers

Published on January 20, 2011 in Development and Graphics. 1 Comment

Our new reverse-engineering project, started end of last year, is progressing. We already know quite a bit about Microsoft Publisher file format, and to make this useful for Scribus team to get cracking with PUB importer, we’ll start writing the spec soon.

For ransacking .pub files Valek wrote a small tool called oletoy which is, simply put, a specialized HEX viewer with tabbed UI that reads OLE container based files and simplifies browsing chunks:

OLE toy 0.5

I’ve just pushed to Git an update from Valek that merges bits of his old(er) vsdviewer app. So oletoy is now a more universal reader of the OLE container. Right now we are not planning to work on reverse-egnineering VSD and VSS much, possible improvements are currently a middle-term goal. OTOH we do see a way to make oletoy a generalized parsing and visualization tool suited not just for OLE containers.

If you happen to have .pub files of any version (2000, 2003 and 2007 preferably) that have really crazy use of various eldritch features, we’d love to have them. Send them to alexandre.prokoudine-WE-LOVE-SPAMMERS-gmail.com.

Catching up on reading

Published on January 17, 2011 in Graphics and Uncategorized. 0 Comments

Packt Publishing released three libre graphics related books in a row in December: “Inkscape 0.48 Essentials for Web Designers” by Bethany Hiitola, “Scribus 1.3.5 beginner’s guide” by Cedric Gemy and “Blender 2.5 Lighting and Rendering” by Aaron W. Powell. I had the first one almost immediately after release (but utterly lacked time to read) and got the second just now. Since all Cedric’s previous books were in French which I don’t speak, I’m really curious what Cedric came up with, so the Scribus book gets priority :)

Scribus 1.3.5 beginner's guide

Now, one question is how many GIMP books we’ll see this year. I know just one so far.

Speaking of GIMP

Published on January 11, 2011 in Development. 3 Comments

The GIMP 2.8 story apparently made it big and reached as far as OMG!Ubuntu, Phoronix and OSNews, not counting few dozens of smaller websites. However, whereas some people got things right, other people took it as a signal to hatefest towards GIMP team. Which was, to be honest, only to be expected. The reason?

It’s all about pressure.

Yes, I’m a talking physics now. It’s about time some people were reminded what pressure really is. Quoting Wikipedia, pressure is the force per unit area applied in a direction perpendicular to the surface of an object. In terms of GIMP it’s millions of people per mere 2.5 people. In terms of human language, it’s like being on the bottom of Mariana Trench without any sort of protection. Gentlemenly behaviour round the clock 7 miles below surface? Right. I can see that.

Anybody with basic understanding of equations can easily figure out that there are only two ways to lower the pressure and make GIMP folks the friendlier ones: make less users (as if you had a different general purpose open source editor like GIMP) or make more contributors. And yet we keep running into people who think that it’s such a smart idea to blame the small overworked team for being arrogant instead of listening for one minute and taking a little of the load.

The problem, however, is bigger than GIMP. Let me state it once again: many major projects utterly suffer from lack of contributors. So what I think really happened is that we simply banged our head against a major milestone: projects growing too large and teams growing backwards with major issues still unresolved.

The real problem we deal with is that the community doesn’t know how to help itself and in some particular cases doesn’t even want to, and dev teams often do not know how to handle this situation. So I’m putting a couple of ongoing publications on hold to do some good there. Expect an update soon.

What’s up with free multimedia production tools in 2010

Published on December 24, 2010 in Development. 2 Comments

After some thinking how to best serve the dish with what little time I currently have here comes an overview of what was happening with free multimedia production tools during 2010. Read on! :)

There’s a bunch of other publications coming during the holidays season, mostly thanks to a magic gadget I stole borrowed from one vendor. The gadget takes a draft of an article and finalizes it. No more hassle of “dunno if it’s good enough to share”. It’s magic!

Nevertheless, I wish you to simply make the most of this holiday season. Stay tuned for more rants :)

On VST, WINE and all

Published on December 21, 2010 in Development and Sound. 2 Comments Tags: , , , , .

The epic battle against Focusrite Plugin Suite is over and I’m defeated. The problem turns out to be in the license registration prompt that simply refuses to load under WINE, whether you load it in Ableton Live or in Ardour: any signal simply gets bypassed until the plugins are registered. There probably is some WINE conspiracy in support for native effects/instruments SDK over VST :)
Continue reading ‘On VST, WINE and all’

The more the better

Published on December 20, 2010 in Development and Graphics. 7 Comments

As an appendix to the recent rant, the hilarious “Creative Suite for Linux” thread on omgubuntu brought this gem a couple of days ago:

“It [migration from Windows to Linux] will solve many issues. In free software community more users = more contributors. More contributors = better software. Better software = more users.”

Sounds like a dream, eh? Surely at least some of those people using free software want to contribute?

Let’s have look at download stats of Windows build of GIMP. The SourceForge page defaults to a week, and for the current timeframe (Dec 13 2010 to Dec 20 2010) it shows 379,681 downloads. That’s 380K downloads a week, boys and girls.

How about a year? 15,902,245.

So, how many new committed developers appeared in that timeframe? I mean, out of those very nearly 16 millions? 10? 20? 50? Um, no. It’s actually zero. Oh wait, I’m wrong! It’s actually -1, ’cause Martin is rather busy since last spring. The usual amount of people who occasionally do something hasn’t changed.

Now you might argue this is because typical Windows users are this and that, but seriously, there is no direct connection between amount of users and amount of contributors. You can have a very small, yet very focused community like the amazing gis-lab.info guys (sorry, it’s mostly in Russian) who work their ass off to make free GIS tools Just Work™ (and they use different OSes). And you can have a large project that doesn’t gain committed contributors at all despite of being well-known, popular, yadda-yadda… Amount of user base simply doesn’t affect anything directly.

Things we should do better

Published on December 12, 2010 in Development. 3 Comments

Earlier this year I had a meeting with Konstantin Rotkevich, who asked me in a by-the-way fashion how things were going for Inkscape. Some five minutes later he told me: “You know, Alex, every time I ask you this question you tell me some horrible stories about Inkscape, and yet the project strives”. Which is exactly true: many software projects live on the edge of complete and utter failure.

The previous blog posting covered things we don’t really do better than proprietary software vendors and things we actually do better than them. Now let’s talk about our weaknesses. This particular blog posting is loosely based around a rather angry mail I sent to one mailing list recently.
Continue reading ‘Things we should do better’

REX2 is on radar

Published on December 9, 2010 in Development and Sound. 0 Comments Tags: , , .

A while ago we, re-lab project, started clean-room reverse-engineering of REX2 — a rather popular file format of audio loops supported by most DAWs on the market except free/libre ones. Before we started we actually contacted Propellerhead to ask if they are willing to share the spec and got no reply whatsoever. Since Propellerhead has a history of being not quite friendly towards open source projects, and we still want our files supported, thank you very much, we proceeded with reverse-engineereing.

Right now we have several Python scripts to parse .rx2 files and dump contents to stdout. There is also a stub of the spec that we intend to fill ASAP with what we already know. If you have a licensed copy of Propellerhead ReCycle (that is the primary authoring application for REX2) and you want REX2 supported by free audio tools, don’t hesitate to join.

The request for REX2 spec originally came from Paul Davis of Ardour fame, so we expect Ardour to be the first application to support REX2. All the work happens in Gitorious: http://gitorious.org/re-lab/audio.

Things we do better

Published on December 8, 2010 in Development. 5 Comments

One of rather fair questions I keep hearing is what exactly free open source software is better at. Sadly, typical reponses often rely on rather flawed argumentation. So it’s time for a bit of myths breaking.
Continue reading ‘Things we do better’