Changes compared to 1.5.1
=========================

- Changed sugarfilter initialization to for loop
- Removed global variable for $sugarfilter (reading prefs when needed is fast enough)
- Changed global variables to local variables: $mypageurl, $content, $mytitle, $playstate, $element, @miparray, @resultarray, $k, $e, $resultlength, $playlistcount,$multiplayer, $volumeslide, $index, $bitrack, $protectloop
- Simplified processMIP function by using standard perl split function
- Separated MIP retrieval logic into a separate getMIPTrack function so it can be used from Dynamic Playlist integration code
- Changed logging category from plugin.SugarCube to plugin.sugarcube to be consistent with other plugins
- Separated volume slide logic into separate slideVolume function so it can be used from Dynamic Playlist integration code
- Separated cleanup code in cleanupTrackArray so it can be used from Dynamic Playlist integration code
- Added Dynamic Playlist integration

Description of Dynamic Playlist integration
===========================================
1.
At startup SugarCube reports to Dynamic Playlist plugin which dynamic playlists it offers by implementing the getDynamicPlayLists function.
At the moment it only reports a single playlist with identifier 'sugarcube'

2.
Whenever the Dynamic Playlist plugin needs more track, it will call the getNextDynamicPlayListTracks in the SugarCube plugin 
if Dynamic Playlist is playing one of the playlists offered by the SugarCube plugin. There is now way to know exactly when Dynamic Playlist
will request new tracks, the only thing you know is that it will do it before it has reached the end of the playlist. Typically it will
request new tracks in the middle of a playing track to make sure to not cause unnecessary delays during track changes which can cause problems with
synchronized players.

3.
When SugarCube is launched from Dynamic Playlist it has no knowledge in its own state parameters if the playlist is playing or not, this is all
handled by the Dynamic Playlist plugin. However, there are situations when SugarCube really need to know if a playlist is playing, the two cases
where I've found that this is necessary is to handled the "sleep" functionality and also to handle the "automatic volume change" functionality.

SugarCube don't have to listen to the "newsong" events to be able to play a dynamic playlist, but I added some code there also for the 
Dynamic Playlist integration to handle the player sleep and volume slide functionality offered by SugarCube.

One thing which there is no easy way to handle exactly the same as "SugarCube without Dynamic Playlist" is the refreshCube function.
With Dynamic Playlist refreshCube is called every time when Dynamic Playlist needs more tracks, since tracks might be collected in advance this means
that it might be called a bit before changing to the next hour. The result is that the MusicIP filter that is supposed to be active after the
hour switch might actually be used for the last track before the hour switch. It would be possible to call refreshCube in the "newsong" event handling instead, but that
would instead cause it to be called too late since Dynamic Playlist already have added the first track for the next hour when the "newsong" event is generated.


Suggestions of other possible changes:
======================================

Suggestion 1:
Settings.pm would be possible to simplify a lot if you didn't require the hour properties to be stored with the extra '0' in the begining.
You could then just have a prefs function that looks something like this:
========
sub prefs {
        my @preferences = qw(sugarcube_flag sugarmip_flag sugarport sugarstyle sugarvariety recipe sugarslide sugarcleartracks sugarcubevolume_flag sugarcubevolumetime sugarcubevolumetimeend sugarcubevolume sugarcubesleep sugarcubevolumesleep sugarcubevolumesleepend scsleepduration sugarcubesleep_flag scsleepfrom scsleepto));
		for(my $hour=0;$hour<24;$hour++) {
			my $postfix = $hour;
			if($hour<10) {
				$postfix = '0'.$hour;
			}	
			push @preferences, 'sugarfilter'.$postfix;
		}
		return ($prefs, @preferences);
}
========
The handler function can then be simplified to:
========
sub handler {
	my ($class, $client, $paramRef) = @_;
	$params->{'filters'}  = grabFilters();
	my $result = $class->SUPER::handler($client, $paramRef);
	if ($params->{'saveSettings'})
	{
		Plugins::SugarCube::Plugin->refreshCube();
	}
	return $result;
}
=======
Of course this also means that you will move the logic that appends a '0' on hours less than 10 to Plugin.pm


Suggestion 2:
You can add validation checks on the setting pages by adding lines like these directly below the commented "migrate" core in Settings.pm
======
$prefs->setValidate({ 'validator' => 'intlimit', 'low' =>    0, 'high' => 23 }, 'sugarcubevolumetime'  );
$prefs->setValidate({ 'validator' => 'intlimit', 'low' =>    0, 'high' => 9 }, 'sugarvariety'  );
$prefs->setValidate({ 'validator' => 'intlimit', 'low' =>    0, }, 'sugarslide'  );
======
To get correct behavoir I think this might require you to also introduce the 'prefs' function as described above


Suggestion 3:
I think you can simplify the player interface code currently implemented in the 'lines' function and int the $functions 'right' hash 
if you instead push the player into a INPUT.List or INPUT.Choice modes.
You can probably get the idea by looking at the setMode function in Slim/Plugin/RandomPlay/Plugin.pm
Using INPUT.List or INPUT.Choice means that standard SqueezeCenter code will take care of the menu navigation 
and you only need to take care of executing the code that should be executed when the user has selected something in the menu.

Suggestion 4:
It would be possible to enhance the Dynamic Playlist integration so SugarCube could be launched as a mixer from the standard
browse menus, as an example this could be used to launch SugarCube in the context of a genre.
Let me know if you feel this is interested and like to get some help implementing it.

Suggestion 5:
It would be possible to enhance the Dynamic Playlist integration so SugarCube is displayed as several different playlists in Dynamic Playlist.
By using this it would be possible to have parametrizied playlists, for example a playlist that request a MusicIP filter from the user when it
is started. SugarCube mixes would then be limited to the selected filter.
Let me know if you feel this is interested and like to get some help implementing it.


