Matthieu Brucher's blog

Annoucement: PyVST 0.1

Matt — Tue, 09 Mar 2010 08:06:43 +0000

I am pleased to announce the first release of PyVST.
PyVST is a ctypes-based wrapper for the (open) VST standard developed by Steinberg for audio processing.

Version 0.1 provides basic access to the VST interface, as well as a script to analyze and display the audio process of a plugin. It can be easy-installed or downloaded on its Launchpad page.

Changelog for 0.1:

Uses the VST dispatcher for several functions:
- processReplacing
- processDoubleReplacing
- open/close the plugin
- open/close the GUI editor
- returns the GUI rectangle
- set the sample rate
- set the block size
- get name/vendor/product
- handle programs
- handle parameters
- suspend/resume
set/get a parameter
get number of programs
get number of inputs
get number of outputs
display.py script
- can load any plugin
- displays the editor, if it exists
- uses a stereo sine-sweep
- displays a spectrogram of the process of the stereo sine-sweep
- dumps properties information

Fixing the QtAGain plugin

Matt — Tue, 02 Mar 2010 08:21:58 +0000

Some months ago, I’ve modified the AGain plugin sample from the VST SDK to add a Qt window. At that time, I encountered an issue with Vsthost, which is a common VST host. The issue was that in windowed mode, the plugin’s UI wasn’t displayed. With Traktion, I didn’t have this problem, but the minihost (a sample from the SDK) also didn’t use the UI size.

When developing pyvst, I has to implement the retrieval of the size of the plugin, and I’ve decided to add this to QtAGain. I was surprised to see that it actually work with just giving back the UI size (so fixing this was less than 5 lines).

So now, I know that to impelment an UI for a VST plugin, I have to implement:

open()
close()
but also getRect()

Don’t make the same mistake as I did, do implement all three of them, even if your favorite VST host can live without getRect().

P.S.: Mixing Qt for VST UIs and wxPython for pyvst works really fine!

Optimization scikit: Structure and implementation

Matt — Thu, 25 Feb 2010 08:04:09 +0000

Some weeks ago, the first release of the optimization scikit was done. I’d like to expose here the internal structure and the way the implementation was thought.

Context

There a lot of optimization routines that can be found in dozens of languages. The issue I faced when implementing manifold learning algorithms is that I needed something that would allow me to test several different optimizers as well as developing new ones.

I first focused on unconstrained optimization, and more exactly direction and then line search optimization. I was supposed to be able to pick different direction searches, different line searches, and then different criteria. Besides, some of these algorithms may be decorated by others (for instance, a line search may start from different step lengths given by one or several of its decorators). The issue that arises is that each of these small algorithms may need different pieces of information from the others, and also may give different pieces of intel.

Separation principle and object orientation

Usually everyone uses objects in Python, especially for a complex framework. The problem is, as I’ve said, that each object needs information that is created by all the others objects. It is not elegant to browse through each of them so I had to find something else: the separation principle.

This principle says that any state information is saved inside a single structure and all the objects needing information do not have an associated state. This is opposition to the object orientation (with a focus on encapsulation), but in reality, the line is fuzzy. So this is the main idea behind the optimization scikit: separation principle on objects.

Usage and conclusion

I will present a complex use of the scikit in the future, but the idea is simple: create your direction search, create your line search, pick a stopping criterion and use everything with an optimizer. You may reuse each of them with another optimizer later. This way, I’ve designed some complex optimizers that needed finely choosing parts (line searches with some conjugate gradients may benefit from starting point that are different). Also, the cost function is also an object with gradient or even Hessian. This means that numerical differentiation is easilly implemented with a specific class, just as least squares would also be.

Of course, this means that the scikit does not provide the fastest optimization routine. You may create one that is really faster than the scikit, but this means that you already know the precise optizer you need as well as that you may loose a lot of time inside the optimizer and not the cost function. In most cases, this is not the case.

Although this framework was written in Python, it could be ported to several langages with more or less advantages or drawbacks (Java, C++ with heavy usage of templates, …).

Book review: Inside Cyber Warfare

Matt — Tue, 16 Feb 2010 07:57:09 +0000

It’s funny I’ve started reading this book shortly before Google announced it withdraws from China because of a cyber attack. Well, this book is about this new theater of operations and explains what everyone should be ready for.

Content and opinions

Warfare is gouverned by international laws. You can’t attack another country (unless you’re the USA…) without some solid arguments. The issue arises here, as a cyber attack is not something we are used to see, and thus there are several interpretations on this topic.

Jeffrey Carr tries to clear the picture by stating what is a cyber attack and how a state can be found responsible for a cyber attack. Indeed, this is a difficult topic as a lot of attacks are made by “simple” hackers that are not officially employed by a state (kind of mercenaries). The fourth whapter is written by an invited guest and describes how a cyber attack may be responded to. It is a complicated legal issue under international laws, but the author is also very clear in his demonstration.

After the legal part, Jeffrey Carr tackles the general topic of intelligence. Attacks may focus on retrieving information (social intelligence or data) or disconnecting websites. I was amazed to see that there were attacks on some websites so that people couldn’t get information from rebels to some states, and that those attacks were made by the before-mentioned states. I thought that hackers were mainly outlaws, but it seems that states rely on hackers when rebels rely more on open information (I’m thinking about the Iran situation).

A lot of time must be spend on finding who launched the attack. How is it possible to launch an attack without being indentified is an issue tackled by several chapters. It seems that a lot of people on the Internet do not ware about accurate information, and this disables the capacity of investigators to find their quarry. It’s also surprising to see the difference between the reality and the movies/TV series where a hacker can find the attacker in less than a minute…

The last chapters are dedicated to using malwares for an attack (retrieving information or setting up a DDOS attack), the military doctrine of China and Russia, how can cyber attack be detected (in a state versus state situation) and general advice for cyber defense.

I have to say that I’m worried when I hear some of France MP saying that all DNS are under US management (which is obviously wrong) and that France should nationalize the Internet: how could we prepare for cyber warfare with this kind of MP??

Conclusion

Although only China, Russia and the USA positions are tackled, I think Europe has even greater problems than the US. The picture given by the book may be grim, but at least it clearly states the challenges we have to face now. I think it is also a corner stone for developing our (meaning your country’s) cyber doctrine. So if you think that Google versus China is not something to be worried about, read it, and if you know that is a symptom of a dangerous disease, read it also.

Here is an interview of Jeffrey Carr that I found also interesting.

Inside Cyber Warfare
Price: $28.79

Inside Cyber Warfare: Mapping the Cyber Underworld (Paperback)
by Jeffrey Carr
ISBN: 0596802153

Price: USD 26.39
38 used & new available from USD 16.99

| 4 | 11

PyVST: another ctypes-based Python VST wrapper

Matt — Tue, 09 Feb 2010 08:06:47 +0000

In a previous post, I’ve tried to use Qt for the editor window of a VST plugin. The thing is, I want to do more than just play with a GUI, I also want to see what is done to an audio stream by a plugin.

To do so, I’ve decided to expose the VST interface to Python. There are some implementation I’ve heard of, but they are based on Cython or other wrapping tools. Ctypes has the advantage of not needing a compilation step. There are also every functionality needed, as callback creation (plugins use a callback to ask the host some stuffs), and Python provides the additional mathematical tools to display what the plugin does. It may not be perfect, but it will be enough for a starter.

Wrapping the VST effect class

Wrapping a VST class is not an easy task. The plugin is accessed by a C structure with pointer functions for the main functionalities: processing an audio flow (with floats or doubles), setting and getting parameters, and a general function for setting and getting information. Additionaly, when instantiating a plugin, a callback must be given. This ctypes callback will have to be stored inside the wrapper so that it stays valid through the plugin lifetime.

So the C structure is created as a class that inherits from ctypes.Structure. Then I have to populate a class that will call the correct function or return the appropriate element inside this structure.

^?Download aeffect.py

class AEffect(Structure):
  _fields_ = [
                    ('magic', c_int),
                    ('dispatcher', c_void_p),
                    ('process', c_void_p),
                    ('setParameter', c_void_p),
                    ('getParameter', c_void_p),
(...)
                    ]
 
audiomaster_callback = CFUNCTYPE(c_void_p, POINTER(AEffect), c_int, c_int, c_long, c_void_p, c_float)

^?Download vstplugin.py

class VSTPlugin(object):
  def __init__(self, filename, audio_callback = basic_callback):
    """
    Constructor
    Parameters:
      filename is the name of the plugin to load
      audio_callback is the Python function to call (optional)
    """
    self.__lib = CDLL(filename)
    self.__callback = audiomaster_callback(audio_callback)
 
    try:
      self.__lib.VSTPluginMain.argtypes = [audiomaster_callback, ]
      self.__lib.VSTPluginMain.restype = POINTER(AEffect)
      self.__effect = self.__lib.VSTPluginMain(self.__callback).contents
    except AttributeError:
      self.__lib.main.argtypes = [audiomaster_callback, ]
      self.__lib.main.restype = POINTER(AEffect)
      self.__effect = self.__lib.main(self.__callback).contents

The main VST function must be called through a dispatch function available in the structure. I will only show of them:

Rewritting the minihost sample

The minihost sample prints some details of the VST plugin and then displays them. Here, I’ll do the same, but I’ve processed a sine-sweep signal and then display the result. If the 64bits processing is available, I will use it.

Here are some info that are displayed prior to the processing for the Big Tick NastyShaper plugin:

Plugin name:
Vendor name:
Product name:
numPrograms = 16
numParams = 11
numInputs = 2
numOutputs = 2

Program 000: Nasty Shaper
(...)
Program 015: Nasty Shaper
Param 000: Pre-Gain [0.00 dB] (normalized = 0.500000)
Param 001: Post-Gain [0.00 dB] (normalized = 0.500000)
Param 002: WS1 [25.00  %] (normalized = 0.250000)
Param 003: WS2 [35.00  %] (normalized = 0.350000)
Param 004: WS3 [45.00  %] (normalized = 0.450000)
Param 005: WS4 [55.00  %] (normalized = 0.550000)
Param 006: WS5 [20.00  %] (normalized = 0.200000)
Param 007: WS6 [60.00  %] (normalized = 0.600000)
Param 008: WS7 [30.00  %] (normalized = 0.300000)
Param 009: WS8 [40.00  %] (normalized = 0.400000)
Param 010: Oversample [OFF  ] (normalized = 0.000000)
Testing with floats (32bits)

Here is a graphical result. On the first row, I display the original input, on the second row is the associated output.

To be continued

The whole 2.4 standard is not yet wrapped, far from it. There is still much to do to be able to use this wrapper class for every plugin (how do I load an impulse for a convolution reverb for instance), but it can still help analyze how a lot of plugins change the audio signal.

Some plugins are not working yet (mainly because every input and output must be connected), but I’m working on it

The code is available on Launchpad.

Annoucement: scikits.optimization 0.1

Matt — Tue, 02 Feb 2010 08:36:18 +0000

I’m pleased to announce the first release of one of my projects. This scikits is based on a generic framework that can support unconstrained cost function minimization. It is based on a separation principle and is also completely object oriented.

Several optimizers are available:

Nelder-Mead or simplex minimization
Unconstrained gradient-based minimization

The usual criterias can be used:

Iteration limit
Parameter change (relative and absolute)
Cost function changer (relative and absolute)
Composite criterion generation (AND/OR)

Different direction searches are available:

Gradient
Several conjugate-gradient (Fletcher-Reeves, …)
Decorators for selecting part of the gradient
Marquardt step

Finally several line searches (1D minimization) were coded:

Fibonacci and gold number methods (exact line searches)
Wolfe-Powell soft and strong rules
Goldstein line search
Cubic interpolation

Additional helper classes can be used:

Finite difference differentation (central and forward)
Quadratic cost (for least square estimation)
Levenberg-Marquardt approximation for least square estimation

Although it is the 0.1 version, the code is quite stable and is used in the learn scikit.

The package can be easy-installed or can be found on PyPI.

Several tutorials are available or will be available on the future at the following locations:

Fun book: Dreaming In Code

Matt — Tue, 26 Jan 2010 08:29:27 +0000

I’ve decided for once to read a novel about software. This book is about the story of Chandler, a piece of software that was a dream that didn’t quite came true.

Content and opinions

The audience of this book is mainly people that do not know much about software but that want to know about a story that drove people for several years. There are a lot of fkashbacks inside software history or parenthesises on software.

Also the book is acclaimed by the critics, I didn’t find it that much interesting. It is very difficult to read the whole book, as the the thread goes from history to context to side stories to the main stories, sometimes after each parenthesis. This is tiresome, and is a drawback for a good book when you want to relax a little bit. Here, you won’t be able to do so, you’ll have to keep focusing on what the author wants to tell you (and that’s not really easy).

Conclusion

Not as much fun as I expected, but still, there are some passages that may be worth it for managers that don’t want to read a book on software project management. I won’t recommend it, but you may still want to learn from other people’s mistakes.

Dreaming in Code: Two Dozen Programmers, Three Years, 4, 732 Bugs, and One Quest for Transcendent Software
Price: $11.92

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software (Paperback)
by Scott Rosenberg
ISBN: 1400082471

Price: USD 9.86
59 used & new available from USD 2.95

| 4 | 70

Book review: Software Project Secrets: Why Software Projects Fail

Matt — Tue, 19 Jan 2010 08:03:46 +0000

There are more stories of failed software projects than of failed insert_another_field projects. But why is that so? Of course, software management is young, contrary to the other fields, but there are a set of management practices that should help project managers in their jobs. Why are they failing? Is it because they are not applied? Because the field is really too young? Or something else?

Content and opinions

The first part is dedicated to the reasons why a software project can fail. It starts with 12 reasons of why software is different than other fields. This implies some assumptions that can differ from the usual project management. The last chapter is a simulation of what a failing software project is. All in all, the main message passes, but I think it is too harsh. The underlying idea is that software is different than all the other fields, but in fact, it may be all the same (at least on the points that were underlined): building a bridge is something we know how to do through usual management, but it can still run late/too expensive/… Besides, the example is overdone. It cumulates all the typical mistakes that we know now how to avoid.

The second part gives the pieces of advice to fix what the first part uncovered. Three agile processes are explained, then tools to budget with one of these processes. the last is the example of the first part reloaded with agile methods. I agree that agile methods are an answer to the software management project, but each time software management is really opposed to usual management. There are issues that are still really different in software projects: defining the needs of the users. When you build a bridge or when you build a house, you know what you want. You know the number of ways, or the number of doors/windows/rooms, … In software projects, you don’t know how many doors you need. Another issue is that people think that software is easy to do, so it’s easy to add something else (mainly because it is mandatory… or not).

Conclusion

If the book is really easy to read, there are some shortcuts that did bother me: the two examples are caricatures of reality (not even a real example where things went well or really bad, they are a story), and software management is also exagerated compared to project management. Perhaps the real conclusion is this one: exageration. Software project management is too difficult to be explained by a caricature: it may lead to the opposite effect.

Software Project Secrets: Why Software Projects Fail
Price: $49.49

Software Project Secrets: Why Software Projects Fail (Expert’s Voice) (Hardcover)
by George Stepanek
ISBN: 1590595505

Price: USD 33.20
39 used & new available from USD 2.99

| 4.5 | 6

Thinking of good practices when developing with accelerators

Matt — Tue, 05 Jan 2010 08:48:57 +0000

Due to the end of the free lunch, manufacturers started to provide differents processing units and developers started to go parallel. It’s kind of back to the future, as accelerators existed before today (the x87 FPU started as a coprocessor, for instance). If those accelerators were integrated into the CPU, their instruction set were also.

Today’s accelerators are not there yet. The tools are not ready yet (code translators) and usual programming practices may not be adequate. All the ecosystem will evolve, accelerators will change (GPUs are the main trend, but they will be different in a few years), so what you will do today needs to be shaped with these changes in mind. How is it possible to do so? Is it even possible?

Available code translators

Code translators are the easiest path to solution. I know two of them.

The first is the PGI compiler. It only supports CUDA and the Fortran and C99 language. I didn’t use it yet, also I plan of testing it in the near future. It is based on pragmas, and the compiler generates the CUDA microcode.

The second solution is HMPP. It supports more than just CUDA (also CAL/IL or OpenCL) and Fortran/C (also Java now). As the PGI compiler, it is based on pragmas, and a excellent thing is that it detects the available accelerators and launches the correct kernel (if you authorized it) or the original code. You can also modify the generated code to put your own (you can tune the code for instance, which may give you an additional x2 factor). Unfortunately, it is not possible to call functions inside the parallelized kernels, which means that only simple or badly-written (too many lines or duplicated code) kernels can be called. I think this is the same for the PGI compiler.

It seems that code translators still need work:

only few accelerators are supported (CUDA, and sometimes CAL/IL or OpenCL),
almost no langage (Fortran/C/Java, a lot of Virtual Machines should be able to use them natively, without developers using specific tools),
only one function can be parallelized at a time.

The last point is currently the biggest issue. You need to cut your function int pieces to have clean code and a good portability/evolutivity for the future.

This is why one still need to program a lot for those accelerators, and so we need to adapt our programming practices, develop in the accelerators’ native langages (even if we know that they may disappear in a few years).

Developping your own “tool chain” for accelerators

For accelerators, there are a lot of things that needs to be done each time: copying some data, computing and getting some data back. These are the steps that code translators automate, in fact it is a common practice to use tools to automate stuff. The issue is that complex kernels are not supported by those translators. So what?

Creating automatic functions that will copy the data you need is in fact very common in metaprogramming. Coding the kernel on an accelerator is in fact not that difficult: the manufacturers provide the needed compilers (that’s what nVidia does and the success of the tool chain cannot be denied), and this is really the cornerstone. One has to write more code, some parts are less portable (because they are written in one of the accelerator’s languages), but in the end, with metaprogramming, the code can be better tuned, enhanced and read. This is the leverage of the accelerators.

Conclusion

Why do we care developing for accelerators? We know that they will go away. Before they do, they are the only way of speeding up our software. Code translators are the best tools to develop in a portable way, but they need time to support more accelerators, languages and method of programming. When CPUs will be on a par with accelerators, their progress will help compilers to target them correctly. It’s just a matter of time.
Meanwhile, metaprogrammin is the next best solution to automate processes that code translators cannot support yet.

Book review: The Passionate Programmer

Matt — Tue, 29 Dec 2009 08:53:16 +0000

It’s all about passion. The second edition of the book saw its title changed (it was called My Job Went To India) to something less depressing and more adequate to what we all should do: be passionate about our work and be happy to do it (it also applies to other job than developers!).

Content and opinions

The book consists of a lot of pieces of advice (the brand of Pragmatic Bookshelf, the publisher), not too many so as not to be bored at the end.

It starts with the field (i.e. language and technology) you may focus on. Either you want to be at the edge, or rely on a mature technology. It depends, but there are some specifics you should know if you want to bloom.
The second aspect/part is dedicated to your network: how do you get information and how do you give it? Who should you be working with? All these aspects help you be the best at what you do.
When you actually work, there are some advice to make you really essential to your company: speak your mind, read the leader’s one, make your job profitabe to your company, …
The fourth part is about marketing. It is perhaps surprising, but you have to sell yourself. You may be the best in your field, have an excellent network and are essential to your company, if it doesn’t know it, you’re screwed. Sell yourself, this will be also great if you want/have to switch jobs.
Your carrier path is not clear with all the technology changes, with the current economical situation. You have to ready yourself to this, which is what the last part is all about: prospects and your future.

Each time the chapter is clear and goes straight to the point. The content is also explained with music metaphors, as the author is also a musician. Other well-known people give their opinion on some chapters of the book, each time shedding a new light on our own situation.

Conclusion

Pragmatic advice starts with obvious advice. If the content seems rather obvious (especially if you want to be better at your job, you may have applied a lot of the pieces of advice of the book), it’s always good to have it reminded, as we tend to not see the forest of the trees.

The main idea is to be at the edge. Learn from others, listen to the trends and the people who make them, and act accordingly.

The Passionate Programmer: Creating a Remarkable Career in Software Development
Price: $20.47

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) (Paperback)
by Chad Fowler
ISBN: 1934356344

Price: USD 16.29
39 used & new available from USD 12.28

| 4.5 | 29