• Audio Interface (required to get sound in and out of the computer – preferably a bit better in quality than a soundblaster)
• Reference monitors – Nearfield (Reference monitors to mix on, that work better than your typical logitech speaker sets)
• Midi input devices (Ranging from keyboards, to padkontrollers to synths to fullblown drum kits)
• Midi Controllers (Devices to use when mixing, controlling parameters on software synths)
• Digital Audio Workstation software (DAW) – (Ableton Live, Reason)
• DJ Software (Traktor Pro)

I’ve spent a reasonable chunk of time setting all this up last weekend. Continue onwards for the progress report.

As my main sequencing is done in a free version of Ableton live (which came with some hardware), which I augmented with a library of free VST instuments I need a proper audio interface with low-latency drivers to work with. Until now, I used an old X-Fi soundblaster, but that just doesn’t cut it anymore. Also, me using low-class Logitech speakers to mix on wasn’t really helping much. Although I didn’t own a lot of hardware, I managed to compile quite an extensive library of samples (from records I own, and loads and loads of free samples from the net) so I have enough stuff to work with.

I reserved a vacant room in my home for this, and decided to move a pc from the office to the aforementioned room. I then started setting up the main parts of my previous setup, the Korg K25, the Korg PadKontrol, the M-Audio Axiom 49, and finally my Frontier Design AlphaTrack. This pretty much ate up all my available USB ports. Also the PSU wasn’t strong enough to power all this hardware using USB so a few universal power supplies happily came to the rescue.

So, next up was extending this already quite luxurious setup to create the studio I always wanted (but on a budget ofcourse – tight budget even).  What I decided I would ‘need’ (want) was a reasonably priced audio interface with balanced outputs, USB connectivity (as I would be using a pc that didn’t have firewire) and a decent set of inputs. I guessed I would need two at most so when I came across the Focusrite Sapphire 6 USB audio interface, I figured it would fit the bill. Reviews of this device are all pretty positive, so I can hardly go wrong with this one, can I? I’ll have to wait for it to arrive before I can give any proper feedback on its performance, but I’m pretty sure that it will outperform my Soundblaster X-Fi with ease. A good sounding audio interface needs decent quality studio monitors to reach I potential, I figure. That’s why I went to the nearest Feedback store to listen to some of the available monitors. At first I read some reviews on the KRK Rokit 6/8 monitors that were supposed to be pretty decent, but after listening to them in the store I felt they lacked mid-range. The guy assisting me in the store advised me to listen to Adam a5x monitors, and they sounded really good. Really solid rounded sound with plenty of low and mid and not to much high. Apparently I’m not the only one hearing the quality in these monitors, as they are pretty hard to come by. I contacted the guys at Feedback if the slightly bigger model would be available, the Adam a7x. I might just decide to go with that set. They look better than Rokit’s as well, nice added bonus.

I’ve had an old microphone for ages, which I used to sample household items and appliances with. It was rubbish and the sound quality was pretty awful. As I do not require a high-end microphone for recording vocals, I decided to go with a budget version. The MXL DRK Desktop Recording Kit comes with a decent little stand, can operate on phantom power delivered by the Focusrite audio interface, isn’t too expensive and gets reasonable reviews. I might have to add a pop-filter to the set, but I’m guessing this will do nicely for my intended purposes. In the reviews I’ve found covering this mic I noticed that recording instruments and vocals also yield decent results, so who knows I might be doing something with that as well.

Recently I finally got to purchase something I’ve wanted to own ever since I was a kid, which is a proper drum kit. As I don’t have the money to live in a villa where no-one can hear me make noise, I had to go with an electric one. The Roland TD-9K felt like a good-featured kit to me, so I bought it. I haven’t regretted the purchase for one second. I previously played my drumtracks on my PadKontrol, but I since then moved to the midi-out capabilities of the Roland kit. A lot of fun to play. The PadKontrol is now mainly used for audio triggering.

The stuff I jotted down here pretty much makes up a decent home studio on-a-budget, I guess. The one last thing I had on my list was that I still wanted to learn how to DJ. I didn’t want to invest in decks and mixers and such, and decided to go with software DJ-ing. Native Instruments Traktor is a good offering in that respect, and when I was looking into that I noticed a pretty cool new hardware controller by Native Instruments. The Traktor Kontrol S4 not only looks the part, but also boasts a pretty decent set of features. Techzine Engadget posted an interesting review of the device, and after looking at some video’s of this puppy in action I decided I should add this to my gearlist as well.

After writing this bit of proze, I went ahead and purchased it all. All is ready to get to work, now all that’s needed is some inspiration and free time. Both are pretty sparse at the moment. Best get started on the plugin installs…

Quite a few sources on the net have already posted their comments on this new Android release, ranging from potential iPad killer to absolute rubbish. I’ve been taken with Android since it was released so I can’t claim to be unpartial but I’m definately impressed by the way it looks. Screenshots are everywhere on the net, have a look and judge for yourself.

Also, Google released a Honeycomb Preview Video that quite clearly shows the immense progress they’ve made with the Android platform. It’s really starting to look like a proper tablet OS.

SDK

As a Java developer that’s interested in development for mobile platforms, I can’t wait to get started with this. Luckily the Honeycomb preview SDK has been released so I had the opportunity to play around a bit. Although the emulator is quite tardy the overall experience is pretty impressive. Android looks very good and is optimized for tablet usage. Let’s hope Motorola and Toshiba get their devices on the market soon so I can start coding my first prototype tablet apps. It’s still early days for the emulator but I’m guessing the final version is just around the corner.

The SDK is available from the Google Android developer site.

Reviews

A good article about the new SDK can be found here. The article also describes the developer point of view and is quite thorough. Nice read.

If you are new to tablets and are still thinking about buying an iPad – hold off for a while. Wait for the new Android tablets to drop. You may change your mind about Apple’s baby after all…

As with most of things IT related it didn’t all go according to plan. The RestTemplate I used didn’t support the gzip stream that was returned by the REST service published by Discogs. So how to fix this? There are two ways.

Firstly, you can use the exchange method included in the RestTemplate. I personally find this approach a bit verbose. Here it is:

HttpHeaders headers = new HttpHeaders();
headers.set("Accept-Encoding", "gzip,deflate");

T response = getRestTemplate().exchange(url,
					HttpMethod.POST,
					new HttpEntity<String>(headers),
					responseType).getBody();

A nicer solution (as far as I am concerned) is extending the RestTemplate to create a GZip enabled template. Stephan Oudmaijer provided me with this code which I found pretty useful. In the code it’s more obvious you are using the resttemplate with gzip support, and you don’t have to change any code if you need the standard RestTemplate. It is somewhat less verbose than using the exchange method.

package org.walgemoed.util;

import java.io.IOException;
import java.net.URI;

import org.springframework.http.HttpMethod;
import org.springframework.http.client.ClientHttpRequest;
import org.springframework.http.client.ClientHttpResponse;
import org.springframework.util.Assert;
import org.springframework.web.client.RequestCallback;
import org.springframework.web.client.ResourceAccessException;
import org.springframework.web.client.ResponseExtractor;
import org.springframework.web.client.RestClientException;
import org.springframework.web.client.RestTemplate;

/**
 * Fix for missing gzip support in Spring RestTemplate
 */
public class GZipRestTemplate extends RestTemplate {

	@Override
	protected <T> T doExecute(URI url, HttpMethod method,
			RequestCallback requestCallback,
			ResponseExtractor<T> responseExtractor) throws RestClientException {
		Assert.notNull(url, "'url' must not be null");
		Assert.notNull(method, "'method' must not be null");
		ClientHttpResponse response = null;
		try {
			ClientHttpRequest request = createRequest(url, method);
			request.getHeaders().add("Accept-Encoding", "gzip,deflate");

			if (requestCallback != null) {
				requestCallback.doWithRequest(request);
			}
			response = request.execute();

			if (!getErrorHandler().hasError(response)) {
				logResponseStatus(method, url, response);
			} else {
				handleResponseError(method, url, response);
			}
			if (responseExtractor != null) {
				return responseExtractor.extractData(response);
			} else {
				return null;
			}
		} catch (IOException ex) {
			throw new ResourceAccessException("I/O error: " + ex.getMessage(),
					ex);
		} finally {
			if (response != null) {
				response.close();
			}
		}
	}

	private void handleResponseError(HttpMethod method, URI url,
			ClientHttpResponse response) throws IOException {
		if (logger.isWarnEnabled()) {
			try {
				logger.warn(method.name() + " request for \"" + url
						+ "\" resulted in " + response.getStatusCode() + " ("
						+ response.getStatusText()
						+ "); invoking error handler");
			} catch (IOException e) {
				// ignore
			}
		}
	}

	private void logResponseStatus(HttpMethod method, URI url,
			ClientHttpResponse response) {
		if (logger.isDebugEnabled()) {
			try {
				logger.debug(method.name() + " request for \"" + url
						+ "\" resulted in " + response.getStatusCode() + " ("
						+ response.getStatusText() + ")");
			} catch (IOException e) {
				// ignore
			}
		}
	}
}

Some handling is still required, as you can see Exceptions are ignored in this snippet. The highlighted lines show where the gzip accept header is added to the mix in the template. After setting this header the resulting stream will be handled correctly. After using this template I was able to consume the REST services from Discogs.

Would still be nice to see easy gzip support in the RestTemplate by default though. Maybe in the future? For now this will do. For any of you interested in the code to execute searches on Discogs, let me know. I may be tempted to clean up the code and provide a generic API.

I’m glad they finally did though. This album simply is one of the best dance albums I have encountered in quite some time. There is quite a unique diversity in tracks, so it’s not just a compilation of drum&bass tracks. The collaboration with foreign beggars results in familiar sounding tracks, but Giovanca’s appearance on ‘this world’ adds a bit of spice to the mix. Title track ‘Split the Atom’ is my favourite track though, it’s solid buildup and earth-shaking basslines are yet unmatched by any track I’ve heard before. Other favourites include the drum&bass stomper call ‘Stigma’, the whacky track ‘Diplodocus’ and ‘Red Heat’. ‘Alpha Centauri’ is also an excellent listen!

Does this mean the rest of the tracks are just filler? Well, no. There are a few less sparkly gems on the disc, but they are gems nonetheless. Highly recommended!

I did however want the solution to be as hassle-free as possible. Even though it’s contract first, I didn’t want to spend a lot of time messing about with XSD’s and WSDL and decided to try and generate both of these artifacts based on my Java code. As JAXB2 supports annotation based definition of the resulting XML structure I decided to use that framework to fulfil my marshalling needs. Spring-WS integration with JAXB2 is pretty decent, so why not?

Maven2

I’m using maven to manage my dependencies, nothing special there. Additionally, I’m going to be looking to Maven to supply me with a mechanism for generating the XSD and packaging it within the application. First, I’ll start by adding the dependencies.

<dependency>
	<groupId>org.springframework.ws</groupId>
	<artifactId>spring-ws-core</artifactId>
	<version>1.5.8</version>
</dependency>
<dependency>
	<groupId>org.springframework.ws</groupId>
	<artifactId>spring-xml</artifactId>
	<version>1.5.8</version>
</dependency>
<dependency>
	<groupId>org.springframework.ws</groupId>
	<artifactId>spring-oxm</artifactId>
	<version>1.5.8</version>
</dependency>
<dependency>
	<groupId>org.springframework.ws</groupId>
	<artifactId>spring-oxm-tiger</artifactId>
	<version>1.5.8</version>
</dependency>
<dependency>
	<groupId>org.springframework.ws</groupId>
	<artifactId>spring-ws-core-tiger</artifactId>
	<version>1.5.8</version>
</dependency>
<dependency>
	<groupId>org.springframework.ws</groupId>
	<artifactId>spring-ws-support</artifactId>
	<version>1.5.8</version>
</dependency>
<dependency>
	<groupId>sun-jaxb</groupId>
	<artifactId>jaxb-api</artifactId>
	<version>2.2</version>
</dependency>
<dependency>
	<groupId>sun-jaxb</groupId>
	<artifactId>jaxb-impl</artifactId>
	<version>2.2</version>
</dependency>

In this snippet I will assume for brevity that all required Spring 3 libraries have already been added. Drop me a line if you want to know the contents of the complete pom.

Servlet configuration

As Spring-WS works using a servlet to handle requests, the first thing I’ll have to do is set up this servlet. I’m going to handle requests using the /services/ mapping.

<servlet>
  <servlet-name>services</servlet-name>
  <servlet-class>
	org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
  <init-param>
    <param-name>transformWsdlLocations</param-name>
    <param-value>true</param-value>
  </init-param>
  <init-param>
    <param-name>contextConfigLocation</param-name>
    <param-value></param-value>
  </init-param>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>services</servlet-name>
  <url-pattern>/services/*</url-pattern>
</servlet-mapping>

This should allow Spring-WS to handly my requests. Interesting bit of configuration is the usage of the contextConfigLocation parameter. The value is omitted to allow the default contextLoaderListener to pick up the configuration and wire everything together. So, after handling this, next up is the Spring configuration.

Spring configuration

This is where it gets a little tricky. Well, actually it’s not that bad.

<bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootAnnotationMethodEndpointMapping" />

<bean id="marshaller"
	class="org.walgemoed.util.ClasspathScanningJAXB2Marshaller">
	<property name="schema" value="classpath:my-service.xsd" />
	<property name="basePackage" value="org.walgemoed" />
</bean>

<bean
	class="org.springframework.ws.server.endpoint.adapter.GenericMarshallingMethodEndpointAdapter">
	<property name="marshaller" ref="marshaller" />
	<property name="unmarshaller" ref="marshaller" />
</bean>

<bean id="supportcms"
	class="org.springframework.ws.wsdl.wsdl11.DynamicWsdl11Definition">
	<property name="builder">
		<bean
			class="org.springframework.ws.wsdl.wsdl11.builder.XsdBasedSoap11Wsdl4jDefinitionBuilder">
			<property name="schema" value="classpath:my-service.xsd" />
			<property name="portTypeName" value="my-service" />
			<property name="locationUri" value="/services/" />
		</bean>
	</property>
</bean>

Four pieces of configuration are required to publish my services. The first bean I’m setting up is the PayloadRootAnnotationMethodEndpointMapping component. This Spring component will register any classes that are annotated with @Endpoint, and pick up any methods annotated with @PayloadRoot. These methods will define the actual services I am offering. I can still define services without this bean, but that’d mean I have to specify this endpoint manually in my Spring configuration. I’m lazy by nature, so annotating the class should be sufficient as far as I am concerned.

Next up is the marshaller. I’m configuring a custom ClasspathScanningJAXB2Marshaller, which I built myself. It uses the Spring classpath scanning mechanism to look for annotated JAXB2 beans. They then are added to a list of classes that are XML roots. Why use classpath scanning? The default implementation supplied by Spring requires you to manually specify any class that you want to be able to marshal. Again, I hate having to annotate the class AND register it in my configuration so I’m just going to automatically discover and register them.

/**
 * JAXBMarshaller extension that uses Spring API to autodetect and autowire
 * JAXB2 XML root elements. Saves the hassle of having to add them to the Spring
 * configuration manually.
 *
 * Error messages returned by Spring-WS aren't too clear, so welcome addition.
 *
 * @author Jarno
 *
 */
public class ClasspathScanningJAXB2Marshaller extends Jaxb2Marshaller {

	private String basePackage;

	private Logger logger = Logger
			.getLogger(ClasspathScanningJAXB2Marshaller.class);

	/**
	 * Constructor. Applies Spring specific API in order to get the RootNode
	 * annotated classes for JAXB serialization.
	 */
	@PostConstruct
	public void init() {
		logger.info("--- Attempting to scan classpath for JAXB2 annotated elements ---");
		this.setClassesToBeBound(getXMLRootClasses());
		logger.info("--- Scan complete ---");
	}

	/**
	 * Uses Spring classpath scanning implementation to scan for annotated
	 * classes. Classes that have the specific JAXB annotation for rootnodes
	 * will be added to the Class [].
	 *
	 * @return Class array of classes that are annotated as rootnodes
	 */
	public final Class<?>[] getXMLRootClasses() {
		ClassPathScanningCandidateComponentProvider scanner = new ClassPathScanningCandidateComponentProvider(
				false);

		scanner.addIncludeFilter(new AnnotationTypeFilter(XmlRootElement.class));

		try {
			Set<BeanDefinition> components = scanner
					.findCandidateComponents(basePackage);
			Class<?>[] result = new Class[components.size()];
			int i = 0;
			for (BeanDefinition bd : components) {
				result[i] = this.getClass().getClassLoader().loadClass(bd.getBeanClassName());
				logger.info("Found class " + bd.getBeanClassName());
				i++;
			}
			return result;
		}
		// Not gonna happen, we are scanning - not guessing
		catch (ClassNotFoundException cnfe) {
			return new Class<?>[0];
		}
	}

	public void setBasePackage(String basePackage) {
		this.basePackage = basePackage;
	}
}

I just extended the class and am using lifecycle callbacks to find out when Spring has completed initialisation. I also added a basePackage property, which defines the base package to start scanning in. As you can see in the Spring configuration, I supplied it with a value. The package org.walgemoed will be scanned for JAXB2 elements that are annotated as XmlRootNodes.

The third bit of configuration is the Spring genericMarshallingEndpointAdapter. This little beast will wire itself using my newly created marshaller and automatically try to marshal and unmarshal any XML I throw at it. As I have done my very best to auto-register the XmlRootNodes, I think this will work out quite nicely. I’m also adding the XSD to the configuration. I’m not using that now, but you can use the validating property on the bean configuration to have Spring validate the XML against the XSD. This is pretty neat as it will generate specific messages on why your XML isn’t correctly formed.

The final bit of configuration will allow me to automatically generate a WSDL for my services. I’m all for that, as I don’t want to do that manually. There are a couple of settings that are important. First of all, a Soap1.1DefinitionBuilder is used. This will generate a Soap1.1 specific WSDL. This will meet my needs, but if you are looking for Soap 1.2 this is also supported. Not gonna spell it out for ya though . The definition generator takes a few property settings, schema, portTypeName and locationURI. The schema defines the contract for the service, so I’m going to go ahead and add the exact same schema as I did for my marshaller. They should match, right? The locationURI specifies where the service will be deployed. As I’ve configured my servlet to be listening for requests on /services/ I’m using that setting here. Finally, I’m going to specify the name for my services by specifying the portType.

After doing this, and after finishing my configuration the WSDL should be accessible via: http://<server>:<port>/<context-root/services/my-service.wsdl

XSD generation

I still can’t deploy my app though, as I don’t have the XML structure yet. I don’t want that job to be a manual activity, as I don’t want to re-generate my XSD every time the signature of my XML changes. At least, not during development. Good thing I’m using JAXB2, as there is a plugin that will automatically generate the XSD for me, based on the JAXB2 annotations on my classes! I’ve added the plugin to my application and configured it to execute this generation every time I build my project.

<!-- Plugin mojo that can be used to generate XSD files before deployment. -->
<plugin>
	<groupId>com.sun.tools.jxc.maven2</groupId>
	<artifactId>maven-jaxb-schemagen-plugin</artifactId>
	<version>1.2</version>
	<executions>
		<execution>
			<phase>generate-resources</phase>
			<goals>
				<goal>generate</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<destdir>${project.build.directory}/schemas</destdir>
		<srcdir>${project.build.sourceDirectory}/org/walgemoed/</srcdir>
		<verbose>true</verbose>
	</configuration>
</plugin>

This will generate a schema file in the target/schemas folder for my maven2 project. All I need to do now is include it in my application. I used to antrun plugin for maven to do this, but there are many other ways. As you can see, I’m also changing the name. There is another way to do this as well, but hey, this works for me.

<plugin>
	<artifactId>maven-antrun-plugin</artifactId>
	<executions>
		<execution>
			<phase>compile</phase>
			<goals>
				<goal>run</goal>
			</goals>
			<configuration>
				<tasks>
					<copy file="${project.build.directory}/org/walgemoed/schema1.xsd"
						tofile="${project.build.outputDirectory}/my-service.xsd" />
				</tasks>
			</configuration>
		</execution>
	</executions>
</plugin>

Done!

Well, almost. Configuration is done, yes. I’ve set up XSD generation, rigged automatic marshalling with JAXB2, added scanning for root elements, set up the servlet AND pimped my build process. What could possibly be left?

Defining a service: EchoService

Right, I didn’t build a service yet. Usually a service consists of a request and an response. I like this approach so I’m going to be using ServiceRequest and ServiceResponse classes for my service. The request will contain a parameter called echo, and the response is going to echo that same parameter three times. This is a very useful service indeed.

Here’s the request:

@XmlRootElement(namespace = NameSpaceConstant.namespace)
@XmlType(namespace = NameSpaceConstant.namespace)
public class EchoRequest {

	private String echo;

	@XmlElement(namespace = NameSpaceConstant.namespace, required = true)
	public String getEcho() {
		return echo;
	}

	public void setEcho(String echo) {
		this.echo = echo;
	}
}

And here’s the response:

@XmlRootElement(namespace = NameSpaceConstant.namespace)
@XmlType(namespace = NameSpaceConstant.namespace)
public class EchoResponse {

	private String response;

	@XmlElement(namespace = NameSpaceConstant.namespace, required = true)
	public String getResponse() {
		return response;
	}

	public void setResponse(String response) {
		this.response = response;
	}
}

Finally, here’s the endpoint for this service:

	@PayloadRoot(localPart = "echoRequest", namespace = NameSpaceConstant.namespace)
	public EchoResponse echoServiceEndpoint(EchoRequest request) {
		EchoResponse response = new EchoResponse();
		response.setResponse(request.getEcho() + request.getEcho() + request.getEcho());
		return response;
	}

Build, deploy and run your application. If everything was configured correctly, and XSD should be generated based on your request and response classes. After generation, this XSD will be packaged in the deployment and wired to Spring-WS and its marshallers and WSDL generators. Open up the WSDL in a Soap testing tool (such as SoapUI) and fire up a request! If all goes well, you should get an echo of your original inputstring. As you can see, your service is completely written in Java, which means no time spent on manually generating XSD’s, WSDL’s and stuff like that. I really like this approach, it saves me a lot of time during development. Hope this helps any of you guys out there that also don’t like spending too much time on XSD’s and WSDL’s.