Author Archives: Ewald Kegel

Review: Native Instruments Komplete Kontrol

Since some time I felt the need to use a sustain pedal with the MIDI controller I use for recording music. My aging Roland controller never had a problem with a simple ‘Hold’ function, but ‘Sustain’ proved to be to difficult. Some time ago I ordered a B-stock Arturia Keylab, but the quality was so bad I had to return it (which had obviously nothing to with Arturia, but everything with the music shop that send out a product without proper quality control). Some time ago I started reading things about the Komplete Kontrol so that controller had my attention.

There were a few things that made me wary about the Komplete Kontrol. First of all it looked overdone with the two screens and the impressive set of lights and buttons. Most of all I was afraid that I was  buying a potential great product but that when actively using it you run into all kind of problems with incompatible (third party) software. So I might as well have bought a simple MIDI controller. In my opinion Native Instruments makes great software, but its user friendliness and ease of use I do not consider as its greatest features. Anyway, I took the plunge and bought the 49-key model.

Without any doubt from a physical standpoint you can easily see you are dealing with a quality product: the bender. modulation wheel, knobs and buttons breathe quality. The resolution of the two screens do not have an exciting resolution, think early type iPhone. Of course it would be very nice if a future iteration of the Kontrol would see a touch screen for an even more direct way to interact. Also the Kontrol editor for Mac was not “made for Retina”, now I come to think of it I believe none of Native Instrument’s software is.

The two screens of the Komplete Kontrol

The two screens of the Komplete Kontrol

The software installation procedure is simple. In the box with the keyboard you will find a serial that needs to be added in the Native Access software. After that you will be presented with the Kontrol Editor and some -impressive- free additional software like Massive and DrumLab. Through the mail I also received 2 vouchers each worth 25 euro giving you the possibility to buy additional software in the Native Instruments online shop.

After installing the Kontrol editor with its first time use the Kontrol editor scans your PC/Mac for compatible software using the so called NKS format that Native Instruments use to interface with the Komplete Kontrol. It worked flawless with my Arturia software. My Waves software needed a small update and then was flawlessly recognised by Kontrol editor.

The Kontrol is compatible with my DAW (Logic Pro X) but there is a ‘but’. Logic Pro X works smooth with all the control like functions (transport, mixer settings) but it does not support Logic’s plug-ins and effects unfortunately. It would be a great addition if this would become available in the future.

The transport controls

The transport controls

The way it works within a DAW is as follows: you load a Kontrol instrument on a (in my case Logic) track and from there you build up the instruments and effects of choice. So within one Kontrol track you can have a chain of instruments and effects, for example Arturia JUP-8V, Klangheim Compressor and Waves H-Delay. You can choose to make all the settings on your computer screen or on the Kontrol itself, the last option of course being one of the main reasons you bought this controller anyways… Because the number of settings within an instrument or effect can be quite overwhelming you might need to click your way through different screens on the Kontrol to get to the parameter you want to edit in one of the two screens. This can be a bit cumbersome procedure, because the description of the parameters is similar to when you change the viewing Logic’s plug-in window to the Control Editor. Things (the naming of parameters) can be a bit cryptic and it is handy that when you are not sure which parameter you are editing to keep an eye on the computer screen to be sure you are editing the right one.

Where the Kontrol absolutely shines is the way you can super easily choose an instrument of your liking. First you can narrow down your search to the type of instruments (for example ‘Sampled Instruments’ or ‘Drums/Percussion’) and from there you can search foryour instruments and favourite patch. Scrolling through the patches automatically plays something for you, so you don’t even have to worry about pressing keys on the keyboard. Only if you really want to use a patch, you push the Load button. This functionality alone is worth the price of this controller.

For every note there is a little light above the keybed. At first this looked a bit like overkill to me, but when I loaded my first drum instrument it became clear why this is a great idea. Similar instruments have same lights, all Snare drums for example are yellow and all Hihat related instruments have a blue light. This is very handy while software developers of drums software put sounds at more or less random places and now it suddenly becomes clear where the different types of similar sounds are positioned. It is the same functionality that you can see in Kontakt with the keyboard screen and its colorising to indicate the function of the key.

Conclusion

I had my reservations if all Kontrol features should work as advertised. This is absolutely the case. For a company that is known to produce some quite complicated software this is a simple to understand and well working product. The big advantage is in my opinion is the ease to drill down to the instrument and accompanying patch of choice. Putting instruments and effects in a row contributes to more creativity and experimentation than using the computer screen of your DAW. Because working with a mouse is always somewhat cumbersome within a DAW you are more likely to go for the combinations of instruments and effects that you know. I felt that with he Kontrol makes you more willing to experiment. Once you have reached your desired instrument/patch the editing of parameters is less spectacular, yet still preferable compared to mousing on the computer screen. The instrument itself is clearly build with high quality components, so this should give you a long and trouble free experience when making music.

The Hague, 3 May 2018

Challenges of testing when using Scrum

Recently I dived into the merits and challenges of software development (or more generic IT products for that matter) in Agile based settings, in particular using Scrum.  Scrum is one of those methodologies that are part of a wave of Agile based methodologies (LEAN, extreme programming among others) that emerged in the 90’s and in 2001 united for the so called Agile Manifesto. Although Scrum is around for some time, it seems that in recent years Scrum has taken its place in countless organisations as the preferred method of developing software. While studying the Scrum approach I kept a focus on the inclinations for the testing process. I will not go into lengths to give a full description of the Scrum framework in this article but instead focus on possible weaknesses and strengths in relation to the testing process.

A clearly positive aspect of Scrum is that it is not hard to understand. Scrum is defined as a process framework, it does not prescribe an in depth approach on every aspect of the software development. Scrum contains a comprehensive workflow and its own taxonomy (with concepts like SprintIncrementDefinition of Done) is limited. The essential of the Scrum approach could be defined as: transparant software development based on a just-in-time workload, the effort to ensure all involved have a clear picture of the products that will be delivered and the benefit of a team based operation where the group effort is more important than individual success of the team member.

Because the scope of a development iteration (the Sprint) is limited (usually 2 weeks and maximum 4 weeks) the chances of deviation between the mutual understanding of the work to be done and the actual performed work could theoretically not be a too big surprise. Along the path of the Sprint there are mechanisms in place (Daily ScrumSprint Review and Introspective Review) to eliminate risks even further. As -in general- testing activities are based around inventorying and addressing the potential risks, the Scrum approach from a testing perspective is a step in the right direction to deliver quality products.

Yet besides these positive aspects, Scrum also will introduce some trade offs. Before diving into these trade offs, some perspective is needed on how to judge whether something might be considered a weakness or strength when we look at the Scrum process and its intertwining with testing. Over the past decades the most clear contraposition to the Scrum approach of software development has been the waterfall method. The waterfall method implies that there is strict sequential order of activities in the process: it is -for example- uncommon to start coding before the functional and technical requirements are completely set and approved by the stakeholders. An implication of this method is that the time to bring a product to the market might be taking a (too) long time. When the analysis phase within a waterfall project is carried out, internal or external (market) situations might have changed and/or the set requirements have changed. New requirements could be added, old ones could be not longer applicable. In an ever more competitive business world the rise of Agile based methods became new, interesting ways to overcome the waterfall method’s shortcomings. A less positive track record for timely delivered waterfall based projects also contributed to a rise in interest for agile methodologies and Scrum in particular.

Yet for testing purposes the waterfall method unmistakable has its advantages. The well known V-model for testing represents this.

A test strategy could be plotted against the deliverables (or project phases) in the waterfall based project. It gives the test manager time and opportunity to carefully plan and carry out the test strategy, changes never come too abrupt. And if changes come they could be easily adapted into a refined or updated test strategy.

In the Scrum world things work different. The Sprint is short cyclic iteration with a predefined outcome of the Sprint, usually defined as ‘working software’. This approach offers challenges in the testing process. First of all the testing effort has a tendency to become inefficient compared to a waterfall based approach. A test process needs to be in place within each Sprint leading to some inherent overhead (like writing test scripts, setting up test environment, inviting testers for the User Acceptance Test). It is still easier and less time consuming to perform a test process once for a larger number of tasks than numeral times with each Sprint for a specific or small number of tasks. The members of the Development Team (usually between 3 to 9 members) have no specific role within the team and should be able to take on the tasks of another team member. So a team member who develops software should also be able to test the software. This might lead to effects of tunnel vision (approving one’s own work) and a lack of segregation of duties.

The outcome of a Sprint does not necessarily has to be a piece of software that is implemented in the live environment. Preferably it is, but in the Definition of Done it also can be determined that the Scrum Development Team has no role in implementing the software in a live environment. This might be the case when that specific task is to be performed by the IT Operations Department. From a test manager’s perspective this caveat needs attention because it leads to non-addressed risks in the period between the deliverance of the Development Team versus the actual implementation in a live environment.

To overcome these potential trouble with the testing process different ideas have been introduced to deal with potential shortcomings. We will have a look at two of them: Agile Testing Quadrants and Test-Driven Development.

Agile Testing Quadrants

Developed by Brian Marick it places different tests in different quadrants based on their relevance (technology driven versus customer driven, supporting the team versus product critique). An advantage of this visual representation is that the Development Team is aware of the tests that support the quality of their products.

Test automation is an important aspect of trying to solve issues of reducing the testing time it will take from the resources of the Development Team or stakeholders to perform tests. We need to be aware though that test automation is not the ultimate cure for time related issues. Tests have to be coded, so it takes time to complete them before the test automation can facilitate the products that emerge in Quadrant 2. Test ware needs to be maintained as well. For example external factors like an organisation upgrading to a new version of a browser or a fixed security leak need to be taken in account when keeping the test ware up to date.

In Quadrant 4 tests like Performance, Load and Security Testing are positioned. These type of tests require special expertise that is not necessarily available by default within the Development Team. Also the same as for test automation is applicable: the test ware for Performance, Load and Security Tests needs to be initially produced and afterwards actively maintained in order to keep them relevant or simply working in future Sprint iterations/ increments . With Security Tests you might even ask if it is desirable to run these test from within the team due to their delicate nature and from a perspective of segregation of duties.

Test-driven development (TDD) has its origins in extreme programming, an other Agile method. With TDD the developer starts his work by writing the actual test before writing the software code for the product to be delivered. Although TDD has a lot to be said about that goes beyond the scope of the article the clear advantage is that it solves issues raised in previous paragraph. The creation and maintenance of test ware becomes an integral part of the work by the Development Team.

Conclusion
Scrum needs an organisational change of mentality to gain the best results. If only the IT software development is isolated and using Scrum, while other parts of the organisation (Marketing, Finance, Purchase, HR) do not participate, Scrum will be less relevant or even fail to work. But even within the IT department itself the integration of Development Team with the Operations organisation, becomes unavoidable and mandatory to tackle the problem of the possible gap between the Scrum product according to the Definition of Done and the ‘real’ live implementation date.

Test automation is necessary to keep control over the time aspects concerned with testing. But as test automation needs its own level of maintenance it is certainly not the answer to all challenges that the Development Team faces. Especially the tests in Quadrant 4 (Performance, Load, Security) require special expert knowledge that will not always be present by default from the Development Team. If that is not the case it will need to be planned with the required resources and might lead to more planning or product related issues that are difficult to match with the short cyclic iteration of the Sprints.