Hi all, Now available at <http://www.doggiebox.com/distribution/Doggiebox-1E5.tbz>. What's new: • Playback tempo is now adjustable in real time according to inbound MIDI Clock events. Ken, please let me know if/how this actually works. :) • Fixed various bugs that have shown up in earlier 1E builds, including: - Some issues related to wacky tempo markings and default tempo for new bars (thanks Dan and Ken). - An issue where drum kit reconciliation did not work properly and could result in a crash (thanks Carl). - An issue where one drum may be inadvertently placed two or more times simultaneously at the same location, resulting in editing anomalies and seemingly louder velocity on some hits. (An easy way to determine whether your song has been affected by this is to open it up in Doggiebox 1.2 and see whether the same drum appears in several grid spots at the same beat position. If so, you'll have to fix this by hand using 1.2; sorry for any inconvenience.) - Some issues where empty bars, or rests at the start of a pattern, were sometimes skipped on playback. • Contrary to documentation and intent, Export Audio was always exporting the whole song (vs. just the selection, if there was one). Now fixed. I did not intend for it to take so long to get this build out. Unfortunately, trying to fix the empty bars/rests problem mentioned above opened a whole can of worms to do with tempo adjustments and calculations which has taken me a few days to deal with. As a side effect of this, there is a new known issue in this build: dragging the master tempo slider during playback will cause playback to stall as long as the mouse is down. Hopefully I will be able to fix this eventually. For the next build, I endeavour to actually introduce some more features (like beat-level copy/paste, etc.) rather than just bug fixes. :) -ben -- Ben Kennedy, chief magician zygoat creative technical services 613-228-3392 | 1-866-466-4628 http://www.zygoat.ca
On 08-Dec-2004 03:34, Ben Kennedy wrote:
- An issue where drum kit reconciliation did not work properly and could result in a crash (thanks Carl).
I'm definitely seeing this fixed now -- Thanks :)
- An issue where one drum may be inadvertently placed two or more times simultaneously at the same location, resulting in editing anomalies and seemingly louder velocity on some hits. (An easy way to determine whether your song has been affected by this is to open it up in Doggiebox 1.2 and see whether the same drum appears in several grid spots at the same beat position. If so, you'll have to fix this by hand using 1.2; sorry for any inconvenience.)
Wow, I had never noticed this until I swapped drumkits (testing a new version of an ns_kit7 dbkit) and went in to clean up some places where I apparently choose the wrong sample for replacement. It looked to me like I was clicking over an existing hit to replace it but the icon didn't change. When I then tried to delete the hit, the existing icon disappeared to reveal the icon for my new change "beneath" it. Easy to spot once I realized what was going on.
For the next build, I endeavour to actually introduce some more features (like beat-level copy/paste, etc.) rather than just bug fixes. :)
This would indeed be really cool :) Also, having saddled myself with a whole load of erroneously chosen replacement hits in the process of kit swapping, I find myself again wanting to vote for a "search & replace" feature. And a feature whereby "right-clicking" in the bar brings up a contextual menu of variants from the drum type currently selected in the kit window (if you see what I mean). Cheers, Carl -- Carl Edlund Anderson http://www.carlaz.com/
On 08 12 2004 at 9:59 am -0500, Carl Edlund Anderson wrote:
It looked to me like I was clicking over an existing hit to replace it but the icon didn't change. When I then tried to delete the hit, the existing icon disappeared to reveal the icon for my new change "beneath" it. Easy to spot once I realized what was going on.
Yeah. This was due to an unfortunate bug that did not test for the presence of an existing drum of the same type before adding the new one. I twigged to this myself as I was playing back some stuff I did that contained ride cymbals on every eight-note or whatever, which I had "drawn in" by just painting the mouse back and forth over the bar (if you know what I mean). On playback it sounded like some of these were accented and I couldn't figure out why, until I realised that there were multiple rides in some of the spots. (As an aside though, it sounded quite cool, and has served to make velocity adjustment and humanization an uber-priority now...) If you or others still have a lot of cleanup to do as a result of this bug, speak up and I can whip up a fixer-upper routine for the next build to try and automatically fix affected files. I figured it would only be a temporary, marginal inconvenience though.
This would indeed be really cool :) Also, having saddled myself with a whole load of erroneously chosen replacement hits in the process of kit swapping, I find myself again wanting to vote for a "search & replace" feature. And a feature whereby "right-clicking" in the bar brings up a contextual menu of variants from the drum type currently selected in the kit window (if you see what I mean).
Definitely; these are both key ideas and I'm on it (eventually, real soon, I hope!). -ben -- Ben Kennedy, chief magician zygoat creative technical services 613-228-3392 | 1-866-466-4628 http://www.zygoat.ca
I've encountered a few oddities while messing around in 1E5. One may be a memory issue with large samples, since I've been doing some more testing with an ns_kit7 dbkit and ns_kit7 has very large samples! Anyway, I sometimes (not not consistently, I think) run into a sitaution where some samples seem to mute each other. I find this mostly with strings of ride hits killing the snare hits beneath them. Especially, say, if I had entered a string of hat hits into a section and then change them to ride hits. Sometimes making a "clean" section with the same pattern of samples works even when the edited section plays back with these "dropouts". Not sure what's up there. However, one more clearly DB-based oddity came about when I tried to copy one of the sections I had built in order to make a variant of it, and I discovered DB was giving me the "Reconcile Drum Kit" dialog and asking me to choose an a sample for a drum called "(null) ((null))". This was odd. I hadn't switched kits, or dbsongs, and I don't have a drum called "(null)" in the kit, that I know of. Woss 'appenin' 'ere? Cheers, Carl -- Carl Edlund Anderson http://www.carlaz.com/
On 15 Dec 2004, at 09:00, Carl Edlund Anderson wrote:
However, one more clearly DB-based oddity came about when I tried to copy one of the sections I had built in order to make a variant of it, and I discovered DB was giving me the "Reconcile Drum Kit" dialog and asking me to choose an a sample for a drum called "(null) ((null))". This was odd. I hadn't switched kits, or dbsongs, and I don't have a drum called "(null)" in the kit, that I know of. Woss 'appenin' 'ere?
Not surprisingly, perhaps, I get asked to choose a sample for a drum called "(null) ((null))" when I try to load the same dbsong now. I suppose I should just choose a sample that I don't otherwise use, see what it is, and probably delete it -- but any ideas? As anyone else seen something like this, or is it just something screwy I've done on my own? Cheers, Carl -- Carl Edlund Anderson http://www.carlaz.com/
participants (2)
-
Ben Kennedy -
Carl Edlund Anderson