Pneuman Remix

Vorder maar langzaam met de remix van Pneuman’s Move Along track. Komt vooral door Hydrogen. Goeie sampler, past perfect in m’n workflow maar de tekortkomingen van Hydrogen beginnen me enorm tegen te staan. De irritantste tekortkomingen:

  • JACK transport werkt niet goed, vooral niet icm seq24. Dit ligt hoogstwaarschijnlijk aan seq24 maar dan nog is het hoogst irritant dat Hydrogen vaak gewoon zwijgt zodra je JACK transport start.
  • Toevoegen van nieuwe of het wijzigen van instrumenten is een drama. Ik moet bij het toevoegen van een instrument iedere keer een extra instrument toevoegen anders wordt de poortnaam niet geüpdate. Wat betreft het wijzigen, dan wordt de poortnaam pas gewijzigd na het opnieuw opstarten van de audio engine maar kennelijk op zo’n manier dat JACK er niks mee kan en Hydrogen geen geluid produceert via de hernoemde poorten. Alleen een herstart brengt soelaas maar hoe onhandig is dat.
  • Hydrogen crasht vaak. Vooral met het toevoegen of verwijderen van instruments en als JACK transport loopt kun je maar het beste helemaal niet aan Hydrogen zitten.
  • De sample-editor is fantastisch maar produceert wel ontzettend veel xruns, vooral als je intensief met rubberband aan de slag gaat.

Misschien moet ik de 0.9.6 ontwikkelaarsversie maar eens proberen. De versie die ik nu gebruik beperkt me enorm in m’n productiviteit. En ik heb al niet zo gek veel vrije tijd. Hydrogen is niet de enige applicatie die dwars ligt trouwens. Qtractor knalt er ook regelmatig uit wat waarschijnlijk komt door buggy plug-ins. Ook kan ik de nieuwste versie niet gebruiken omdat de verbeterde VST support iets heeft veranderd aan Qtractor waardoor de MDA JX10 VSTi plug-in die ik gebruik totaal anders klinkt.

Ok, dat is er uit. Heb nog wel wat kunnen doen, heb in ieder geval iets van een coupletje:

Pneuman Remix

Cannot deliver port registration request

M’n Pneuman remix sessie wilde niet meer opstarten, alles deed raar, Qtractor segfaulde, Hydrogen klapte er tijdens het opstarten uit. En ik kon de oorzaak maar niet traceren. Dus dan ga je alles maar één voor één troubleshooten. Uiteindelijk spuugde Hydrogen de volgende melding uit:

Cannot deliver port registration request

Oftewel, Hydrogen vraagt Jack poortjes aan maar krijgt van Jack nul op het orkest. Deze melding nog nooit eerder gezien en Google bracht me ook niet verder. Toch maar even in QjackCtl m’n Jack setup gecheckt. Hmmmm, Port Maximum staat op 256, wat nu als ik deze op 512 zet? Kan het me nauwelijks voorstellen dat ik al zoveel poorten in gebruik heb maar baat het niet dan schaadt het niet. Je raadt het al, sessie start weer moeiteloos op en ik kan weer verder.

Omdat ik toch benieuwd was hoeveel poorten ik nou in gebuik heb met deze sessie heb ik ze even geteld met jack_lsp | wc -l De uitkomst? 258. 258 Jack poortjes in gebuik, net 2 meer dan de Port Maximum van 256 die ik voorheen altijd gebruikte. En het worden er gestaag meer. Gelukkig ben ik gek op spaghetti, zowel analoog als digitaal.

Cannot deliver port registration request

Qtractor en externe MIDI controllers

Maanden geleden een bug gerapporteerd dat bij praktisch elke Qtractor sessie Qtractor op een gegeven moment niet meer reageert op binnenkomende MIDI boodschappen van externe controllers. En kon de oorzaak maar niet vinden en de ontwikkelaar ook niet aangezien hij het probleem niet kon reproduceren.

Totdat Louigi Verona een forumdraadje opende op de site van de ontwikkelaar. Dit was precies hetzelfde probleem waar ik ook tegenaan gelopen was en kennelijk wordt dit probleem getriggered door het niet gebruiken van een specifieke QGtkStyle of het gebruiken van de gtk+ QGtkStyle in Gnome. Met elke andere QGtkStyle, welke je kunt instellen met het qtconfig commando dat in het qt4-qtconfig pakketje zit of op de cli met de -style optie, komt dit probleem niet voor. Ik gebruik nu de -style cleanlooks optie met Qtractor en MIDI verbindingen blijven nu gewoon werken.

Qtractor en externe MIDI controllers

Windows 8 en UEFI

Microsoft heeft het lumineuze idee opgevat om UEFI secure boot te gaan gebruiken voor Windows 8. In het kort, UEFI (gebaseerd op EFI) is de opvolger van het BIOS en heeft een secure boot optie: in de UEFI kun je sleutels instellen en alleen software die digitaal ondertekend is met die sleutels kan draaien op de computer. In het geval van Windows 8 is het hele besturingssysteem ondertekend met sleutels van Microsoft. Fabrikanten die computers willen leveren met Windows 8 voorgeïnstalleerd zullen dus de Microsoft sleutels in de UEFI moeten zetten en secure boot moeten activeren. Aangezien Microsoft de sleutels levert, dus niet een onafhankelijke certificaatautoriteit, wordt het onmogelijk om iets anders te installeren dan Windows 8 op een computer met secure boot. Linux leveranciers kunnen niet aan die sleutels komen om hun software te tekenen dus Linux zal niet booten op een dergelijke computer. En al zou men de beschikking krijgen over de sleutels dan zou dat betekenen dat er non-GPL bootloaders gebruikt moeten gaan worden, ondertekend met de Microsoft sleutels. Leveranciers zouden ook self-signed software kunnen gebruiken, maar dat zou betekenen dat computerleveranciers ook al deze sleutels zouden moeten toevoegen aan de UEFI. Een andere mogelijkheid zou zijn dat er een optie in de UEFI wordt toegevoegd om secure boot uit te schakelen. Maar veel hardware leveranciers willen hun firmware zo simpel mogelijk houden en er bestaat dan ook een grote kans dat op veel computers deze optie zal ontbreken.

Iets om je druk over te maken? Ja en nee. Ja omdat het de eindgebruiker dwingt Microsoft producten te gebruiken, de gebruiker heeft niet meer de keus iets anders dan Windows 8 op zijn computer te installeren. Nee omdat het waarschijnlijk niet zo’n vaart zal lopen (Microsoft heeft daar wel een handje van), er zeker mensen in het verweer gaan komen die het verplicht willen stellen dat secure boot uitgeschakeld kan worden en nee omdat naar mijn mening de zelfbouwmarkt en de markt van computers die zonder OS worden geleverd een boost zal krijgen mocht dit hersenspinsel van Microsoft echt gestalte krijgen.

Meer informatie:
Blog Matthew Garrett (Red Hat)
Webwereld artikel

Windows 8 en UEFI

Yoshimi 1.0

Na het overlijden van Alan Calvert, de ontwikkelaar van Yoshimi, heb ik contact opgenomen met SourceForge en ze de situatie uitgelegd. Ze hebben me toen project admin gemaakt van het Yoshimi SourceForge project en aan mij nu dus om de toekomst voor Yoshimi deels zeker te stellen. De discussie rond deze toekomst heeft een momentumpje gehad waaruit naar voren is gekomen dat zowel de Yoshimi gebruikers als de huidige ZynAddSubFX ontwikkelaars het liefst zouden zien dat de ontwikkeling van Yoshimi en ZASFX zo convergeren dat ze kunnen mergen tot één project. Maar voordat het zover is komt er nog wel een Yoshimi 1.0 release, gebaseerd op 0.062, maar dan zonder de ergste bugs (zoals de befaamde Heffalump bug die als het goed is nog in 0.062 zit) en met de MIDI learn functionaliteit van Alessandro Preziosi. Hoogste tijd dus om me wat meer te verdiepen in git.

Yoshimi 1.0

JuJu perikelen

Heb me maar eens gewaagd aan het uitproberen van de nieuwe JuJu FireWire stack die de oude ieee1394 stack op termijn gaat vervangen. Dus nieuwste libraw1394 en FFADO versies geïnstalleerd, /etc/modules, /etc/modprobe.d/blacklist-firewire.conf en /etc/default/rtirq aangepast en sudo update-initramfs -u -k all gedraaid. Na een reboot wat projectjes opgestart en helaas, heel veel xruns. Als er goeie pakketjes zijn van de nieuwe 3.0 realtime kernel probeer ik het wel weer eens. Voorlopig blijf ik met de oude FireWIre stack werken.

JuJu perikelen

Nieuwe release RT patchset

Ook al zijn forced threaded interrupt handlers inmiddels onderdeel van de mainline kernel (vanaf 2.6.39), neemt niet weg dat er nog het nodige verbeterd kan worden aan de real-time performance van recentere kernels. Thomas Gleixner en co. hebben de aankomende release van de 3.0 kernel aangegrepen om met een nieuwe release van hun real-time patchset te komen. 3.0-rc7-rt0 is inmiddels beschikbaar en de eerste reacties zijn postief.

Nieuwe release RT patchset

amSynth Galore!

Eigenlijk moet ik gewoon meer muziek maken maar dan zie ik m’n BCR2000 staan naast m’n scherm met de laatste beta van amSynth erop die je kunt skinnen en dan ben ik alweer afgeleid. Oftewel, heb een amSynth skin gemaakt voor gebruik met de BCR2000.


text-align: center;

amSynth 1.3 beta 2 met BCR2000 skin

amSynth zelf is inmiddels bij de tweede beta van de 1.3 release aangekomen. Zowel deze beta versie als de BCR2000 skin staan in mijn PPA. De skin staat trouwens ook op mijn Sourceforge pagina. Daarnaast heb ik de laatste git versie van de amSynth DSSI plug-in geüpload naar mijn PPA aangezien de plug-in uit het eerdere pakketje de boel liet crashen op sommige 64-bits machines.

amSynth Galore!

TYOQA is aangebroken!

The Year Of Qtractor Automation is aangebroken, oftewel Rui, de ontwikkelaar van Qtractor, is begonnen met het implementeren van automatisering in Qtractor. En het ziet er goed uit, het werkt goed en het voelt goed. Dat laatste klinkt misschien vreemd maar zulke ingrijpende veranderingen aan een applicatie die je bijna dagelijks gebruikt kunnen je ook tegenvallen of je zelfs tegen gaan staan.


text-align: center;

Qtractor hoofdscherm met MIDI track en automatiseringscurve

En op de een of andere manier voelt de manier waarop Rui dit implementeert bijna als vanzelfsprekend. Ik kan er gelijk mee overweg, begrijp hoe het werkt en zie van allerlei mogelijkheden die deze functionaliteit biedt voorbij trekken in m’n hoofd.

Gebruik je net zoals ik Ubuntu Lucid Lynx 10.04 dan heb ik goed nieuws, heb een Qtractor-SVN PPA opgezet waarnaar ik m.b.v. een script nieuwe bronpakketten upload zodra er aanpassingen zijn in de SVN trunk:

#!/bin/bash

MAINDIR=$HOME/PPA/qtractor/daily-builds

SVNREV=$(svn info https://qtractor.svn.sourceforge.net/svnroot/qtractor/trunk
| grep Revision | cut -d " " -f 2)

CURRENTREV=$(cat $MAINDIR/current.rev)

if [ $SVNREV = $CURRENTREV ]
 then echo "Current build is up to date."
 exit
else
 echo $SVNREV | tee $MAINDIR/current.rev

 VERSION=$(svn cat
https://qtractor.svn.sourceforge.net/svnroot/qtractor/trunk/configure.ac
| grep AC_INIT | cut -d " " -f 2 | cut -c 1-8)

 SVNDIR=$MAINDIR/qtractor-$VERSION+svn$SVNREV

 svn co https://qtractor.svn.sourceforge.net/svnroot/qtractor/trunk $SVNDIR

 rm -rf `find $SVNDIR -type d -name .svn && find $SVNDIR -type d -name debian`

 cp -a $MAINDIR/debian $SVNDIR

 cd $SVNDIR

 dch -v "$VERSION+svn$SVNREV-0lucid0~autostatic0"
 "Daily build, Qtractor SVN trunk checkout $SVNREV"

 rsync -av $SVNDIR/debian/changelog $MAINDIR/debian/changelog

 debuild -S -sa -k12345678

 dput ppa:autostatic/qtractor-svn
 $MAINDIR/qtractor_$VERSION+svn$SVNREV-0lucid0~autostatic0_source.changes

fi

TYOQA is aangebroken!

aj-snapshot

Met aj-snapshot van de hand van Lieven Moors kun je een snapshot maken van de actieve ALSA en JACK connecties. Heb een bronpakketje geüpload naar mijn PPA en aj-snapshot pakketjes voor Ubuntu 10.04 zijn dan ook inmiddels beschikbaar. Heb deze tool zelf nog niet gebruikt maar ga dat waarschijnlijk wel doen, het lijkt me toch wel een erg handige command line tool om JACK en ALSA connecties te herstellen en op deze manier hoef ik dat niet meer zelf te scripten met aconnect en jack_connect regels.

aj-snapshot