Recently we encountered a problem where a user had two parallel installs. One for version 4.8.5 and one for version 4.9.0. The former version did not respect the mp3 samplerate while the latter does. Songs with a non 44.1kHz samplerate would be playing at different speeds. After version 4.8.5, that problem had been resolved. We took care to play the old mixes still as they were created (that is at a wrong samplerate).
What happened: version 4.9.0 analyzed a bunch of new tracks. One of these tracks had an odd samplerate and was used in a mix created in 4.9.0. Then version 4.8.5 was started. It saw the newly analyzed beatgraphs and realized it did not understand what they were about and reanalyzed the tracks, writing an older version of the .bpmdj1 files to disk. That is: without the samplerate info. Some time later, version 4.9.0 imported those beatgraphs again, thereby it saw the old file format and assumed the data was still okay (except without knowing the samplerate), and let them be as they were. All fine, until that mix was opened which contained the odd tracks _with known samplerate_. There really wasn't any such track anymore. Therefore it refused to load/play that particular track. The solution was to start the latest version again with --mp3-upgrade on the directory with the flip-flopping beatgraphs.
Nevertheless, it shows a problem we are facing: many users want to have multiple installs of the software, yet a software can generally not be forward compatible. Typically what is done to solve this is to avoid data interaction between multiple installs. At the level of beatgraphms (.bpmdj1 files), this is not the case, these are shared between installs and serve as an ankerpoint to define the identity of a file. How this could be solved is not at all clear yet. Yet there is also a second problem: the mixes themselves (.bpmdjs files) are shared between installs. If version 4.8.5 sees files in a 4.9.0 install, it will assume it can write it. Equally so, a version 4.9.0 install will assume ownership over 4.8.5 files. That is a real problem because, if mix 4.8.5 is deleted in install 4.9.0, it will really be gone from disk. Install 4.8.5 might rewrite it (if it still has a cached version in the database), but if install 4.8.5 is removed before the mix is rewritten, then it will be removed.
The history of the above clusterfuck lies in the phone version of BpmDj. On a phone we were absolutely sure that only 1 BpmDj version would run and we were sure it would never go back in version numbers. On desktop this is no longer true and I believe we must face reality and start thikning about giving the user control over where his files are saved. You know: like a real 'save' and 'save as'.
A question to the more musical notation inclined people: if we have a timesignature of 4/4, a barlength of X minutes, then we can compute the BPM by as 4 beats/X minutes. Now.... if we had a 3/4 signature, we would get 3 beat/X minutes, which means that the BPM wil be either over or underreported if we were to treat this rhythm as a 4/4 signautre. Sadly, this is what most DJ tools do. We're trying to fix that in the software and here comes the interesting part... The denominator '4' was actually never used in the previous argument. Assume we had a timesignature of 6/8. Would a multiplication with 6 really be the correct number of beats ? For highly denominated signatures, this would result in absurdly large tempos.
From what I gather this is mainly a notational matter: 6/8 is sometimes easier to write the score than 3/4 because of the note lengths. A second argument is that 6/8th has a different energy hierarchy than the 3/4th. Assuming that it is indeed related to the difference in hierarchy, then how do you actually count the beats in a bar if you look at the timesignature ?
The past three months, we've been creating a testbed to verify whether the software is backward compatible. That is: can it properly load all sessions from any previous BpmDj version, despite changes to the internal data format. During this test process, we encountered many dead ends and problems in the software that were never really apparent to us. After all, song analysis is something you run once and be done with it and we did not sufficiently test that before each release. For about a year or so the software required two starts before it would analyze your tracks, and even then it would often stop for 5 seconds before continuing. In other instances we found that entire parts of the database were unnecessary.
Regarding new features: the nearest neighbors have again been overhauled, you might see that your next start will start upgrading the beatgraphs. Luckily this process is fast. About 50 milliseconds per track. Most likely your harddisk will be the bottleneck during this process.
And to give you something new as well, we added a new display option: 'delignate beatgraphs'. See menu Display|Delignate bars.
211 US, United States 105 CL, Chile 94 GB, United Kingdom 73 NL, Netherlands 55 TH, Thailand 51 IT, Italy 43 MX, Mexico 42 PL, Poland 39 RU, Russian Federation 37 FR, France 33 BE, Belgium 25 CA, Canada 24 CH, Switzerland 22 RS, Serbia 22 AU, Australia 18 ES, Spain 16 SE, Sweden 16 PE, Peru 14 ZA, South Africa 12 GR, Greece 12 BR, Brazil 11 CN, China 10 KZ, Kazakhstan 10 AT, Austria 9 RO, Romania 9 CZ, Czech Republic 7 DK, Denmark
Between grappa and storm, we got good weather and 4 people who made a mix with BpmDj. Be sure to check 'm out
This year we will again be at the Chaos Communication Camp 2015 (which takes place around Berlin)
At CCC 2011, we gave a talk on how BpmDj performs its audio analysis. Two years later, at OHM 2013, we explained how the nearest neighbor detection and associated weight matrix is created. This year, we won't talk about the project anymore, but instead give you the opportunity to meet the developers.
Actually, we want you to come to us with ~100 tracks and an idea for a mix. We will then sit together and create that mix. As a reward you will receive one of our heat sensitive cups.