With the beta 4 update of 1.9, we’re introducing yet another rule which you can use to make mixes just the way you want. This particular rule gets right to the core of our acoustic analysis, and because it lets you tweak the results based on acoustic properties, we’ve named it tweak.

Tweak

The tweak rule lets you push a playlist in one of six directions, based on acoustic properties. Because the core playlisting engine is doing a lot of different work to build the list, these particular rules are more like nudges in a given direction, rather than an absolute lock on the desired property. Still, they can be useful. The key properties exposed in this version are bass, energy, and tempo.

The full syntax looks like this:

<tweak cond="expr" index="type" more="boolean" weight="expr"/>

The index attribute lets you choose the property you want to base the tweak on - either bass, energy, or tempo (there is no default value, this attribute is required). The more attribute lets you specify if you want more or less of the given property - more tempo will mean faster, less tempo will mean slower, and so forth (as a reminder, though, these are general nudges rather than hard and fast rules). The default is more! The default weight is 2.5.

As an example, here’s a recipe that will try to produce a playlist which is overall faster and higher energy than an equivalent mix without the recipe:

<recipe name="Give Me More">
  <tweak index="energy" more="true"/>
  <tweak index="tempo" more="true"/>
</recipe>

One common thread we’re hearing from people playing with all these new features is the need for more examples. When we finish this next round of testing, we hope to introduce some ways to make all this power even easier to use.

Welcome to day five of MusicIP Mixer 1.9 preview week. This will be the last post, for now, about the new features. I’ll wrap up with a few final miscellaneous features.

Two Extra Rules

With the pile of constraints, modifiers, and other rules introduced so far, here are two more which might, at first blush, seem a little odd. The first one simply replaces the acoustic ranking algorithm with a fixed "no bias" level.

<fixed/>

This lets you apply any of the other rules by themselves, without the acoustic data.

The jitter rule lets you introduce some controlled randomness in your mixes. This is similar to the variety slider for regular mixes, but tends to give better results. The full syntax looks like this:

<jitter cond="expr" exp="bool" low="expr" high="expr"/>

The exp option uses an exponential distribution instead of a flat distribution (the default is flat).

The low and high options specify the range of the jitter. The default range is .9 to 1.1. Bigger ranges will produce more randomness.

File/Save As Text

Moving on from recipes, one of the new features is the rather unassuming Save As Text option under the File menu. This takes whatever data is being displayed in the song window, and saves it as tab-delimited text. Just choose the columns you want to have displayed (you can right-click on the column headers to enable and disable columns, drag the columns around to position them, and click to sort them). Then use Save As Text to get a text version of the mix. This can be an easy way to share lists of songs, or post them to blogs. Simple, but convenient.

Nested Filters

Many months ago, we conducted a poll on the forums to see what the most requested feature for 1.9 would be (with some restrictions). The winning selection, with 50% of the votes, was nested filters. So, what’s a nested filter?

Regular filters allow you to create a set of conditions for which songs are currently visible. Some of our users like filters so much that they create a lot of them. In this case, the left hand pane becomes a bit unwieldy with too many entries. In order to clean things up, it’s convenient to be able to store them in a tree structure, like the folders on your hard drive.

Rather than stop there, though, we added an extra twist - you can choose to have nested filters inherit the properties of the parent filter. In this way, you can build a heirarchy with increasingly narrow conditions, to let you easily drill down to whatever specific filter you have in mind. (If you don’t want to inherit conditions, just make sure the parent filters are empty.)

To create a nested filter, either right-click on the parent filter and choose New Filter, or use drag-and-drop to drop one filter on to another. This should work just like other tree controls you may be familiar with.

We hope you enjoy the new version of the mixer. As always, if you have questions or comments, you can leave them here or on the forums.

Yesterday I showed some new data which the mixer makes available through power words. However, there’s even more data buried inside the newest version of the mixer. To use that, you’ll need to understand how to use recipes - you might want to review our earlier posts introducing recipes or the official documentation if you are planning on using this feature. In a nutshell, recipes are special rules which modify how the mixer creates playlists - so you can customize the algorithms until they are just right for you.

The good news is that even if you don’t feel comfortable making your own recipes, you can still use recipes created by other people - since the description is basic XML, you can simply use your favorite text editor to copy and paste recipes which other people have created, and then choose those recipes from the preferences menu.

Up to now, the only rules available for recipes were constraints and modifiers. Version 1.9 introduces new rules which use the extra data available through MusicDNS (some of these are simply convenience wrappers around constraints or modifiers you could write yourself using the new power words). The following summary shows the most common options. Note that all rules share the following attributes:

cond="expr" - This indicates a conditional rule. The value of the expression will determine whether the rule is to be applied to a given mix.

weight="expr" - This indicates a modifier weight. The higher the number, the more likely a song is to show up in a mix (2 would mean roughly twice as likely). Numbers less than one make songs less likely to show up in a mix (.5 means roughly half as likely).

All attributes are optional - each rule has default values for general use.

Era

The era rule lets you incorporate information about when a song was first released. The full syntax looks like this:

<era cond="expr" type="type" mode="mode" range="expr" end="bool" weight="expr"/>

The type attribute controls the primary meaning of this rule. If the value is lock, this is a constraint. If the value is bend, it will bring matching songs closer. If the value is contemporaries, it will bring matching artists closer (this is the default).

The mode attribute controls which year data is used. It may be mip (use only MusicIP years), mip-local (use MusicIP years if present, or local years otherwise - this is the default), local-mip (use local years if present, or MusicIP years otherwise) or local (only use years from your own metadata).

The range attribute controls how large a range of years is considered to match - the default is plus or minus 5 years, but you can choose any range you like. The range may even be an expression.

The end attribute is used when comparing artist eras. If true, then the full release range for an artist is used - otherwise, only the initial date is used. The default is to only use the initial year for each artist.

Location

The geo rule lets you incorporate information about where a song is most popular, based on the anonymous data collected through the mixer and MusicDNS. For instance, if a certain artist is big in Germany, then you can associate songs by that artist with songs by other artists which are big in Germany. The full syntax looks like this:

<geo cond="expr" type="type" weight="expr"/>

If you want to use this as a constraint, set type="lock". Otherwise, it will work as a modifier, and you can override the default weight if you choose.

Genre

The genre rule lets you incorporate information about more detailed genres, like Heavy Metal, Disco, or Funk. This does not depend on your own tags, but on how other people around the world have tagged their songs. Using this rule, you can associate artists based on similar genre tags. The full syntax looks like this:

<genre cond="expr" type="type" weight="expr"/>

If you want to use this as a constraint, set type="lock". Otherwise, it will work as a modifier, and you can override the default weight if you choose.

Popularity

The popularity rule lets you incorporate information about how popular a song is - do you want just the hits, or do you want to reach deeper into an artist’s catalog? The full syntax looks like this:

<popularity cond="expr" type="type" weight="expr"/>

The type attribute may have one of the five following options:

• hits - only match the most popular songs (the default),
• mainstream - prefer more popular songs,
• mixed - blend popular and less popular songs,
• offbeat - prefer less popular songs,
• fringe - only match less popular songs.

Social Contexts

The social rule lets you incorporate information about how artists relate to each other in various social contexts. The full syntax looks like this:

<social cond="expr" source="source" type="type" weight="expr"/>

If you want to use this as a constraint, set type="lock". Otherwise, set type="bend", and it will work as a modifier, and you can override the default weight if you choose. (The default for this rule is to lock.)