If all goes to plan the 1.1 release should be available within the next few weeks. So, do you have any last minute feature requests you'd like to see added before the release?

Some new features in 1.1:

+Vastly improved automation support in most major hosts
+Choke groups
+Solo buttons!
+Pads now transmit 'velocity'
+Velocity sensitivity on/off switches for each pad
+Reduced CPU usage


Some new features recently requested but not yet added:

-Program change support for live performance
-Randomize kit and randomize pad buttons
-More presets!
-Sample playback module
-Velocity/controller mapping to parameters


http://www.audiospillage.com/drumspillage.php

Gotta say haven't regretted my purchase of DrumSpillage one bit as it has mountains of character and a fantastic ability to create authentic analog/hybrid drum sounds that really cut through a mix; but it's great to see the improved automation support and choke groups (as well some of the other improvements you've listed).

One of my main bug- bears though is preset management. I'd like a better way of seamlessly auditioning presets without having to use OS X's Finder. It's 4 or 5 clicks every time you want to change preset which to be frank begins to grate after a while.

Great work so far though, really looking forward to the improvements in future releases (and maybe even an integrated drum sequencer at some point).

JM
------------
http://soundcloud.com/leftside-wobble

Thanks for the positive comments metrosonic!



OK, someone raised a similar point recently too. The idea is that the load kit/pad menus should take you straight to a root menu e.g.

/Library/Audio/Presets/AudioSpillage/DrumSpillageKits/ or
/Library/Audio/Presets/AudioSpillage/DrumSpillagePads/

..from there you should be able to navigate to the UserKits or UserPads folder within 1 or 2 clicks. In practice it seems this isn't what people want.

In which case it would make sense to try and improve the current system in combination with the introduction of proper bank/kit/program change handling which has also been requested a number of times. Some way of categorising pads by type (bass drum, hihat etc) would be useful for preset management too.

This is my personal preference so that you don't have to use Finder at all when previewing presets.

JM
------------
http://soundcloud.com/leftside-wobble

OK, it's on the list!

Ok, so far, very enthousiastic about my new purchase of DrumSpillage. I think it will enable me to add a very unique sound to my tracks.

I'm curious about the status of version 1.1 and in what ways it will improve automation. In my music, I use a lot of it to add a sense of evolution in a track and now it seems very difficult to alter some of the more interesting parameters (i.e. Warp Frq and FM) using Logic automation since they are difficult or impossible to find in the automation context-menu. I found they can be assigned to the pad view and controlled using the crosshair (by lack of a better word) but then, how do I automate the crosshair?

OK, in Logic, I found the possibility to automate "X Controller" and "Y Controller" - but that will actually change the parameter assigned to X and Y, and not its value (which I find very confusing)!

So let's say I'm trying to automate "X Controller" and I move from 0 to 109 (its maximum value), I can see the parameter set to the X-axis change rapidly from "BD: Pitch" to "Filter Modulation Depth 2" and all that's in between, in stead of the "BD: Pitch" value changing.

I assume this is unintentional?

And I finally: Discovered that the parameters that are particular to each model are only numbered from "Model #1" to "Model # 32" - probably because this set-up changes whenever you change a model. My dear "Warp Frq" parameter, for instance, is "Model #21".

Now, I can imagine it may be difficult to set it up so that all parameters are properly named. Perhaps there could be a map made available that links the various controllers to "Model #"-numbers, to save me the time of having to do so myself?

That's exactly the problem. In theory it isn't difficult to implement dynamic parameter names that update when the model type is changed but in practice few hosts fully support it (although things are improving). So for consistency the model parameters are named Model #1-32 as you found out.

To clear things up I'll add a few pages to the manual to illustrate the exact mapping. Perhaps a more interactive solution such as tool tips or something like that would be a better idea.

1.1 is in the final stages of testing. In some hosts automation recording in Latch and Touch mode wasn't reliable (including Logic) so that has been fixed. Also, parameter values displayed in automation editors should now be much more consistent with the values shown in the GUI.

Thanks for the positive comments!

Hi stefan,



Yes and no..

The "X Controller" and "Y Controller" parameters are used internally to keep track of the parameters assigned to the X/Y controller. These two parameters are now hidden from Logic's automation lists in 1.1 - unfortunately not all hosts currently support hiding parameters from automation editors.

To automate the X/Y controller you need to know the exact parameter assigned to it.. which I admit is confusing and could be improved upon in the future.

The 1.2.1 update includes tooltip support. Doesn't sound like an earth shattering addition on paper but the tooltips for all the model parameters now display the automation parameter ids (e.g model#1 .. model#32) for easier reference

Hope you find that useful,
AudioSpillage