White.Steve.Blog : Software

Sparkle, development teams, and what ‘no code’ means

stevewhitepsfd — Thu, 06 Oct 2005 07:07:00 GMT

Microsoft Expression “Sparkle Interactive Designer” (Sparkle for short) was announced and demonstrated at the Professional Developers’ Conference in Los Angeles last month. To find out what this powerful tool is all about, see the Expression Home Page, the Sparkle Team on Channel9, and Eric Rudder’s PDC keynote.

So, what is the Sparkle tool good for and who will use it? Well first of all, if you’re evaluating the Windows Presentation Foundation (WPF) today, you’ll have noticed that Visual Studio currently has no design surface for XAML source code. In time, Visual Studio will have design support (codenamed ‘Cider’) for WPF suitable for the needs and wishes of software developers. What Sparkle will offer over and above Visual Studio’s WPF designer is a set of features aimed at professional user-experience designers.

The kind of designers I’m talking about have creative and technical skills including graphic design, usability design, and interaction design. The North Face demo (also shown at PDC) is a beautiful and striking example of how WPF brings the development of creative interactions within reach and obviates a specialization in 3D computer graphics.

Developers with design sensibilities will also use Sparkle, just like designers with programming sensibilities already use Visual Studio. These skill combinations are very common – what’s less common is to be excessively talented in both spheres. So Sparkle will not ‘turn developers into designers’ nor ‘require designers to be developers’ but it will give the members of large development teams the opportunity to specialize whilst preserving the MSBuild format of projects transferred between Sparkle and Visual Studio.

Clemens Vasters has written an excellent blog entry about subject-area specialization in which he discusses what he calls visualization developers. Visualization is a component of interaction and the members of this sector of the development team may equally well be called interaction designers and possibly, for the trickier coding, interaction developers.

Which brings me onto what code means and, more importantly, what no code means. The community regularly describes HTML, XAML, C#, VB.NET, etc as code which implies that any formalized, syntactically-constrained encoding is code (whether the logic is declarative or imperative). But often, in demonstrations of WPF and Sparkle, the speaker (myself included!) points out that no code was written and I think this deserves some clarification.

Typing XAML into Notepad or Visual Studio is, arguably, coding and the no code assertion is hard to support. Similarly, a Sparkle project with no code is an empty one. Rather, what’s compelling about WPF is that the semantics of the code is incredibly rich so you need less of it. What’s compelling about designing on a surface in Sparkle or Visual Studio is that the tool generates the code for you. It so happens that declarative code is more practical for tools to generate than imperative code and that a design surface is able, in real-time, to reflect edits to declarative source code whereas imperative source code is built before it is expressed. So it’s likely that great tool support, making XAML so friendly, is the reason we often overlook it as code.

Avalon 3D File System Visualizer (FolderTreemap3D)

stevewhitepsfd — Thu, 07 Jul 2005 20:33:00 GMT

Download the FolderTreemap3D sample

(Requires Windows Server 2003 or Windows XP, .NET Framework 2.0 SDK Beta 2 (or Visual Studio 2005 Beta 2), and WinFX Beta 1 RC Runtimes and SDK)

Ben Shneiderman developed the treemap style of visualization in the early 1990s in response to the common problem of a filled hard disk. For this application, Professor Shneiderman needed an alternative to the incumbent tools (i.e. File Manager and Explorer) which, although strong at quantitative presentation of one hierarchical level of files at a time, don’t offer the aggregation needed for a high-level, qualitative view. A treemap’s strength is the reverse: perspective (or context) is more important than precision. If you’ve ever trawled up and down through the levels of a hierarchy seeking the largest files and folders as candidates for deletion then you’ll appreciate the perspective a treemap gives.

The ‘squarified’ treemap is a refinement which minimizes the aspect ratio of each node rectangle and this is the variation I have used. But with any flat treemap, the depth of hierarchical nesting of a node is not obvious to the viewer. It occurred to me that, if a node’s nesting level is represented by its distance along the z axis, then an orthographic 3D projection would appear to be a flat treemap when viewed from the front but would reveal the spacing along the z axis when rotated. I was also curious to see the same 3D model projected with perspective.

I have used color to distinguish folder nodes (transparent) from file nodes (colored dark in proportion to their depth). Examine the image at the beginning of the post. The entire image is a visualization of the %windir%/Microsoft.NET/Windows folder which contains the Avalon runtimes. What does the image tell us? Well, first (and without having to expand any nodes) we can see that the \Windows folder contains a single child folder named \v6.0.4030 which in turn contains the \Avalon folder and a number of files. The \Avalon folder contains one large .msi file at a deeper level than the files inside \v6.0.4030. We get a qualitative sense of the relative sizes of the files and folders – e.g. PresentationCore.dll and PresentationFramework.dll are approximately the same size as one another and both much smaller than avalon.msi. We can also see that there is a large number of small files which we could zoom closer to if we wanted to see their names.

The following image moves up a folder and shows, amongst other things, the combined size of the Avalon runtimes (the \Windows folder) in relation to the remainder of the .NET Framework. We can also see that, for example, System.ServiceModel.dll is a little larger than PresentationCore.dll and PresentationFramework.dll.

Here are the pieces which go into this sample:

A generic DatatreeNode class used to build a ‘datatree’ of the data to be visualized. Using this extension point, any data which can be represented as a hierarchy (e.g. your Exchange/Outlook folders) can be processed into a treemap.
A routine to recurse into a file system folder and build a datatree from it.
A TreemapNode class (and ancillary classes) used to build a treemap from a datatree.
A routine to arrange the treemap into layers for back-to-front rendering. As the scene uses semi-transparent materials, it is defined back to front to aid correct alpha blending.
A routine to walk the treemap layers from furthest (from the eye) to nearest and to process each node in each layer as follows:
1. Create a tree of Visuals consisting of a TextBlock inside a Viewbox inside a Border.
2. Create a VisualBrush from the above and use it as the material on a plane (a MeshGeometry3D) which is placed appropriately on the z axis.
A custom Viewport3D in which to display and manipulate the scene (the same one I introduced in the Nendo Nessie post).

There’s a lot of information to be seen in the images here, but even more information emerges when you are able to manipulate the model yourself with the mouse. Download and build the sample and evaluate it yourself. To toggle mouse manipulation mode, use Ctrl + right-mouse-click. See the Nendo Nessie post for more details.

Furthermore, information is always lost when flattening (i.e. projecting) a 3D scene for display on a traditional CRT or LCD monitor. Flat displays rely on artificial depth cues (e.g. perspective or color) to tell the eye how far away an object is. The same 3D data shown on a stereoscopic or a holographic display would preserve depth information so that the eye and brain sense true depth and can more fluently read the scene.

It would be an interesting exercise to use the sample’s treemap generation logic inside a custom Panel.

I’ll leave you with another of Ben Shneiderman’s visualizations – structured flowcharts – which may offer an interesting future project for someone to realize in Avalon.

Building Avalon Apps: Basics and Behind-the-scenes. Part 2

stevewhitepsfd — Sun, 19 Jun 2005 12:42:00 GMT

Command-line build 2: XAML-only NavigationApplication

In the previous post I showed how to build a very basic C#-only Avalon application. At the end I mentioned that declaring and initializing UI is probably not best done with imperative code. This time I’ll go to the other extreme and declare a very simple application entirely in markup. In future posts I’ll settle for a mixture of markup and code-behind.

If you’re familiar with ASP.NET then you’ll know about markup files and code-behind files. The idea is that UI is defined in markup, and application logic is separated out into the code-behind file. This way, in an idea world, a developer can drop a basic UI into markup, make it functional in the code-behind, then let a designer take the markup and make it beautiful. It also means that the UI and application logic needn’t be compiled at the same time.

Although Windows Forms doesn’t have markup, it does have the InitializeComponent method into which the Forms Designer writes a lot of UI initialization code. This gives some separation of static layout from application logic but, because the UI is initialized in imperative code, it’s not as toolable as markup. It also means the UI and application logic must be compiled together.

XAML is Avalon’s markup. XAML can be used to declare any CLR object and it’s effectively a persistence format for CLR objects. When used with Avalon, XAML is a persistence format for Avalon objects, and Avalon offers far better flexibility and customization than ASP.NET or WinForms. XAML is XML so it is extremely toolable and it can be parsed and/or compiled separately from the application logic, even being loaded dynamically at runtime as a control tree.

With the Beta 1 RC bits, the Application we created in the previous post purely in C# can’t be done purely in XAML (I’m told it will be possible in future bits). However, we can do a NavigationApplication purely in XAML. A navigation application has a similar paradigm to a web application or a Wizard in that it has pages between which the user nagivates and a Journal in which navigation history is remembered.

First we’ll create a file in which to declare the application class. Create a folder called XAML-only NavApp and, in it, create a new text file called NavApp.xaml. Declare an empty NavigationApplication element with a StartupUri of Page1.xaml like this:

In XAML, elements correspond to type names and attributes correspond to property names (unless recognised by XML, e.g. the default XML namespace declaration). What we’re doing here is declaring a partial type deriving from System.Windows.Navigation.NavigationApplication. We’ll shortly be processing this markup through a XAML markup parser. The markup parser will know the NavigationApplication type because we’ve specified a default XML namespace which identifies the Avalon types. I haven’t named the derived type so it’ll get a default name (actually _Application). The markup parser will also assume we want a singleton instance of this class and it will generate the code to instantiate one also. We’ll look more closely at what gets generated from this XAML after we’ve built it.

Next, create Page1.xaml containing a Page element as follows:

</TextBlock>

</Page>

Again the Avalon XML namespace is required. The value of the Page element’s Text attribute will appear in the navigation application’s main window caption when this page is shown. Nested inside the Page element is a TextBlock element which is a control used to display simple text content. The markup parser has a set of rules by which it determines what a child element represents relative to its parent. A child element may be a complex property of its parent (e.g. Button.Background); a member of the collection stored in its parent’s default property; part of its parent’s content tree; or something else.

In this case the TextBlock is interpreted as being the value of the Page’s Child property (which is of type UIElement; and TextBlock is a UIElement). Inside the TextBlock is a Hyperlink element which is interpreted as the TextBlock’s content.

Again, this XAML is declaring a new partial type deriving from Page. Whereas the markup parser will instantiate an application instance for us without being explicitly asked, it does not do so for other classes declared in XAML. However, the application’s StartupUri is set to Page1.xaml which is a fairly explicit request for an instance of our Page-derived class and the markup parser will generate code which will result in one. As I’ll show in a moment, this instance is actually created at runtime by another parser.

Next, create Page2.xaml:

Now create a project file called NavApp.csproj which contains:

<AssemblyName>NavApp</AssemblyName>

<OutputType>winexe</OutputType>

</PropertyGroup>

</ItemGroup>

</Project>

The NavApp.csproj file contains the same Assembly references as the project file in the previous post, but it also has ApplicationDefinition and Page item types. These item types are built by code inside the PresentationBuildTasks.dll I mentioned in the previous post, and the WinFX targets tell MSBuild about that dll.

Choose Start – All Programs – WinFX SDK – Release Build Environment and change directory to your XAML-only NavApp folder. Issue the command msbuild and confirm that the build succeeded.

If you can resist running the application right away you might be interested to look at the generated intermediate files in your \obj\release folder. The .baml files contain a binary version of the XAML (i.e. tokenized XAML). The .g.cs files are generated C# source files.

When we built our project, the Page XAML files were parsed into a corresponding .g.cs source file and a corresponding .baml file. Inside Page1.g.cs you’ll see that a class called _Page1 has been generated. In this class is logic to load the page’s BAML from a managed resource embedded in the assembly. However, although Connect is called (the purpose which is to give the class the opportunity to wire up any event handlers), InitializeComponent is not, as can be witnessed by setting breakpoints. A class called System.Windows.Navigation.NavigationService is actually used behind the scenes to load the BAML and parse it into an tree of user-interface elements.

Inside NavApp.g.cs (which was generated from NavApp.xaml) the _Application class is defined, deriving from NavigationApplication. And in its constructor the StartupUri is set to the same value we set in markup.

NavApp.Main.g.cs does not correspond to any XAML file but it is generated by virtue of the fact that we are building an application. Our Main method is generated in this class along with a ResourceLoader class which you can see being instantiated in the _Application class. However, the ResourceLoader is now a deprecated mechanism. In the Main method our application singleton instance is created, and it is stored in a private static member by the Application base class constructor. This enables the instance to be accessed via System.Windows.Application.Current as you can see happening in _Page1.MyApplication.

Also during the build process, the generated .g.cs source files are then compiled into an assembly. All that remains of the markup is the BAML which is deserialized into CLR objects at runtime by the System.Windows.Serialization.Parser class. This class can be used to (de)serialize any BAML or XAML at runtime.

If you now run the navigation application you will see the chrome at the top of the window which contains the navigation buttons. The chrome actually belongs to an instance of a NavigationWindow which has been automatically created for us, and our Pages are placed inside that. The Journal is the name for the mechanism which remembers our navigation history which you can see by using the navigation buttons’ drop-down buttons after you have navigated with the hyperlink.

Next time I’ll move into Visual Studio 2005 and combine XAML with code-behind in order to benefit from the advantages of each.

Building Avalon Apps: Basics and Behind-the-scenes. Part 1

stevewhitepsfd — Sat, 18 Jun 2005 14:21:00 GMT

I thought it would be interesting to walk through building some very basic Avalon applications. Some topics I want to introduce include Avalon’s application model; the interplay between declarative XAML markup and imperative CLR code-behind; what happens at build time; and some behind-the-scenes details at runtime.

The WinFX Beta 1 RC bits

To follow along you’ll need to install the WinFX Beta 1 RC Runtimes and SDK on XP or Windows Server 2003 if you haven’t already.

Although Avalon and Indigo are each parts of WinFX (i.e. the Windows Frameworks), their assemblies are installed to slightly different destinations in the Beta 1 RC. For instance, Indigo’s System.ServiceModel.dll can be found in %WINDIR%\Microsoft.NET\Framework\v2.0.50215. But the Avalon runtimes (WindowsBase.dll, PresentationCore.dll and PresentationFramework.dll, etc) can be found in %WINDIR%\Microsoft.NET\Windows\v6.0.4030. This separation may become clearer on Longhorn but it suggests that Indigo is part of the .NET Framework whereas Avalon is part of WinFX proper. This is supported by the following table:

Assembly	AssemblyProductAttribute	AssemblyVersion	AssemblyVersion of .NET F/W Referenced
System.ServiceModel	Microsoft(R) .NET Framework	2.0.0.0	2.0.0.0
WindowsBase	Microsoft (R) Windows (R) Operating System	6.0.4030.0	2.0.0.0
PresentationCore	Microsoft (R) Windows (R) Operating System	6.0.4030.0	2.0.0.0
PresentationFramework	Microsoft (R) Windows (R) Operating System	6.0.4030.0	2.0.0.0

Another of Avalon’s assemblies is PresentationBuildTasks.dll which contains the MSBuild Tasks which process XAML into CLR source code files and into a binary representation called BAML.

The first two applications will use command-line builds; I’ll get to Visual Studio 2005 later.

Command-line build 1: C#-only Application

Let’s begin by building an Avalon application entirely in C#. Create a folder called C#-only App and, in it, create a new text file called App.cs. Add the following code to the file:

using System;

class EntryPoint

{

[STAThread]

static void Main() {}

}

So far there is nothing to distinguish this from a regular .NET application. It has a UI thread and an entry point. Now add a using statement for System.Windows. Notice the subtle difference here: if we were writing a Windows Forms application we would use System.Windows.Forms. Next, in Main, instantiate a new Application (actually System.Windows.Application) and call its Run method. Your file should now look like this:

using System;

using System.Windows;

class EntryPoint

{

[STAThread]

static void Main()

{

Application app = new Application();

app.Run();

}

If we build and run this, we’ll have a running Avalon application but it will have no way of interacting with the user (unless you count Task Manager!). So let’s have the app show a window. In Main, instantiate a new Window (System.Windows.Window) and call its Show method. Your Main method should look like this:

static void Main()

{

Application app = new Application();

(new Window()).Show();

app.Run();

}

We’ll be using the Microsoft Build Engine (MSBuild) to build our application, so create a project file called App.csproj in your application folder. Inside it put the minimum contents to perform an Avalon build:

<OutputType>winexe</OutputType>

</PropertyGroup>

</ItemGroup>

</Project>

The only thing of note, the only part which is different from a normal C# MSBuild project, is the set of assemblies referenced (the ones we talked about earlier).

Now, to build the application from a command-prompt choose Start – All Programs – WinFX SDK – Debug Build Environment and at the prompt change directory to your C#-only App folder. Issue the command msbuild. Confirm that the build succeeded.

Run App.exe and note the default window which is shown. Now, to customize the window a little. Add a new class to App.cs called MyWindow which derives from Window. In the class’s constructor set the window’s Text to “Hello from MyWindow”.

class MyWindow : Window

{

internal MyWindow()

{

this.Text = "Hello from MyWindow";

}

Change the code in Main so it instantiates a MyWindow instead of a Window. Build and run again and note the window’s caption is the value you set the Text property to.

So far there’s nothing to distinguish this as an Avalon window so let’s put some Avalon controls inside it. Add a using statement for System.Windows.Controls. In MyWindow’s constructor, declare an object reference and assign a new Button (System.Windows.Controls.Button) to it. Cast the object to a ContentControl and set its Content to “Some text content”. Finally set the MyWindow’s Content to the object.

internal MyWindow()

{

this.Text = "Hello from MyWindow";

object o = new Button();

(o as ContentControl).Content = "Some text content";

this.Content = o;

}

Notice how both the Button and the MyWindow have a Content property of type object. This is because both derive from System.Windows.Controls.ContentControl. This idea that there is no constraint on what can be contained within a control is Avalon’s evolution of text content. In the above code the Button’s content is still plain old text but it could be any object whatsoever (including the root of a tree of content), e.g. a Shape, a Control, a Panel or a business object. The MyWindow’s content is a Button, but would normally be a Panel of some kind inside which the remainder of the window’s content would be laid out.

I made the variable o have type object to show that the Content property of the MyWindow is of type object. But this also enables us to instantiate any ContentControl and assign it to o. Try instantiating a CheckBox instead of a Button.

Build and run. Notice that the Button is filling the window. This is because the default behavior for Buttons is to stretch to fill their container. There are many rules around layout which I’ll cover in a later post. For now, though, cast the Button object to a FrameworkElement and set its horizontal and vertical alignment to Center and, so that we can see it clearly, set its LayoutTransform to new ScaleTransform(5,5). You’ll also need to add a using statement for System.Windows.Media which is the namespace containing the ScaleTransform class. Your entire code file should finally look like this:

using System;

using System.Windows;

using System.Windows.Controls;

using System.Windows.Media;

class EntryPoint

{

[STAThread]

static void Main()

{

Application app = new Application();

(new MyWindow()).Show();

app.Run();

}

class MyWindow : Window

{

internal MyWindow()

{

this.Text = "Hello from MyWindow";

object o = new Button();

(o as ContentControl).Content = "Some text content";

(o as FrameworkElement).HorizontalAlignment = HorizontalAlignment.Center;

(o as FrameworkElement).VerticalAlignment = VerticalAlignment.Center;

(o as FrameworkElement).LayoutTransform = new ScaleTransform(5,5);

this.Content = o;

}

The casts are there only to highlight which classes define the various properties. If you like you can change o’s type to Button and remove all the casts. Build and run and notice the difference to the Button’s layout and scale transformation.

So far the application consists exclusively of imperative code which would arguably be more suitable in the form of declarative XAML markup. In the next post I’ll look at a XAML-only application (a NavigationApplication in fact) and after that we’ll mix the two modes and begin to use Visual Studio 2005.

Scales

stevewhitepsfd — Sat, 12 Mar 2005 20:59:00 GMT

So I’ve talked about classes representing the ideas of note and interval. This post I’ll cover Voices.ScaleClass, Voices.Scale and Voices.KeySignature.

A scale is an interesting interplay between notes and intervals within an octave. As an example, the notes C D E F G A B constitute the C major scale. But it is the set of intervals between these notes (the sum of which is an octave) which defines the essence of what it is to be a major scale. Specifically, these intervals are: maj2 maj2 min2 maj2 maj2 maj2 min2. Typically the intervals are summed cumulatively with the initial perfect unison and the final perfect octave assumed, so: maj2 maj3 per4 per5 maj6 maj7. That set of intervals, measured out above a tonic note, locates and names the notes of any major scale.

Although a scale can be viewed as a series of notes or as a series of intervals, it’s practical to see the notes as the scale and the intervals as the scale class. So a scale can be defined as a sequence of notes, chosen out of the possible notes in the octave, and beginning on a tonic. And a scale class can be defined as the class of scales between whose notes appears the same sequence of intervals. As I’ve said, that sequence of intervals sums to an octave no matter what the scale class.

So, let’s look at a C# class representing scale class. Greatly simplified, Voices.ScaleClass looks like:

public class ScaleClass

{

static ScaleClass()

{

_majorScale = new ScaleClass("Major", "2 3 4 5 6 7");

_dorianMode = new ScaleClass("Dorian Mode", "2 b3 4 5 6 b7");

...

_bluesScale = new ScaleClass("Blues Scale", "b3 4 b5 5 b7");

}

public static ScaleClass MajorScale { get { return _majorScale; } } static ScaleClass _majorScale;

public static ScaleClass IonianMode { get { return _majorScale; } }

public static ScaleClass DorianMode { get { return _dorianMode; } } static ScaleClass _dorianMode;

...

public static ScaleClass BluesScale { get { return _bluesScale; } } static ScaleClass _bluesScale;

internal ScaleClass(string longName, string intervalsString)

{

_longName = longName;

_intervalsString = intervalsString;

}

internal string _longName;

internal string _intervalsString;

}

The only real value this class provides is a place to store the _intervalsString field. This field contains a string representation of the sequence of intervals which give the scale class its identity. These intervals have the format of an optional sharp or flat symbol followed by a digital interval quantity. Alternatively they can be the solfeggio symbols: do, di, ra, re, ..., te, ti.

The class Voices.Scale has a constructor with the signature:

public Scale(ScaleClass scaleClass, Note tonic)

What this constructor is interested in is the tonic note and the _intervalsString from scaleClass. It String.Splits intervalsString into a string[] the elements of which it then takes in turn and obtains an Interval from by means of the following method on Voices.Interval:

internal static Interval Interval.LookUp(string abbreviation)

The constructor proceeds to add each resulting Interval in turn to the tonic Note, thus obtaining the degrees of the scale. It’s a little more complicated than than because Voices.Scale is actually composed of a doubly-linked cyclic list of Voices.ScaleTone.

So, of the list nodes (i.e. the tones) in a Scale, those which are ScaleDiatones are the ones corresponding to the tonic note and the notes reached by adding the intervals of the scale class to it. All the rest are plain old ScaleTones.

In order to support enumeration, Voices.Scale implements IEnumerable and its implementation of IEnumerable.GetEnumerator simply returns a new instance of the Voices.ScaleToneEnumerator class. As is typical, ScaleToneEnumerator Resets its Current state to ‘one before the first element’ which in this case is the tone at the 11-o’clock position. It implements MoveNext by moving to ScaleTone.Sharp until the 11-o’clock position is reached again.

The last class I’ll talk about in this post is KeySignature. A key signature is a pattern of sharp or flat symbols written at the beginning of a musical staff to indicate which degrees of the scale are not natural. Strictly speaking, distinct key signatures exist only for fifteen major scales. Minor scales and the remaining modes re-use the key signatures of their relative major scale. I omitted this detail above for the sake of clarity, but one of the arguments to the ScaleClass constructor is a value from the ScaleClass.Mode enumeration, which looks like this:

public enum Mode

{

Major = 0,

Dorian = 6,

Phrygian = 5,

Lydian = 4,

Mixolydian = 3,

Minor = 2,

Locrian = 1

}

There is a field for each mode. The value given to each field represents the degree of the corresponding mode on which the mode’s relative major begins. For example, you may know that the major mode begins on the minor mode’s third degree. This is why Minor has the value 2 (where 0 means first). The constructor of the class Voices.Scale reads n, the integer value of its ScaleClass’s Mode, and then finds the nth degree of the scale being constructed. This way it identifies the major scale on which the scale is based and it is that scale which donates its key signature.

The important parts of the KeySignature class are:

public Note[] Accidentals

{

get

{

return _accidentals;

}

internal Note[] _accidentals;

public bool Sharps

{

get { return _sharps; }

}

internal bool _sharps = true;

The Accidentals property returns an array of Notes in key signature order, and the Sharps property tells us whether the accidentals are sharps or flats.

Even more registration-free COM articles!

stevewhitepsfd — Sun, 27 Feb 2005 20:42:00 GMT

So, I spent the past two weekends and every evening between finishing these. Please check them out and let me know what you think.

Registration-Free Activation of COM Components: A Walkthrough

Registration-Free Activation of .NET-Based Components: A Walkthrough

New registration-free COM article

stevewhitepsfd — Mon, 21 Feb 2005 04:27:00 GMT

I posted the article "SxS Managed COM With Manifest Resource (WinXP and Win2K3)" some time ago and Jason Buxton was interested in applying it to Visual Basic 6.0 client applications. Well, I've put together an MSDN article proposal which addresses that question and is a general improvement on the original article.

The new article is called Registration-Free Activation of .NET-Based Components: A Walkthrough and can be found in the Software category of my articles section. I'm planning accompanying articles named "Registration-Free Activation of COM Components: A Walkthrough" and "Registration-Free COM in Web Applications: A Walkthrough."

Starting over with Voices.Interval

stevewhitepsfd — Fri, 18 Feb 2005 08:18:00 GMT

In the previous post in the Voices category I showed my re-imagined Voices.Note class and its close relatives. You can already see that the new design has a useful separation of tone from note. I had also mixed solfeggio and scale into my initial, abandoned, design. I’ll come to scale in the future but, in this post, I’ll show why solfeggio is, and should remain, distinct from note. At the same time I’ll introduce the second fundamental of music - interval. By the way if you want to know more about music theory check out the articles I’ve posted under the Voices Help category. These articles will be developed further over time.

So, the reason I’d made a horrific hybrid of solfeggio and note the first time round (like Seth Brundle spliced with the fly) was because I hadn’t appreciated what solfeggio is, or at least what the best way to interpret solfeggio is. Warburton’s Harmony is not alone in presenting solfeggio as a kind of algebra for notes. You’ll find many definitions describing the solfeggio syllables as the ‘notes of a scale’, and very few point out that they’re more usefully thought of as aliases for intervals above some scale tonic. So do is equivalent to perfect unison; di is augmented unison; me is major third; mé is minor third, and so on.

With solfeggio and interval neatly unified, I’ll now turn to interval itself and show how I implemented and optimised it in the Voices.Interval class. The kind of client code I want the Voices class library to be able to support is:

Note n1 = Note.C;

Interval interval = Interval.Second.Major;

Note n2 = n1 + interval.Inverse;

If you have experience of music theory you’ll know that an interval has two components – quality (e.g. major) and quantity (e.g. second). In my first, abandoned, version of Voices.Interval I gave the class just such fields. On top of those I gave it fields storing the number of compound intervals (for intervals greater than an octave) and the number of times the interval was diminished or augmented (which could be zero). It took me a long time and about 900 lines of C# to get the Interval class correct in its first version. Its methods (e.g. DecrementQuantity and IncrementQuantity), properties (e.g. Octaves) and operators were long and full of tortuous boundary condition logic.

What I’d missed is that there was no need to represent the state of an interval so literally. It eventually occurred to me that every note is some interval above or below C4. And you can represent the private state of any interval – ascending or descending, simple or compound – by the note which is that interval away from C4. It only remained to implement the properties in terms of that internal state by reusing the Voice.Note class and the methods, properties and operators I’d already implemented on it. This change was done surprisingly quickly and it was a real education to me that note and interval really are two aspects of the same idea. In lines of code the new class is well over a third shorter than its first incarnation. An extreme example is the Octaves property’s set clause which was reduced from 64 lines to 1 because Voices.Note has its own Octaves property.

The new Voices.Interval class, plus its nested and ancillary types, is around 2,500 lines of C# and it looks like this:

public class Interval : IComparable

Public Ancillary Types

class IntervalException : ApplicationException

enum IntervalQuantity

enum IntervalQuality

Public Nested Types

class GeneralIntervalList : IList, IEnumerator

abstract class GeneralInterval : IList, IEnumerator

class Unison : GeneralInterval

class Second : GeneralInterval

...

class Fifteenth : GeneralInterval

Public Fields

static bool NameIsAbbreviated

static bool NameIncludesCompoundText

static bool NameIncludesDirection

Public Constructors

Interval(Interval)

Interval(Interval interval, Int32 additionalAlteration)

Interval(Interval interval, Int32 additionalAlteration, Int32 additionalOctaves)

Interval(Interval interval, Int32 additionalAlteration, Int32 additionalOctaves, bool reverseDirection)

Public Properties

static Unison GeneralUnison { get; }

static Second GeneralSecond { get; }

...

static Fifteenth GeneralFifteenth { get; }

bool IsImmutable { get; }

bool IsAscending { get; }

Interval Complement { get; }

Interval Inversion { get; }

Interval Reverse { get; }

Int32 Alteration { get; set; }

Int32 Octaves { get; set; }

IntervalQuantity Quantity { get; set; }

IntervalQuality Quality { get; set; }

string CompoundTextTextual { get; }

string CompoundTextDigital { get; }

string AlterationText { get; }

string Name { get; }

Int32 Semitones { get; }

bool IsCompound { get; }

bool CanBePerfect { get; }

Interval SimpleInterval { get; }

Public Methods

void DecrementQuantity()

void IncrementQuantity()

void Diminish()

void Augment()

string GetName(bool abbreviated)

string GetName(bool abbreviated, bool includesCompoundText)

string GetName(bool abbreviated, bool includesCompoundText, bool includesDirection)

static bool Exists(IntervalQuantity quantity, IntervalQuality quality)

string ToString()

static Interval operator+(Interval lhs, Interval rhs)

static Interval operator-(Interval lhs, Interval rhs)

static bool operator==(Interval lhs, Interval rhs)

static bool operator!=(Interval lhs, Interval rhs)

static bool operator>(Interval lhs, Interval rhs)

static bool operator>=(Interval lhs, Interval rhs)

static bool operator<(Interval lhs, Interval rhs)

static bool operator<=(Interval lhs, Interval rhs)

bool Equals(object obj)

bool Equals(Interval rhs)

bool IdenticalTo(Interval rhs)

int GetHashCode()

int CompareTo(object arg)

By the way, I made Voices.Note a value type as I know I’ll be using a lot of Note[]. I don’t suspect I’ll be doing that with Interval, so I’ll leave it a reference type until there’s any good reason to change it.

My team is hiring in the UK!

stevewhitepsfd — Tue, 08 Feb 2005 03:28:00 GMT

Follow this link and under Development you’ll see the job title Developer Consultant PSfD.

Tell them Steve sent you. :-)

Side-by-side Assemblies Articles

stevewhitepsfd — Sat, 05 Feb 2005 23:07:00 GMT

Jason, thanks for your comment on the previous post. What particularly resonated with me was "Making it work for real would be a big deal where I work," because I'm part of Premier Support for Developers and our job is helping enterprise and ISV Microsoft customers with their app development issues. Customers buy an annual contract (there is a range of sizes) with my team and we work with them through the year so we get to know their systems.

I've just posted two articles under the Software category on the subject of SxS Managed COM - i.e. a native app activating an unregistered COM-Callable Wrapper which then delegates on to a managed class library. Generally the CCW would have to be registered but the SxS mechanism uses .manifest files to build in-memory structures known as Activation Contexts.

The two articles mention associated .zip files. I haven't included a link to these but there are clear steps in the articles (with source code and explanations) on how to produce the binaries for yourself. I hope these are of some use. Please note that the 'With Manifest File' article applies to Windows 2003 only and the 'With Manifest Resource' applies to both Windows 2003 and XP, so please choose the approach which fits your platform requirements.

Side-by-side Assemblies

stevewhitepsfd — Sat, 05 Feb 2005 03:54:00 GMT

Recently I’ve been researching into Isolated Applications and Side-by-side Assemblies [1] for one of my customers. I thought I’d share a few evidently little-known rules and gotchas around this technology. I actually have a lot of these, and I’m still collecting them, so I’ll start with just a few here and I’ll post some more in the future. I also plan to write an MSDN article on the subject so I’ll post the link to that in due course.

First, Side-by-Side (SxS) with native COM components. So, on Windows XP, I seem to have to give my assemblies a multi-segment name (I’d be interested to know if anyone has experience to the contrary). The assembly name is what appears in the name attribute of your assembly manifest file’s assemblyIdentity definition element, e.g.:

<assemblyIdentity

type = "win32"

name = "myCOMServer"

version = "1.0.0.0"

processorArchitecture = "x86" />

So, although this will work fine on Windows Server 2003 with a dll called myCOMServer.dll, on Windows XP you have to change the assembly name to myCOMServer.XXX (or some such multi-segment name). There’s no need to make any change to the dll’s name. By the way, changing the assembly name means: changing the name of the assembly manifest file to myCOMServer.XXX.manifest; and changing the name attribute of the assemblyIdentity element in both the def (assembly manifest) and the ref (application manifest).

Another one is that, although the processorAchitecture attribute of the assemblyIdentity element is documented as not required [2] [3], if you use it in one of the def or the ref, you have to use it in the other.

Now for SxS with managed COM components. This first one is obvious if you come at it with a CLR mindset, but if you come at it fresh from SxS with native COM then it may be less obvious. With SxS native, the assembly name you put in your manifest files is independent from the name of your dll. With SxS managed, the assembly name you put in your manifest files must be the name of your .NET assembly and therefore the name of your dll (there are issues with multi-part assemblies which I’ll defer to a later post).

By no means obvious is the fact that for Windows XP it is mandatory to embed the assembly manifest into the assembly as a Win32 resource file (by the way this is currently optional for Windows Server 2003, but please don't rely on it always being so - SP2 may cause Win2K3 to behave like XP in this regard). To do this, first create a resource file to reference your assembly manifest. Here’s an example of myAssembly.rc which looks like:

#include <windows.h>

1 RT_MANIFEST myAssembly.manifest

This will compile into myAssembly.res when run through the resource compiler. So create a build script to build the resource and then embed it as a Win32 resource into your assembly. Something like:

rc myAssembly.rc

csc /t:library /out:myAssembly.dll /win32res:myAssembly.res AssemblyInfo.cs Class1.cs

[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/isolated_applications_and_side_by_side_assemblies_start_page.asp

[2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/application_manifests.asp

[3] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_manifests.asp

Starting over with Voices.Note

stevewhitepsfd — Wed, 02 Feb 2005 04:20:00 GMT

So this year I threw away my code and started again. I believe that the two fundamentals of music are note and interval and that all else (scale, chord, etc) is build from them. Rhythm (i.e. time) is an orthogonal dimension and I’ll save that for much later. This post I’ll talk about my Note class.

So, last post I showed a diagram of how I’d modelled a circle of notes. You can see the circle and peanut shapes in that diagram: the peanuts are there to show notes with enharmonic names. I think I’d failed to separate out the ideas of tone, note, solfeggio, and scale in my original classes. A static class diagram of just a few of them looks like:

Furthermore, I’d written a ChromaticScale and a MajorScale class built from ScaleToneNames. The MajorScale doubled as a representation of the natural note names (i.e. the white piano-keys). I then used CodeDom together with a set of IntervalCycle instances with hardcoded intervals to generate classes for another ten scales including the modes and the minor scales.

My interval class left a lot to be desired and had few operators; the logic for generating a scale of ScaleToneNames from intervals was tortuous; the code which allowed Notes and Intervals to interact was not general; and the project was bloated with too many classes and too much code. I needed a re-think.

So, what’s the definition of a note? What comes to mind? A physical division on an instrument (piano-key, fretted guitar-string)? Or is a piano-key only a note when it’s played? Maybe you feel a note is something theoretical so that the same piano-key is sometimes the note C# and sometimes Db whether it’s sounded or not? Is a note something you can point at, press, and finger; or something you hear; or something you distinguish by its name and notate on paper? All these ideas are important but I think it’s necessary to give them unique names for the sake of clarity.

In 12-TET (twelve-tone equal temperament), the octave class is divided up into twelve pitch classes. Just like in the abbreviation TET, you’ll almost always hear these pitch classes referred to as tones so I’ll do the same to distinguish them from the idea of note.

Since an octave rolls around into its neighbours, it’s useful to consider only the octave class and to present it visually with its twelve tones arranged like the hour positions of a clock-face.

I’ve called this arrangement, and its corresponding C# class the TwelveToneClock. It’s composed of twelve Tones. As you can see, some tones have names and some don’t. So, derived from Tone are NamedTone (with a Name property) and UnnamedTone. Although the unnamed tones can be named in relation to the named ones (any of them in fact, but typically a neighbour), it’s also important to the theory of tonal harmony that a natural name can be overridden. For example, the tone at the twelve o’clock position is typically used as the note C natural, but a good musical model should allow for it to theoretically become the note B# or even Dbb. It’s in this (en)harmonic sense that I’ll define the Note class.

A Note, then, is defined as a reference to a NamedTone along with scalar properties representing the note’s octave number (approximately 1-8 on the piano, but capable of being much wider) and how many semitones that NamedNote has been sharpened or flattened (therefore a signed integer, typically in the range -1 to 1) known as its alteration. And here’s the relevant portion of the new static class diagram:

My first (false) start at the Voices project

stevewhitepsfd — Sun, 30 Jan 2005 09:36:00 GMT

So, the middle of last November I started doing some thinking and designing and putting some C# classes together in a library. It was a bit of a false start as I’ll explain, so this year I started the project afresh with the benefit of what I’d learned. I’ll get to the starting-over in later posts but first I’ll talk about what I did wrong the first time around and what I failed to understand correctly at the time.

It was a combination of note names and solfeggio that conspired to confuse me. It wasn’t about how notes are named in a diatonic scale, because I was only considering notes roaming untethered in their wild state. I was thinking about the possible names a note could have as it sat on the piano or on the guitar, and I came up with a good idea but then made a schoolboy error. The good idea was to abstract the notes away from their instrument and visualize them in a circle so that I was working with an instrument-agnostic format. My error followed from something I misunderstood in Annie O. Warburton’s book Harmony.

In her book, Warburton introduces the solfeggio names do, re, mi, fa, sol, la and ti (although she spells them her own way) as a kind of algebra for the seven notes in any major scale. For example, the C major scale begins C-D-E-F, and the B major scale begins B-C#-D#-E-, but what those two sequences of notes have in common – what makes them both major – is the pattern of musical intervals between neighboring notes. So we can represent the notes of any major scale as the algebraic symbols do-re-mi-fa- and so on, so long as we define the musical intervals between neighboring symbols as being those of the major scale. So far, so simple.

But there’s a scale called the chromatic scale. It’s arguably not a true scale as it’s nothing more than all twelve notes of the octave in sequence. Its intervals are all the same size – physically a semitone; some are augmented unisons, some are minor seconds. Warburton writes that the solfeggio names in the ascending chromatic scale are do-di-re-ri-mi-fa- and so on, and in the descending chromatic scale they end fa-mi-mé-re-ra-do. With do (the tonic) as the note C, these names become C-C#-D-D#-E-F-, etc., ascending and end F-E-Eb-D-Db-C descending. So some notes (e.g. C, D) have the same name in either direction and some (e.g. C#/Db, D#/Eb) change their name. Distracted and charmed by the altered solfeggio notes such as di (which can be thought of as do sharp and represents C# in C major), I believed that the solfeggio names had all the possible note names covered – and that was mistake number one. I also believed, taking my lead from Warburton’s note spellings in the chromatic scale, that whenever you sharpened a C you got C# and whenever you sharpened C# you got D. Descending, I thought that whenever you flattened a D you got Db and whenever you flattened Db you got C. Of course, not all those are correct. It led me to a diagram of a note-circle like this:

The dotted arrows show the direction a note moves when it is sharpened or flattened by a semitone, and their destination shows what I thought the resultant name had to be. In fact, if you sharpen C# you do get a note with the same pitch as D but you call it C double-sharp (C## or Cx). There’s actually a lot more to sharpening and flattening notes than I’m telling here because the only meaningful harmonic operation on a note is to add a directed interval. But more on that in the future. In any case, I realized my design wasn’t quite right.

The diagram implies that there’s something special about the peanut shapes because they have two possible names. But I’d forgotten the existence of notes like Cb (same pitch as B), B# (same pitch as C) and Ebb (same pitch as D). In fact, theory allows for any note to be given many names. A diagram showing all the possible theoretical note names and arrows between them would be far too large and busy to be useful.

Next time I’ll look at the right way to model notes and intervals. Incidentally, what Warburton’s book doesn’t say explicitly, but you can figure out, is that the solfeggio names are not simply algebra for note-names. What’s important about them is the interval between one name and the next. But you can also accumulate those intervals and know what interval any solfeggio name is above the tonic of the scale. If you know a sequence of intervals above a tonic note then you know everything you need to know about a scale class and you can place the tonic on any of twenty-one note names and know twenty-one scales of that scale class. Therefore what solfeggio really represents is a set of aliases for intervals. If you’re unsure what an interval is then have a look at my music training articles.