Archive for May, 2009
Setting up a Default Sequence Template for the MPC1000
May 31st
I make music with the MPC1000 and every time I start a new sequence I find myself naming my tracks the same, over and over and over. This takes a few minutes each time I start and is productivity play dough (it slows me down). 90% of the songs I create have the same track order and track name, simply for organization (for track mutes, tracking, etc).
Example:
Track# – Track Name
1-Hat
2-Snare1
3-Kick1
4-Kick2
5-Hat2
6-Cymbal1
7-String1
8-Shaker1
9-Empty
10-Empty
11-Empty
12-Empty
13-Empty
14-Empty
15-Sample1
16-Sample2
17-Empty
18-Empty
19-Empty
20-Loop1
21-Loop2
I wanted to set this up as a default template when I start the MP1000. Therefore I can start sampling or programming beats as soon as I turn it on. This would save me a lot of time. Here’s how to do it:
Start your MPC and name your tracks (as I have done above).
Now save this sequence to your CF card via [MODE] –> PAD3 (SAVE).
If you do not have an AUTOLOAD folder create one. Anything in the AUTOLOAD folder will be loaded when the MPC1000 starts up (if this does not happen, see the bottom of this post for how to enable the AUTOLOAD feature).
Save the sequence (in this case, Sequence01) to the AUTOLOAD directory.
Now, when your MPC1000 boots up, it will load Sequence01 as your default sequence. All of your tracks will have names and you can start programming your beats right away.
If you restart your MPC and your new sequence does not AUTOLOAD, its most likely that you do not have AUTOLOAD enabled. To enable this you must go to the load window: [MODE] –> PAD2 (LOAD) and hit F4 to enter the A.LOAD window (I’m using the JJOS1 for this, if you’re using another OS, it could be different for you).
Once in this window select “MEMORY CARD AUTOLOAD” as shown below. This will enable the AUTOLOAD feature to load from the memory cards AUTOLOAD directory. (You can also define your own folder if you want to).
That’s it, you should have your track names loading upon start of of the MPC, as shown below.
Enjoy
Spark Part 1 DimeCast Amendment
May 29th
In the latest DimeCast I recorded I developed the demo app while running the ASP.NET Development Web Server. A colleague of mine, Tim Schmidt, caught an error (thanks Tim). If you are going to run your ASP.NET MVC site on IIS 7 (which is highly likely) you’ll also need to add the following lines to the web.config.
You need to add the UrlRoutingModule to system.webServer/modules:
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
And add the UrlRouting.axd handler to system.webServer/handlers:
<add name="UrlRoutingHandler" preCondition="integratedMode" verb="*" path="UrlRouting.axd" type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Now you should be good to go!
Saying Hello to the Spark View Engine
May 27th
I recently completed a small series on the Spark View Engine for DimeCasts.net. The first episode “Saying Hello to the Spark View Engine” has been posted. If this interests you be sure to check this blog or DimeCasts.net for new episodes.
Code Review Tip: Using the ‘warning’ Preprocessor Directive
May 26th
Communicating changes back to a source developer during a remote code review (when the review is done while the developer is not near) can be very difficult. Emailing the thoughts/changes/errors is an option, but this option has “no teeth”. These items are likely to get missed and most likely will not get addressed. My preferred method is to use the #warning preprocessor directive in C#.
The Warning Preprocessor Directive
I’ll add a warning directive with some text defining what the issue is. I’ll then submit the code and then re-assign the feature ticket to the developer who’s code I reviewed.
Here’s what I’m talking about:
Now the main benefit to this approach is that if I have warnings as errors turned on I will get an error during compilation. If I do not, I’ll get a warning. My build system reports the warnings as well as errors so I’m able to keep track of what needs to be fixed still.
Here’s a screen shot of the warning that shows up from this code above:
I’m now able to keep track of the warnings/edits and also make the visible via the build system on the build server as well as each developers machine. Collective code ownership, baby.
Other Tips
- Create a nomenclature.
- Example: Include the ticket number or check in number that this original fix was in question of. Such as : FIX [ CheckIn-#OfCheckIn] – Comments such as …
- FIX [CheckIn - 1499]: Don’t hardcode UID/PW Combos …
- Have your build break on errors. This will cause you to fail fast.
- If the offense is a system halting issue, use the error preprocessor directive. This works the same as the warning, but throws a compilation error. Fast Failure, baby.
Updated Visual Studio Settings
May 26th
Previously I had uploaded my dark themed visual studio settings. These settings were created prior to using the Spark View Engine for my web development. I have updated the settings to include support for the Spark View Engine views. Here’s a screenshot of what the HTML view looks like. Download the settings file at the bottom of the post.
Download
DonnFelker-20090526.vssettings (~341 KB)
