This planet is made of fresh clean feeds by members of the Entropia bunch
The Harvester is made of fresh flesh, clean design by Tigion, hacked-together Ruby scripts by Astro and Atom support by Neingeist
wget the RSS-1.0 feed!
Missing something?
Contact Neingeist via Mail or Jabber: neingeist@23bit.net
So, over the weekend, I went to Evoke. Evoke, for those who don’t know, is a Demoparty, a sort of gathering for people who write Demos to get together, show off their newest works in the competitions, talk, and potentially get mightily drunk.
We didn’t actually plan to release anything at the party, but after arriving after a 4ish-hour-drive (Drove there with Maep and Saga_Musix, took a few wrong turns… <.<) I suddenly felt like coding something up for the DS. WAHa_06x36 and coda were availble to assist with additional effects, graphics work and music, so in 16 hours of intense partycoding, during the course of which I downed half a crate of club mate and nearly threw up my breakfast, we’re able to give you:
[Pouet] [Non-live video]
Our release was generally well-redieved, and finished second in the “Alternative Plattform” compo. We even got Prizemoney this time around, which was a little unexpected.
One of my favourite demos of the whole party was this 64k intro (It’s 64k, despite what it says in the video). Beautiful use of… cubes! It won, too! <3
Something I sadly only found after the party was over is the full version of this years party jingle, mmsx#001 - dq feat. scraping micha - this year. Absolutely lovely.
In conclusion, Evoke 2010 was an awesome party, massive thanks to the organizers - especially to the beamteam for the recording, you’re awesome - and to brainstorm for free sausages and alcatraz for free beer. o/
The next demoparty for me will probably be the 2010 edition of the ultimate meeting, right here in Karlsruhe, or maybe a party up in finnland! See you there!
- a Platform for Interactive Art Installations
Multitouch360 is a project by Johann Korndoerfer and Thorsten Blum that aims at creating a hemispherical multitouch display. It has now officially reached some degree of "finished", meaning that all essentials are working, no cheap workarounds remain in either hardware or software and the software framework is capable of letting anyone code cool stuff.
Watch the short video below:
This is my debug application running on Multitouch360, showing a wire hemisphere along with camera calibration markers and visualizing touch events. As you can see, touch recognition works reasonably well.
How does it work?
We use a technique called FTIR (Frustrated Total Internal Reflection) to detect touches. This means that an infrared camera looks at the hemisphere from the inside. The picture to the left is what the camera sees - you can see a shadow from the hand and five bright points at the tips of the fingers. Those bright points are created by the users' fingers touching the outer acrylic hemisphere (called the Wave Guide). The Wave Guide is made of clear acrylic and flooded with infrared light from 288 infrared LEDs set in the rim. The IR light can't escape the acrylic except when it is touched by an object with a sufficiently large refractive index, like water or human skin. Thus, the infrared light enters the finger, gets scattered and can be picked up by the camera.
Since you can't project anything onto clear acrylic, we needed a inner layer of matte acrylic (called the Diffusor) just inside the Wave Guide. This layer makes the bright points from the outer layer a bit blurry for the camera, but we would have done the blurring in software anyway. Using a mirror to save some space, we project a rendered image onto the Diffusor, again from below. You can see the whole setup in the image to the right.
The image that is projected onto the sphere gets distorted quite a bit, which has to be anticipated in software. The same applies for the other direction: touch locations have to be transformed back into 3d as well. Both the projection and the camera have to be calibrated, which can be done by clicking five positions with the mouse (calibrating the projector), then touching the same positions on the sphere (calibrating the camera). You can see a visualization of the gradient descent that solves the resulting optimization problem right at the beginning of the video above.
The Software
I made a nice little framework for Multitouch360 that lets you write multitouch applications. The debug application from the video above looks like this:
from multitouch360 import * class DebugApplication(MultitouchApplication): def touch_down(self,touch): TouchIndicator(touch) def touch_move(self,touch): pass def touch_up(self,touch): Explosion(touch.world_pos) def display(self): glutWireSphere(1,30,30) DebugApplication()
And this is it. You can define textures, buttons, etc. easily and the weird math you need for handling things on a sphere is taken care of.
What do you do with it?
First, you can do something with it. If you know some Python and OpenGL, you can code your own application. The Multitouch360 framework will simulate the hemisphere on any computer and you can click on a virtual version of it with your mouse. If you are interested in doing something with it and you are located near Karlsruhe, Germany, please let me know. Keep in mind that anything that runs on Multitouch360 must be tailored to the spherical layout - thinking in 2d will make you wish you had a flat table, but embracing the hemispherical form lets you do some things that are impossible otherwise: planets, star maps, boobs or eyes are some of the things that may come to life. Games that involve not seeing what your opponent is doing on their side are another obvious candidate.
Second, i have made a few very simple demo applications that are hardly more than a hello-world, but may show what's possible. Watch people play Global Thermonuclear War in the video below, incinerating whole countries by touching them. The only winning move is not to play. (Application written in about three hours.)
Project State
Although there are a lot of other ideas for games or weird interactive installations, i am now starting to pursue other projects and apart from some maintenance, documentation and potentially helping you code something nice, the project is now finished for me.
The project is also part of my subsidiary subject (Media Art) at Hfg Karlsruhe and has kindly been hosted by the Computer Graphics Department of the Karlsruhe University. This post is also mirrored on the official Multitouch360 blog where you can find more pictures of Thorsten and me building the thing.A friend recently had a problem with a cameras flash card that had become unreadable after he pulled it out of his computer without unmounting properly first - the FAT file system had become corrupted and his images had become unreadable.
Luckily, he found saveimg, a tool to restore pictures from broken FAT file systems. Annoyingly, this tool only deals with JPG files, and his camera is a NIKON cam that takes picture in Nikon RAW (NEF) format.
I modified the tool to deal with those, in addition to dealing with JPG files, just like the original. Usage is the same as the original saveimg, read up on how to use it there.
neingeist posted a photo:
Every week, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Der dritte Punkt aus "interner Blogumbau" ist mir mittlerweile dann doch auch wieder eingefallen, ich wollte die Domain anpassen. Das habe ich nun lange genug vor mir hergeschoben, insbesondere da ich dies auch immer als Grund vorgeschoben habe, eigentlich vorgesehene Einträge doch nicht zu schreiben.
Naja, nun ist es geschafft, das Theme ist auch erstmal gewechselt, auch wenn ich eigentlich kein Fan von fixen Breiten bin, da muss eindeutig nochmal nachgebessert werden. Soviel erstmal hierzu.
Die alten URLs sind erstmal noch komplett gültig, zumindest gibt es keine Fehlerseiten, sondern sie werden per '301, MOVED PERMANENTLY' auf die neue URL weitergeschickt. Irgendwann wird dann wohl auch mal der Feed durch ein hartes "Hey, schau mal da drüben!" ersetzt, bis dahin vertraue ich erstmal auf die Kooperation der Leser.
Every week, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every week, a quick writeup of what we were up to.
Wesen:
see you next week!
Spätestens seitdem ich auf dem Rosinenkalb meiner Freundin saß, war mir klar, dass ich auf der CB500 nicht unbedingt glücklich werde, und etwas enduroesqueres her muss, am besten in etwas leichter und etwas gelendegängiger.
Als brauchbare Schnittmenge von Preis, Gewicht, Leistung und Verfügbarkeit fiel der Fokus recht schnell auf die DR350, welche mit ihren 30PS auf 140kg auch gerade noch in der Stufenführerscheinbegrenzung von 0,16 kW/kg Platz findet. Als ich dann erfuhr, dass eine mit bekannter Vorgeschichte sowie allen mit vertretbarem finanziellen Aufwand gemachten Verbesserungen zum Verkauf stand, war es eigentlich nurnoch eine Frage des wanns, bis sie meine ist. Und durch die Absenz eines E-Starters ist jedes losfahrenankicken auch ein Ereignis für sich, auch wenn sie sich hierbei erfreulich zickfrei verhält.
Every week, a quick writeup of what we were up to.
Wesen:
see you next week!
Every week, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every week, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!

In this modification of the KPR-77 'ultimate' mod series we will be discussing how to modify the unit to have trigger outputs. Trigger outputs can be interfaced with modular gear or other instruments that have trigger inputs, such as analog drum units.
Extracting the trigger outputs is quite easy on the KPR-77. Locate the PCB labeled KLM-448 and unscrew the four screws holding the board in place. Detach the two ribbon cables and flip the board over. The pin on the top ribbon cable closest to the center of the machine is ground. Depending on what kind of jacks you use, you may need this. If your devices use banana jacks, you can omit ground but you will need to connect ground by some other means (like running an audio cable to the modular as well). If the device you want to trigger has 1/8” or 1/4” you will need to connect ground. In order, from ground over the outputs are (drum names and abbreviation used in the diagram): Clap (CLP), Closed Hi-hat (CH), High Tom (HT), Low Tom (LT), Open Hi-hat (OH), Cymbal (CY), Snare Drum (SD), and Bass Drum (BD). On the KPR-77 the Cymbal and Clap share the same trigger buttons but are swapped when creating a pattern. This is why you can only have one outputting during a pattern. When I installed the trigger outs on my unit I fixed a small breakout box to the left side of the KPR-77 and mounted the outputs in the box. There may be enough room within the KPR-77 to mount the trigger outputs on the unit itself-- this is up to you. It should be noted that these triggers are positive going pulses, so if your unit needs negative going triggers, this modification won't work. You can extract negative going triggers from the IC's on the KLM-448 board, but since I don't have a use for these I haven't written about them.
Now you can enjoy the KPR-77 with your other gear without having to use just the two tom outputs.
Keep checking back for more KPR-77 Modifications!
This article describes how to render a ridicuously large 500 Megapixel Buddhabrot with iteration depths in the range of millions. Lisp source included. Scroll down for the final image.
Why would you want to do this? To have it printed and on your wall, of course (see pictures below).
I will begin by outlining the general idea of the Buddhabrot (see the Wikipedia article for more), then talk about my optimizations and rendering choices.
The Buddhabrot
You need a maximum iteration depth n (sometimes called the Dwell Limit) because many samples will be within the Mandelbrot Set and you would run the iteration indefinitely for those. Whenever the maximum iteration depth is reached, the sample is considered to be inside the Mandelbrot set - although it possibly isn't and after another 1000 Iterations it would have escaped. There is no way to be sure.
We now consider only those samples "good" whose iteration escaped before reaching the maximum iteration depth, i.e. those who are definitely outside the Mandelbrot Set. Each good sample gives a set of points whose magnitude is equal to the number of iteration steps i that it took for us to find out that it was outside the Mandelbrot Set. Sometimes this is a very small number like 2 or 3, but samples nearer to the border of the Mandelbrot Set take much longer. A sample can take thousands or millions of iterations before escaping, thus leaving a much larger footprint in the resulting point cloud. It seems that for each Natural Number n there is a sample that takes at least n iteration steps, although for higher values of n it becomes harder and harder to find one.
Deep Iteration
It has been observed by many people that just rendering the Buddhabrot like this - using all the escaping samples' visited points - gives a nebula-like image but that a more interesting image can be made by considering only those samples as "interesting" whose iteration time i exceeds some minimum iteration time k with k < n. For example, you could use k = 1000 and n = 10000, i.e. keep only those samples that do not escape before their 1000th iteration but do escape before their 10000th iteration. I you look at one of those more deeply iterated good samples' visited path in the complex plane you will note some pattern: it forms some kind of orbit, sometimes some kind of circle or a set of circles or other shapes. I have no idea why the orbits are shaped this way and i don't know if anyone else does. Here is a part of the orbit of the sample -0.9114822433916717 + 0.2523940788714053i, for example (containing nearly five million points):
Incidentally, all interesting samples like this one are located very very close to the border of the Mandelbrot Set and make good targets to zoom into with your favourite fractal explorer. Try it.
Since the longer orbits look nice we will try to find only "interesting" samples that take a long time to finally escape. There have been several approches to find them. The most obvious one is of course just choosing a sample randomly and seeing how it goes, which means throwing away something like 99.999% of them. You could also use a regularly spaced grid of samples which basically means the same. The interesting samples are all located near the Mandelbrot Set's border, so there must be some spatial pattern to their distribution which might help us find them. If you ever played around with the Set a bit you probably know that the border is infinitely long and calling it "complex" is a bit of an understatement, but surely we can do better than just randomly sample the plane?
Optimization
Since we still choose our samples randomly, every rendering will look different - depending on which orbits your random search finds. There is no "the" Buddhabrot. This also means that the image is not symmetic on the small scale which is a good thing if you ask me. You could of course get a symmetric image of the same quality in half the time by mirroring it, but i think it's worth waiting for the asymmetric one. On the right is a part of the final rendering that exhibits superficial symmetry, but is composed of asymmetric orbits. Click it to view this detail in the final resolution.
If i had had my renderer run for much longer (maybe a week or a month), more and more orbits would have shown up, occluding each other and finally blurring the whole thing into the standard nebula-like buddhabrot. The key is to render just long enough until a sufficient amount of orbits have appeared and then stop.
Lisp Implementation
The renderer is written in Common Lisp which is not your classic number crunching language. If the goal was to do it as fast as possible, you'd probably end up doing it in C with inline assembly or on the GPU. On the other hand, i had never really optimized any lisp code to the limit and wanted to do just that: see how far you can get. One long night of low-level optimization at entropia with the help of some friends later there was is only a factor of 2 left compared to the C implementation that one entropian made. Which is quite okay, considering the cumulative speedup of about 2000 compared to my first implementation. Trading of sbcl's builtin complex numbers for traditional pairs of floats, declaring all types, working in-place instead of on the stack, considering cache efficiency, prompting usage of inline arithmetic instead of jumps to costly sbcl functions, etc. gained us a factor of about 3 to 5 while the big rest was due to the algorithmic improvements.
The renderer uses double-floats throughout. I think i can safely say that the orbits' shapes are not due to cumulative floating-point errors (which i had suspected at some time) because tiny variations in the starting value usually do not produce significantly different orbits. Orbits are not chaotic systems.
Since tracing the few good samples is quite cheap compared to finding them, the renderer first multithreadedly collects some good samples by randomly sampling from the grid cells (see optimizations above) and only afterwards processes them to keep track of their jumping around on the complex plane. Their path is recorded in a big 16bit greyscale image which is repeatedly written to disk.
Postprocessing, Color and Noise
Converting this greyscale HDR image to a LDR image with color has to be done by hand which is a nontrivial task for most image manipulation programs because 20000x25000 is not exactly your standard image resolution. Gimp and Cinepaint both crash or freeze (and Gimp can't handle 16-bit images), but Photoshop worked for me. I also cheated a bit by gently surface-blurring the image, removing some noise.
The noise is the only reason you need the really large iteration depths in the range of millions that i used. If you increase both the minimum iteration time and the maximum iteration limit, your orbits will consist of more and more points, allowing you to choose a higher resolution. If, on the other hand, you get less than, say, five hits per pixel in the darker regions of the orbit you will start to notice that some pixels may get only two hits and their neighbour pixel may get ten hits which will be visible as noise in the output image. If you iterate more deeply, this effect evens out and the signal-to-noise ratio increases. To remove noise, you can always downscale the output image or, as i did, selectively blur the image a bit to improve the look of the noisy areas.
For the output image that i consider the most successful one i used a minimum iteration time of 1000000 and a maximum iteration depth of 5000000. it took about 16 hours on my university's 8-core Xeon machine which i abused for this task overnight.
Results
Here is a scaled version of about 5000x6000 pixels for your firefox's non-crashing convenience.
I am quite satisfied with the digitally printed one as well, although some of the darker reds lose their saturation.
Do not open the large image in your browser. It is a 93MiB JPG file of 20000x25000 pixels which consumes 1.5 GiB of RAM when opened. Don't try this at home. I warned you.
You can also have a look at the Lisp source.
A selection of videos for your wednesday morning. By way of moxlust comes this nice minicommand unpacking video:
And here is a nice trailer for the machine-project from elektron-users, machinedrum and monomachine oriented tracks by fellow forum users. Check it out at machine-project.com.
Starting this week, every saturday, a quick writeup of what we were up to.
Wesen:
Ruin:
Next week will show a few more "concrete" results! :}
Introducing the first Ruin&Wesen audio effect VST: MBD. Simply Multi-Band Distortion. No special name for it. Three bands of distortion split into low, mid and high bands. The processing is in stereo and each band has an 'offset' knob, which offsets the cutoff the left and right channels filter cutoff for each band individually. This can create some interesting stereo effects to widen mono signals. Along with the 'offset' knob, each band also has cutoff, volume and gain. The distortion type is very digital and creates some really interesting sounds. As always we will be releasing this VST with the source files, which were put together in SynthMaker. Please enjoy.
Every saturday (actually, we've been slipping up on that, due to extensive travel), a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every saturday, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every saturday, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every saturday (or... sunday), a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!

This week, Ruin brings you the beginning of a series of blogs about modding the Korg KPR-77 into a badass TR-606/808 killer.
When I first came into contact with this drum machine, I noticed several things about it that were severely lacking. First of which being the bass drum. When I heard that damn bass drum, I thought of someone punching a cardboard box. That thing has too short of decay, and the pitch is too high for my taste. On top of that, there is not much punch to the drum. All of this adds up to a severely anorexic kick drum. When half your time with a song is spent tweaking the sounds, this kick drum can really get you down.
This is probably the hardest set of mods to perform on the KPR-77 in this series, but as you will see, it is still extremely easy to perform.
A little background first on the type of circuitry used in the KPR-77: the drum 'shell' sounds in the KPR-77 use what is called a Twin-T, or Ringing Filter network. These networks are extremely common in analog percussion units, ranging from those found in old home console organs to even the mighty TR-808 and 606. These circuits are filters with very high resonance, almost to the point of self oscillation, dampened only slightly. Sending a short pulse to the input excites the filter, causing it to ring. This provides an excellent and sexy percussion sound, with a nice natural decay. However, these circuits are quite a bit touchy-- if you increase the pitch, be aware that the decay also increases, so take caution when tweaking the sounds because you can get some wild, unwanted oscillations sometimes.
Okay, open up that KPR-77 and locate the KLM-416 board. It will be where the mixer section is, on the top half of the KPR. The top right corner is where the bass drum circuitry presides. You will need to unscrew this board. On the component side of the board locate resistor R37, and de-solder one leg of the resistor so that the resistor is now out of the circuit. Solder two wires on either side of R37 to connect to a pot. This pot should be linear response, and somewhere around 5-8k, the one I used was measured at almost 8k. You may also want to put a trimmer on one leg of the pot and tweak it to a region you find suitable. I found this trim pot useful. Refer to the picture for these spots underneath the board. The other pot will be a linear 10-15k pot, connected as shown in the picture. You may also want to use a trim pot on one of the legs of this pot as well. The upper region is quite touchy, as you might find. You will notice these values are a bit loose. I like to work with what I have on hand.

This part of the mod can be skipped if you don't have a modular or something to provide an envelope or control voltage. This part will utilize a vactrol, as discussed in one of our previous technical blogs. Attach the LDR legs of the vactrol to the two legs of the pot, before the trim pot if you add it. Simple, isn't it? This will be used as a decay envelope for the bass drum to give it a nice oomph. This could probably be achieved some other way, but I don't care, man. This also lets you use an lfo, or even a sequencer on the bass drum for some interesting effects.
A question may arise, 'how can I sync up an envelope or sequencer to the bass drum?'. Well, we will also add a trigger output! Locate the board that is sitting on top of the board covering the bottom half. This board should be brown instead of green. Here is where the triggers come in from the CPU. There is a ribbon cable that goes from the top half of the board, to this board. Locate the sixth pin from the left (if you are looking at the KPR-77 from the front). This is the trigger for the bass drum. Unscrew the board, and solder a wire to this pin. Solder a wire to ground as well. You can attach this trigger to whatever kind of jack you would like. I use banana jacks in my modular so that is what I chose for mine, but 1/8” jacks may be more useful for you-- it all depends!

This mod is only the first in a series of mods for the KPR-77. If you want to mod the F$$K out of your KPR-77, I suggest you create a breakout box. A large one. Large enough to hold at least 14 pots. Thats right, 14 pots! There's more that can be done, but that's what I used.
This video has better bass than the second, showcasing the bass drum a bit more with an envelope from my modular going into the pitch input. DAMN.
Check back later for the next installment of the KPR-77 Mod series!
Today at RuinWesen we bring you another technical blog. This time, we will be discussing the construction and applications of a Vactrol. A Vactrol can be thought of as a very simple way of getting voltage control into a circuit. The Vactrol couples an LED (Light Emitting Diode) with an LDR (Light Dependent Resistor) to provide a conversion from voltage to resistance, which allows easy integration into a circuit such as a guitar effect pedal.

The basic components you will need for the assembly of the Vactrol are:
These are the basic components you will need. Other useful components may be a jack for the incoming signal, or a 50k potentiometer for a 'depth' control.

Now that these components are all wrangled up, sit them down on the bench (or suitable working surface- the floor or back of the nearest person will do fine) and get to it. Shrink tubing is preferable to electrical tape since it will have greater isolation from external light. It is also just easier and quicker to use, dammit! But I will understand if you can't get any in your town, if you are too poor to buy it, or if you lack the balls to steal it*. If you have some shrink tubing, please skip to chapter 9. This here is for the electrical tape losers. (Seriously, if you are going to be building more than one Vactrol, get yourself some shrink tubing.) Okay, grab your electrical tape, LED and LDR. Put the LED and LDR ass to ass (or face to face? I just wanted an excuse to say ass to ass). Once in the position, begin wrapping the tape around the pair several times so that they are snug in their sticky blanket. Okay, this is getting creepy. I probably should have never mentioned ass to ass! Make sure the legs of both are separated so they do not cause a short when wrapped. Now, begin wrapping some tape between the legs to seal off any further light from getting in. Make sure the enclosure is sealed well. Add some more tape if you want to.

Grab the shrink tubing, LED, and LDR, and put the LED and LDR face to face. Slip a suitable length of the shrink tubing on the two and apply some heat. Done. See, you electrical tape losers?! It's that easy. No nightmares about naughty electrical components.
Once your LED/LDR combo package is complete, you will need to solder on the resistor. This resistor is important since it prevents your LED from dying a horrible death. Would you like to be killed by electrocution? Neither does the LED. Identify the anode of the LED, which is the longer of the two leads. Clip the leads of the resistor and the anode to a suitable length and apply some solder. That's it! Now, some fun!
Do you have a favorite delay pedal but wish it could be adjusted from your modular? Well you are in luck, fine citizen. With your newly constructed vactrol, you can open up your delay pedal and apply the leads of the LDR end to the delay time potentiometer. Stick some wobbly voltages into the LED side and BOOM, chorus! This is where a depth knob voltage divider comes into play nicely.
Vactrols are also well suited for circuit bending. If you have a pitch mod, you can now add external control of the pitch so you can sequence your toy with your music without having to resort to sampling.
There are really many ways that a Vactrol can be used. Think of the vactrol as a replacement for potentiometers, or place them across currently existing potentiometers.
I hate to get you down, but Vactrols aren't perfect as you may have already noticed. They are a bit slow to changes in voltage. This is known as Slew. They are also a bit tricky to tune properly and are best left for quick and dirty methods of control voltage. Do not expect to use them as a 1V/Oct control of your circuit bent creation without a considerable amount of effort put into it. With that said, even the man himself, Don Buchla, used Vactrols to control some of his synthesizer modules. So I say, if they are good enough for him, they are good enough for me.
*RuinWesen does not support the theft of shrink tubing, or any object for that matter.The last 4 months, and in particular the last 5 weeks, have been quite intense for RuinWesen. A lot has gone on and a lot of problems have become painfully acute. We would like to take this time to fill you in on what has been happening and what we have planned for 2010.
Ruin and Wesen was started quite quickly and eagerly by us both, without having ever met except over the internet and webcam. A lot of people started asking us for our electronics devices, and we realized that in order to distribute them in a meaningful way, we had to start a company. Of course, none of us (Wesen coming from programming, Ruin coming from analog DIY electronics) was quite aware of the amount of work involved in building products in an industrial, professional way, and we made up a lot of things as we went. We are quite satisfied with the results, but we have to admit that we made our fair share of mistakes along the way.
The main mistake was probably to be too focused on the products themselves, and not on our customers. As we are users as well, we see all the cool possibilities of opensource controllers and opensource synthesizers, and of course talk about them. People pick up on that, and of course when we realize that we don’t have the time nor the resources to implement them, they get disappointed. Another “mistake” is not realizing that the setup costs involved in building batches of hardware are awfully high compared to software development or kits for example. This caused us a lot of trouble as well (a batch of minicommand requires setup costs of about 12000 EUR).
These issues and their consequences are what led to the prolonged “pause” since end of 2009, that you may have noticed on our blog and on twitter. This thinking time was necessary to rethink the concept of our company through, and work out carefully the steps needed.

In 2010, Wesen finished the second batch of Minicommands, and shipped them out to Europe. The orders from Australia and the United States were meant to go out in a grouped shipping, which had to be cancelled because of changed customs regulation. The bureaucratic side of it is now resolved, but this is probably the roughest point, as we were constantly losing money on shipping. We are going to take some time to rethink this aspect through, and think about updating the shipping costs and looking for alternative ways to distribute the device.
During this time, no further development of the devices was done, and this is starting to be felt by the users. We are happy to announce that we are now back, and the first steps that are taken is to write up a good FAQ for the minicommand, and finally release the opensource framework including documentation (for OSX and Windows, Linux will have to wait a bit), so that users can finally develop their own firmwares. This is going to happen during May.
We have learned a great deal about manufacturing products while producing the MiniCommands. This was great learning experience for us, as we are new to the game. We are eager to put out the best products that we can, and are actually happy that only a very few Minicommands came back. There are some hardware issues with the first two batches, as they were designed in a semiprofessional way. These issues are going to be fixed in the third batch, and they can be quickly resolved by users themselves. This is going to be documented in the FAQ.

Ruin has been building some very interesting analog synths over the past few months. One plan has been to get into the world of Euro Rack module production. Some prototype modules have been developed for that. There are so many ideas that it is hard to choose just one to focus on, but we think we have found it. Our main focus, for analog synths, is the creation of a unique analog drone/noise synth and effect unit. It is a small, well featured tone generator, with a number of uses and functions. This will serve as a good introduction to the Ruin ideal- simple, easy to use interface with a flexible and versatile synth engine allowing many possibilities. We hope to see this in production soon, but cannot give a solid date as of yet.
Most of all, we have been very happy to have all the support of our customers through these trying times, and hope to bring unique and useful devices to them as the year goes on. We hope to become a source of creativity for the musicians who use our products.
Every saturday, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every week, a quick writeup of what we were up to.
Wesen:
see you next week!
Every saturday, a quick writeup of what we were up to.
Wesen:
Ruin:
see you next week!
Every saturday (this time with a slight delay, sorry about that), a quick writeup of what we were up to.
see you next week!
This week, a short tutorial to explain how to setup the MDArpeggiator patch (also present in MDMonsterNew and MDMonsterMelody). First, make sure your MiniCommand is connected correctly. The left input of the MiniCommand (MIDI connector on the left) should be connected to the output of the Machinedrum. The output of the MiniCommand (MIDI connector in the middle) should be connected to the input of the MachineDrum. Finally, the MIDI output of the keyboard should be connected to the second input of the MiniCommand (MIDI connector on the right).

Switch on the MD and the MC. If they were connected correctly, the MiniCommand should automatically load the current kit of the MachineDrum: it quickly flashes "CURRENT KIT:" followed by the name of the kit). Now check the GLOBAL settings of the MachineDrum. It should send clock information (in SYNC, check that TEMPO OUT is ON, and CTRL OUT is ON). Then check that the BASE CHANNEL is set to something sensible (not --), so that the MiniCommand can receive and send individual track parameter controls. Finally, check that each track is triggered by a note in the MAP EDITOR (if it's not, the MiniCommand won't be able to play notes). Check that the clock input of the MiniCommand is set to IN1: turn off the MiniCommand, hold down the upper left button, and turn it on again. It will go into the clock configuration menu: turn the leftmost encoder until CLK shows IN1. Press play on the MachineDrum, if everything was set correctly, the left LED of the MiniCommand should be blink in sync with the MachineDrum.
Finally, check that the keyboard is set to send notes on CHANNEL 1. Press play on the MachineDrum, select a melodic track with the TRK encoder of the Arpeggiator, and hold down a chord on the keyboard. The MachineDrum should play an arpeggiation on the selected track. If it isn't, that could mean that the notes you pressed were too low or too high for the selected melodic machines (depending on the loaded machine, the range is bigger or smaller).
Now that everything is set, have fun playing crazy arpeggiations. More information about the parameters and individual arpeggiation modes will follow.
Bookmarks is an extension to the Mercurial SCM, which adds git-like branches to Mercurial. The extension is distributed together with Mercurial.
Recently the extension has received a major update. Time to look back.
This is a series of blogposts that consists of three parts:
(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks
I stumbled over Mercurial in August 2007. Back then I had already
used Git for 6 months, but wanted
to try out different distributed version control systems (DVCS).
I soon began to like Mercurial’s approach because of its simple and
intuitive interface and its clean codebase. While playing around
with Mercurial for a few weeks I was content with its concepts.
There was one feature missing
that I really like in Git: git-like branches.
Unlike in Mercurial or in any other version control system, branches in
Git are simply lightweight markers pointing to a commit. Every ancestor of
the commit is considered part of the branch. Back then, this sounded odd to me. Later I realized it was a really good tool to create small local branches. You can create a small branch
for a feature, merge it into your mainline, and remove the branch
without anyone knowing you ever had a branch called
‘stupid-little-feature‘. To make a long story short: It’s a good
idea to have a similar concept in Mercurial, but none existed back in 2008.
In June 2008 I started developing Mercurial References providing lightweight branches similar to those available in Git. Although the initial work was appreciated by the community, it was rejected
in favor of a concept more natural to Mercurial. Matt Mackall, the author of
Mercurial proposed Mercurial Bookmarks.
The concept of bookmarks is easy:
You can bookmark a commit with a unique name. So it’s similar to
a tag, with one exception, a bookmark advanced when you commit.
(Like real bookmarks when you go to the next page).
I wrote an initial version of Mercurial Bookmarks in August, that
was finally accepted in October. This improved git like workflows
in Mercurial but still the implementation was far away from what I
wanted. By adding the notion of a so called “current bookmark”, it
got better. Still bookmarks had one major drawback in comparison
to git style branches. They were local only. There was no way to
push or pull bookmarks.
This was the status for the past two years. I tried to make bookmarks
pushable during this time. A proposal by me how extensions in general
can exchange arbitrary information over the wire was rejected in
early 2009 because it was too unrestrictive for the protocol. A new
concept, so called ‘pushkey concept’ was developed in 2009. This
was discussed and accepted during the Mercurial Sprint in Paris,
January 2010.
Matt Mackall, who now gets sponsored to work on Mercurial,
worked on the initial implementationof pushkey and
pushable bookmarks. And finally after two years of ongoing complains
by people about local-only bookmarks, Mercurial 1.6 will have
pushable bookmarks and introduces a great new concept to exchange
metadata information between repositories.
The next blogpost will show you how to use bookmarks.