I thought I’d see if there was any improvement in the latest version of BFD3. Seems not.
Loading some of 8 Bit kit samples (snares mainly) - causes an immediate BFD3 crash when you attempt to one of the trigger one of the articulations of the kit piece via MIDI.
Here’s some more details:
The 8 Bit Kit snares tend to have both Hit and Rim articulations - it’s normally just one of the articulations that causes the crash not both…although one of the snares crashes on both.
Renaming the ‘Hit’ folder to ‘Rim’ and visa-versa loads the previously crashing samples fine. This means the crash is almost certainly not something within the sample folder ? Samples are not corrupt.
I’ve tried rebuilding/copying the BFDinfo.xml from other kit pieces but the crash remains with the same kit articulation. This says to me that there isn’t a problem with the data in the actual kit piece folder and the issue is elsewhere ?
done lots of rescans - tried temporarily deleting the kitpiece database etc.
On odd thing is that if I start with a blank kit and just load one of the faulty kit pieces - then trigger over midi it doesn’t crash but you get an audio ‘blip’ and the meters peg fully on for the duration of the sample. No sound is generated though.
Also:
All still working fine in BFD2
It used to work last time I checked in the InMusic version of BFD
you can preview both hit/rim fine in the ‘info window’ - crash occurs when you try to trigger via MIDI.
nothing logged as the crash is to fatal.
Windows shows the error in BFD.dll as you’d expect.
ok - think I’ve found the source of the problem and here’s a ‘workaround’
This problem doesn’t occur in the last FXpansion version of BFD3 - this is a bug that has been recently introduced - one step forward and two steps back.
This is for Windows but I suspect the same bug is in the Mac version.
Are a bunch of articulation .xml files for your kit pieces. Find the folder of the crashing piece and rename BFDArticTweaks.xml > .old
You can’t simply delete or rename the folder as BFD3 recreates it when it loads the piece - but it’s not smart enough to know that you’ve simply renamed that file so it doesn’t try to ‘fix’ the ‘mistake’
Should load ok now.
NOTE: these .xml files are not corrupted in anyway - although I notice that InMusic BFD3 has written some extra config in there that’s not in the FXP version. Just the fact they exist causes the crash.
Dunno how many kit pieces are affected or what the fallout of not having those extra .xml files is but 18 months after InMusic and we still have show stopping issues - Anybody actually beta testing this stuff ? sigh
this workaround doesn’t work with the crashing Bob Siebenberg kit pieces or with the crashing Crash in the downbeat kit - although I think the problem is similar - and the fix is going to be similar too. That Siebenberg kit has some odd things going on with the various .xml files.
Either way there is enough information there for the developers to fix it - although I suspect that won’t happen - I’ve spent enough time trying to debug the dodgy code. Back to SD3 which I’ve never had crash and the Hitmaker expansion is amazing.
Could you please send me the OLD artictweak.xml file, and could you also allow BFD3 to generate a new one and send me that.
And if you do still have a version of BFD3 from FXpansion, can you delete the artictweaks from the loudness cache AND the kitpiece in question, and send me the new one that the OLD version of BFD3 creates - basically I wanna see what piece of data is being generated badly, then we can address the fix.
There is nothing wrong with the artictweak.xml file. You can replace it with the old FXP one - or you can let BFD3 generate a NEW one , which it will do if you delete the top level directory containing it. You can even download the whole installer again and use the one from there. Zero difference - byte identical files.
The fact that the file exists at all causes the crash.
It’s fine to leave the .xml file in the data directory, you just need to rename the one in the /appdata directory.
If you’re interested the difference in the ‘new’ BFD3 xml compared to FXP is that it adds some volume curve information.
Something similar is happening with the other kit pieces that others have reported causing crashes - but I’ve spend several hours tracking that showstopping bug down and I’m not sure I have the hear/time/inclination to fix another.
it’s very easy to reproduce - why not try ?
Incidentally I’ve found a few more bugs - that don’t cause a crash - but InMusic have had 18 months on this, with very little progress it seems ? Sorry if I come across as a bit annoyed but I’ve spent £1000s on BFD products in the last 2 decades and it’s frustrating seeing all that money and potential end up like this.
I can’t reproduce it here. I’m able to load every single 8-Bit Kit drum, without any crashing. There is something going on here that is more complex than you may realise.
If you won’t send me the files, then I can’t debug this.
What I can say is, here, I do not have any legacy FXpansion era packs. It is all new packs from the newest inMusic installers. I don’t know if there is some data conflict that could be happening here; I’d have to check it out. Extremely difficult to diagnose this without actual evidence to go on.
Just as a point of order, I’ve been working on BFD with Angus, Skot, and the rest of the FX crew since 2008 (and a bunch of FXers are still with BFD to this day). I’m the one who built all of the installers for the expansion packs, did the QA testing, and even a ton of presets and what not. So I’m very familiar with what these files do. If you send them over, I might be able to spot some errant data.
It feels like the artic tweak file has something inside that causes BFDengine to crash out. That stands to reason if removing it makes the crash go away.
I can send you series of IDENTICAL .xml files and other files that are autogenerated by the latest version of BFD3. They all crash when you try to play the sample. ANY and ALL .xml files being present in the /appdata folder cause BFD3 to crash when attempting to play the samples.
err? I’ve given you some evidence ? and I’ve managed to find a workaround.
yep, and I’ve been using BFD longer that that - what’s your point ?
right - well done
maybe so - but the NEW autogenerated ones also cause the crash. It’s not the CONTENTS of the file but some other factor here.
as I say, you are barking up the wrong tree. Sending those files WILL NOT HELP.
happy to work with you on this but your track record is not good - are you saying if I send you the various files you PROMISE to fix it ? Do you still have developers actually working there ?
just to confirm - I’ll send you several .xml files. Some of them are the original defaults from the original install (which you ALREADY HAVE) - some have some extra info deposited there by BFD3.
ALL (yes ALL) of which crash BFD3 when they are in the /appdata folder and by analysing the difference between them you will be able to diagnose the issue ? (ha ha, bloody ha). It’s not the DIFFERENCE in the files or their contents that is the issue.
That’s especially interesting as you don’t actually have any legacy era packs installed and yet you look after QA - explains a lot…but I’m sure your developer are all over this. Just checking - they have been working on this for the 18 months, since Skot and Angus sold out ?
I also notice that you didn’t comment on this thread
will do - but as I’ve said several times you’re barking up the wrong tree
ALL the .xml files crash BFD3 when loading those samples, including the default ones and autogenerated ones. So looking at the difference between them will tell you nothing at all. The fault is NOT IN THOSE FILES.
and that’s why we are where we are with BFD.
thanks
is it ? - in the last 18 months under your stewardship we really haven’t seen much improvement…actually the FXP version works better, it certainly doesn’t crash quite as frequently…so we’ve moved backwards. If you wanna take ownership then do it but if not then accept you’ve basically screwed what was a great product.
3 xml files - ALL of which crash BFD3 when they are in the /appdata LoudnessCache folder (NOT the kit piece data folder)
These files are autogenerated by BFD3 the first time the kit piece loads. As I mentioned - this is fine in the FXP BFD3 so it’s something that changes made by InMusic has broken.
The files are NOT corrupt - and the problem is the crash when you attempt to play the articulation IF any xml file exists. The workaround is given in previous replies.
note: the ‘code’ tag in Discourse isn’t very kind to the formatting but if you go in as a Mod and edit my post you’ll see the original formatting - so it will be a bit easier to read.
Okay. Those files are definitely corrupt. The loudness measurements all say “-inf” - that is why the kitpieces are crashing. Have confirmed that this is the issue at hand.
BFD3 only regenerates these files if two things are true:
The LoudnessCache folder doesn’t have artictweaks.xml for the kitpiece articulation in question.
The kitpiece audio folder itself doesn’t have artictweaks.xml for the articulation in question.
From that, I am assuming that you’re only deleting/renaming in one place and not the other. Because when I clear out all of my 8-bit kit tweak files, and let BFD3 regenerate them, it no longer has bad loudness data.
I took a look at the raw data on the server and this does look like a bug in packaging - these files should never have been bundled. Strangely enough, my local data didn’t have this problem. My data is always in-flux because of all of the development work I do, so I’m assuming I cleared them out at some point in the past. That means the data I have isn’t the same as the dat you have.
All in all, was useful to see the files in order to confirm the data inside them. That then led me to looking at the server data and comparing it against yours and my local copy, to find out the cause. So thanks for that.
Ultimately, it is a simple 10 minute fix, and then an upload of a fixed installer bundle. I’ll have that done by the end of the day.
If you want to fix it yourself, you can delete all of those tweaks xml files across loudness cache folder AND the 8 Bit Kit audio folder, and let BFD3 generate them completely from scratch; that should create correct data.
I did that on the crashing folders already - and the IMBFD xml file was autogenerated by BFD3
and I think you need to delete the containing folder in /appdata as it won’t autogenerate if the folder is present (as mentioned earlier)
EDIT - and when you delete /appdata and data xml files BFD recreates them with the same -inf data
EDIT2 - I’m not seeing this in the Sonic Reality kits or any of the FXP ones you mentioned ?
Very curious that you’re seeing those -inf values being recreated. I’m wondering if this is a bug that has come and gone many times, and it has snuck into the .31 build you have.
I’m on a different internal build, and I’m not seeing it here. Hmmmmmm. More investigation required. I’m fixing 8BK now.
